Go语言中文网，致力于每日分享编码知识，欢迎关注我，会有意想不到的收获！
假定N为后台服务节点数，当前台携带关键字key发起请求时，我们通常将key进行hash后采用模运算（hash(key)%N）来将请求分发到不同的节点上。
对前台请求于后台无状态服务节点不敏感的场景而言，只要请求key具有一定的随机性，哪怕节点动态增删，该算法于后台而言已可以达到很好的负载均衡效果。
但对于分散式快取，或者分散式数据库等场景而言，上述方式就不合适了。因后台节点的增删会引起几乎所有key的重新对映。这样，于分散式快取而言，均发生cache miss；于分散式数据库而言发生资料错乱，其影响是灾难性的。
而一致性杂凑算法的目标是，当K个请求key发起请求时。后台增减节点，只会引起K/N的key发生重新对映。即一致性杂凑算法，在后台节点稳定时，同一key的每次请求对映到的节点是一样的。而当后台节点增减时，该算法尽量将K个key对映到与之前相同的节点上。
1）一致性杂凑算法原理
一致性杂凑算法是将每个Node节点对映到同一个圆上。将各Node的key采用hash计算，可得到一个整数阵列。将该阵列排序后，首尾相连即是一个圆。如下图所示，Node的key分布在圆的不同弧段上。同理，若有一请求key，hash后落入该圆的某一弧段（下图三角点所示），顺时针方向寻得离其最近的节点即为其服务节点（下图Node2）。这样每个节点覆盖了圆上从上一节点到其本身的一段弧段区间。如某一节点失效，之前落入其弧段区间的请求即会顺时针移到与其相邻的节点（下图如Node2失效，之前落入Node3至Node2弧段的请求会落入Node1）。而未落入失效弧段区间的节点则不受影响（之前落入Node2至Node3弧段的请求，当Node2失效后不受影响）。增加节点的场景与此类似，新的节点承载一段新区间，这样，落入失效节点至新节点弧段的请求会被新节点所承载。
在节点固定的情况下，为了增加节点在圆上分布的均匀性与分散性，可以设定节点的replicas（副本数）。下图将replicas设定为2，各节点承载的弧段范围已更加精细且于整体而言分布更加分散。所以适当调节replicas引数可以提高算法的均衡性。
2）Golang一致性杂凑算法实现程式码
本文的hash函式，是对key先做一次md5Sum，然后采用crc32做checkSum得到一个正数。
3）均匀性分析
构建服务节点时，为模拟节点key在圆上的分布，简单采用id（0，1，2）做初始key，replicas为100。根据点间距等比例划分圆后得到其位置，彩色小圆点为其对应的节点（红绿蓝对应0，1，2）；三角点代表外部请求的三个字串（10.10.10.10，10.10.20.11，10.10.30.12）hash后按算法取到的服务节点；
使用Python matplotlib工具描点绘图如下。
从图可知，节点虽少（3个），但扩大副本量后，key的分布已具有一定的均匀性与分散性，外部key请求的最终落地节点于整体服务节点而言也是比较均匀的。
4）Golang高可用丛集代理程式码
一致性杂凑算法具有很广泛的使用场景。如做请求分流与负载均衡，分散式快取，分散式储存等。如下程式码呼叫Golang反向代理类库，结合上述一致性杂凑算法，根据请求头标记做分发，数行程式码，即可构建一个小巧高可用的代理服务器。
参考资料
[1] https://en.m.wikipedia.org/wiki/Consistent_hashing[2] http://michaelnielsen.org/blog/consistent-hashing/
[3] http://www8.org/w8-papers/2a-webserver/caching/paper2.html
原文连结：https://leileiluoluo.com/posts/consistent-hashing-and-high-available-cluster-proxy.html
本文作者：磊磊落落的部落格，原创授权释出。
