来自：黑客和白帽子的故事
::特性
jdk8中使用了::的用法。就是把方法当做参数传到stream内部，使stream的每个元素都传入到该方法里面执行一下，双冒号运算就是Java中的[方法引用],[方法引用]的格式是：
分类目录归档：所有Java文章
Redis集群的方案总结：客户端Sharding/Redis Cluster/Proxy
转载：分布式一致性算法（一）一致性哈希算法（consistent hashing）
转载：Jedis下的ShardedJedis（分布式）使用方法（一）
一、Redis集群
由于Redis出众的性能，其在众多的移动互联网企业中得到广泛的应用。Redis在3.0版本前只支持单实例模式，虽然现在的服务器内存可以到100GB、200GB的规模，但是单实例模式限制了Redis没法满足业务的需求（例如新浪微博就曾经用Redis存储了超过1TB的数据）。Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能，但3.0版本等到2015年才发布正式版。各大企业在3.0版本还没发布前为了解决Redis的存储瓶颈，纷纷推出了各自的Redis集群方案。这些方案的核心思想是把数据分片（sharding）存储在多个Redis实例中，每一片就是一个Redis实例。
一致性哈希算法（consistent hashing）
来自：一致性hash算法（consistent hashing）
一 基本场景
比如你有 N 个 cache 服务器（后面简称 cache ），那么如何将一个对象 object 映射到 N 个 cache 上呢，你很可能会采用类似下面的通用方法计算 object 的 hash 值，然后均匀的映射到到 N 个 cache ；
hash(object)%N
一切都运行正常，再考虑如下的两种情况:
- 1 一个 cache 服务器 m down 掉了（在实际应用中必须要考虑这种情况），这样所有映射到 cache m 的对象都会失效，怎么办，需要把 cache m 从 cache 中移除，这时候 cache 是 N-1 台，映射公式变成了
hash(object)%(N-1) ； - 2 由于访问加重，需要添加 cache ，这时候 cache 是 N+1 台，映射公式变成了 hash(object)%(N+1) ；
1 和 2 意味着什么？这意味着突然之间几乎所有的 cache 都失效了。对于服务器而言，这是一场灾难，洪水般的访问都会直接冲向后台服务器；
再来考虑第三个问题，由于硬件能力越来越强，你可能想让后面添加的节点多做点活，显然上面的 hash 算法也做不到。
有什么方法可以改变这个状况呢，这就是 consistent hashing…
学完这100多技术，能当架构师么？（能）
来自：小姐姐味道
前几天，有个搞培训的朋友，和我要一份java后端的进阶路线图，我就把这篇文章发给了他《必看！java后端，亮剑诛仙》。今天，又想要个java后端目前最常用的工具和框架，正好我以前画过这样一张图，于是发给了他。虽然不是很全，但也希望得到他的夸奖。没想到… 继续阅读
一篇文章讲透分布式存储
来自：存储技术
分布式存储是一个大的概念，其包含的种类繁多，除了传统意义上的分布式文件系统、分布式块存储和分布式对象存储外，还包括分布式数据库和分布式缓存等。本文局限在分布式文件系统等传统意义上的存储架构，对于数据库等不做介绍。
补充说明：（1）块存储可以认为是裸盘，最多包一层逻辑卷（LVM）；常见的DAS、FC-SAN、IP-SAN都是块存储，块存储最明显的特征就是不能被操作系统直接读写，需要格式化为指定的文件系统（Ext3、Ext4、NTFS）后才可以访问。优点：读写快（带宽&IOPS）；缺点：因为太底层了，不利于扩展。（2）补充一点，与块存储对应的是文件存储，Ext3、Ext4、NTFS是本地文件存储，NFS、CIFS是网络文件存储（NAS存储）；最明显的特征是支持POSIX的文件访问接口：open、read、write、seek、close等；优点：便于扩展&共享；缺点：读写速度慢。（3）对象存储，对象存储肯定是分布式存储，但分布式存储可能是分布式文件系统，不一定是对象存储；常见的对象存储开源实现有 Ceph 的RADOS、openstack的swift、AWS s3等，常见分布式文件系统，lustre、glusterfs、HDFS等；对象存储和分布式文件系统的表面区别：对象存储支持的访问接口基本都是restful接口、而分布式文件系统提供的POSIX兼容的文件操作接口；最本质的区别：分布式文件系统文件组织方式为目录树、对象存储采用的则是扁平的组织方式；对象存储不支持随机读取和写入，put和get操作都是针对的整个文件。相信使用过网盘的同学都了解。既然都是分布式存储，扩展性肯定都是没问题的。只是使用场景不同。
Mybatis架构与原理
来自：消失er
我们把Mybatis的功能架构分为三层：
(1)API接口层：提供给外部使用的接口API，开发人员通过这些本地API来操纵数据库。接口层一接收到调用请求就会调用数据处理层来完成具体的数据处理。
(2)数据处理层：负责具体的SQL查找、SQL解析、SQL执行和执行结果映射处理等。它主要的目的是根据调用的请求完成一次数据库操作。
(3)基础支撑层：负责最基础的功能支撑，包括连接管理、事务管理、配置加载和缓存处理，这些都是共用的东西，将他们抽取出来作为最基础的组件。为上层的数据处理层提供最基础的支撑。
集群资源调度系统设计架构总结
来自：IO METER
调度器的定义
无论是在单机系统还是分布式系统当中，调度器其实都是非常核心和普遍的组件，其内涵也比较宽广和模糊。
一般来说，下面提到的几种类型的模块都可以认为是调度器：
-
- 早期计算机系统当中的批处理调度系统
- 现代计算机系统当中的抢占式进程调度系统和内存分配系统
- 某些系统或程序提供或实现的，定时激发某些类型操作的工具(如 crontab、Quartz 等)
- 某些编程语言的 Runtime 提供的线程/纤程/协程调度器(如 Golang 内置的 Goroutine 调度器)
- 分布式系统当中的任务关系管理和调度执行系统，(如 Hadoop YARN, Airflow 等)
- 分布式系统当中的资源管理和调度系统(如 Mesos、Borg、Kubernetes 的调度器等)
可以被称为调度器的工具涵盖的范围非常广，他们有的提供定时激发任务的能力，有的提供资源管理的能力，
有的负责维护任务的依赖关系和执行顺序。甚至有的系统还集成了任务监控和各种指标度量的工具。
这篇文章主要涉及的是管理系统资源和调度任务执行相关方面的架构和模型，
具体的资源分配策略和任务调度策略不在我们讨论的范围内
