Cassandra源码学习：一致性hash回顾

每个节点都有一个哈希值，将这个哈希值配置到圆环上(0到2的32次方)，相当于这个圆环分配给了这些节点，每个节点负责一段。数据根据同样的哈希函数也得到一个哈希值，这个哈希值落到哪一段，就表示这个节点存储在这段对应的节点上。

每添加或者移除一个新的节点，只有相邻的那个节点会受到影响，因此，一致性哈希解决了节点变化引起的数据重新分布问题。

Cassandra1.2以前采用的是这种标准的一致性哈希算法：为每个节点分配一个token，根据这个token值来决定节点在集群中的位置以及这个节点所存储的数据范围。

由于这种方式会造成数据分布不均的问题，在Cassandra1.2以后采用了虚拟节点的思想：不需要为每个节点分配token，把圆环分成更多部分，让每个节点负责多个部分的数据，这样一个节点移除后，它所负责的多个token会托管给多个节点处理，这种思想解决了数据分布不均的问题。



如图所示，上面部分是标准一致性哈希，每个节点负责圆环中连续的一段，如果Node2突然down掉，Node2负责的数据托管给Node1，即Node1负责EFAB四段，如果Node1里面有很多热点用户产生的数据导致Node1已经有点撑不住了，恰巧B也是热点用户产生的数据，这样一来Node1可能会追随Node2而去，Node1去了，Node6还hold住吗？

下面部分是虚拟节点实现，每个节点不再负责连续部分，且圆环被分为更多的部分。如果Node2突然down掉，Node2负责的数据不全是托管给Node1，而是托管给多个节点。而且也保持了一致性哈希的特点。