“一致性hash的设计初衷是处理分布式缓存问题，它不仅能起到hash作用，还可以在服务器宕机时，尽量少地迁移数据。因而被广泛用于状态服务的路由功能”
假设有一个消息推送系统，其简易架构如下
设施接入层不仅要接收设施的登录、下线等状态命令，还要把开发者的消息推送给设施。这个时候设施接入层就需要维护设施的状态信息（当然可以专门拆一个状态服务去维护这些信息，要求这部分必需少有代码升级，具体起因自己去想哦=_=）。这个时候设施接入层的每台server都保留一批设施的状态信息cache，设施应该连接哪台server去获取数据，同时中间层的消息又该发往哪个server去推送呢？这就用到了一致性hash算法。
一致性hash由对象、资源、算法和机器组成。它要做的是：对象通过算法判断连哪台机器。在如上系统中：设施id（userID）为对象；其对应的状态数据(cache)为资源；服务器为机器。
一致性hash在一致性hash算法中，这些资源围成了一个闭环，每台机器又保存着一个资源段，每个资源段对应一批对象/设施；这样假如某台机器挂了，那它对应的资源转移到离它较近的机器x，这台dead server对应的设施连接到机器x就行。
现在假设这四个资源段对应的设施，活跃情况相差较大。比方说资源段1、2对应的设施特别活跃，而资源段3和4几乎没活动。这样机器1-2需要保存大量的状态数据，而3-4则有大量的空置，显然是不正当的。改进版的一致性hash算法是这样操作的：它不再是每台机器去保存一个连续的资源段，而是让每台机器都保存多个区域的部分资源段。如机器1保存每个资源段的1/4，机器2保存每个资源段的1/4，机器3、4同样如此。这样即便个别号段有热点，也会均摊到不同的机器。
一致性hash改进版如上详情了一致性hash的概念和改进，在系统实践中，我们客户量非常大，往往不只一个集群。我们是如此使用一致性hash：
首先根据不同号段选择对应的集群，这部分是可配置的
确定集群后，根据一致性hash把设施匹配到server的某个instance上(每台server部署多个设施接入层实例（1.每个instance保存的状态信息更分散;2.服务的gc问题会有缓解）
建立机器虚拟节点：把user逆序(打乱之前连续userId)，组成新的资源段;相当于建立了server虚拟节点
记录每台server锁服务的设施数，假如机器A挂了，筛选服务设施数最少的机器去承接kicked-device
以上详情了一致性Hash的原理和实践，但不是所有的服务都适合用一致性hash来路由。比方01节中的消息推送系统，中间层是无状态的，开发者接入层请求cluter-A的哪台机器都行，它只需做完基本校验后，把消息异步发给MQ就可，无需等待结果直接返回; 而设施接入层是有状态的，且对较高时延无法忍受，更适合一致性Hash选择好server-instance，而后通过TCP/UDP来通信。
在此我向大家推荐一个架构学习交流圈。点击加入交流圈 里面资深架构师会分享少量整理好的录制视频录像和BATJ面试题：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多。
注：
作者：靳刚同学
链接：https://mp.weixin.qq.com/s/30uPH-EddfdcRGPEz7LFhw
来源：微信公众号
