参考这篇文章：
http://www.yeeach.com/post/591
在做服务器负载均衡时候可供选择的负载均衡的算法有很多，
包括： 轮循算法（Round Robin）、哈希算法（HASH）、最少连接算法（Least Connection）、响应速度算法（Response Time）、加权法（Weighted ）等。
其中哈希算法是最为常用的算法.
如果某一台机器宕机，新增一台机器，如何设计一个负载均衡策略，使得受到影响的请求尽可能的少呢？
在Memcached、Key-Value Store、Bittorrent DHT、LVS中都采用了Consistent Hashing算法，可以说Consistent Hashing 是分布式系统负载均衡的首选算法。
由于hash算法结果一般为unsigned int型，因此对于hash函数的结果应该均匀分布在[0,232-1]间，如果我们把一个圆环用232 个点来进行均匀切割，首先按照hash(key)函数算出服务器（节点）的哈希值， 并将其分布到0～232的圆上。
用同样的hash(key)函数求出需要存储数据的键的哈希值，并映射到圆上。然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器（节点）上。
注：节点和key都映射在同一个圆上。
新增一个节点的时候，只有在圆环上新增节点逆时针方向的第一个节点的数据会受到影响。删除一个节点的时候，只有在圆环上原来删除节点顺时针方向的第一个节点的数据会受到影响，因此通过Consistent Hashing很好地解决了负载均衡中由于新增节点、删除节点引起的hash值颠簸问题。
虚拟节点（virtual nodes）
之所以要引进虚拟节点是因为在服务器（节点）数较少的情况下（例如只有3台服务器），通过hash(key)算出节点的哈希值在圆环上并不是均匀分布的（稀疏的），
仍然会出现各节点负载不均衡的问题。虚拟节点可以认为是实际节点的复制品（replicas），本质上与实际节点实际上是一样的（key并不相同）。
引入虚拟节点后，通过将每个实际的服务器（节点）数按照一定的比例(例如200倍)扩大后并计算其hash(key)值以均匀分布到圆环上。
在进行负载均衡时候，落到虚拟节点的哈希值实际就落到了实际的节点上。
由于所有的实际节点是按照相同的比例复制成虚拟节点的，因此解决了节点数较少的情况下哈希值在圆环上均匀分布的问题。
2、Consistent Hashing算法实现：
文章Consistent Hashing中描述了Consistent Hashing的Java实现，很简洁。
import java.util.Collection; import java.util.SortedMap; import java.util.TreeMap; public class ConsistentHash<T> { private final HashFunction hashFunction; private final int numberOfReplicas; private final SortedMap<Integer, T> circle = new TreeMap<Integer, T>(); public ConsistentHash(HashFunction hashFunction, int numberOfReplicas, Collection<T> nodes) { this.hashFunction = hashFunction; this.numberOfReplicas = numberOfReplicas; for (T node : nodes) { add(node); } } public void add(T node) { for (int i = 0; i < numberOfReplicas; i++) { circle.put(hashFunction.hash(node.toString() + i), node); } } public void remove(T node) { for (int i = 0; i < numberOfReplicas; i++) { circle.remove(hashFunction.hash(node.toString() + i)); } } public T get(Object key) { if (circle.isEmpty()) { return null; } int hash = hashFunction.hash(key); if (!circle.containsKey(hash)) { SortedMap<Integer, T> tailMap = circle.tailMap(hash); hash = tailMap.isEmpty() ? circle.firstKey() : tailMap.firstKey(); } return circle.get(hash); } }
注意，其中用到的SortedMap的tailMap函数，非常的到位和赞！
下面这篇文章也有点补充，但是写的太理论呆板。
http://blog.csdn.net/cywosp/article/details/23397179/
一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希（DHT）实现算法。 定哈希算法好坏的四个定义： 1、平衡性(Balance)：平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。
2、单调性(Monotonicity)：单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。
哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。
3、分散性(Spread)：在分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。
当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，
最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。
分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生，也就是尽量降低分散性。
4、负载(Load)：负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，
也可能被不同的用户映射为不同 的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。
原有的Hash方法严重的违反了单调性原则，而一致性哈希满足。3和4还不太清楚，但是一致性哈希的分散性应该不高，只是局部。
机器的删除与添加
普通hash求余算法最为不妥的地方就是在有机器的添加或者删除之后会照成大量的对象存储位置失效，这样就大大的不满足单调性了。
一致性哈希在删除和增加节点时，只影响节点附近的数据。
一致性哈希算法在保持了单调性的同时，还是数据的迁移达到了最小，这样的算法对分布式集群来说是非常合适的，避免了大量数据迁移，减小了服务器的的压力。
文中还提到，一致性哈希算法满足了单调性和负载均衡的特性以及一般hash算法的分散性。
下面这篇文章有一些实际系统（LightCloud）设计中的解决方案：
http://www.ooso.net/archives/549
LightCloud不能免俗的使用了一致性hash算法（Consistent Hashing），这是为了避免新增数据节点时发生集体拆迁事件。Consistent Hashing算法的原理请参考这里。
LightCloud的hash环有什么与众不同？
对于数据可用性的处理：
其它分布式key-value数据库采用的办法是复制数据到多个节点上，例如Amazon Dynamo的复制策略图（Dynamo是Amazon实现的一个KV存储服务系统）：
Dynamo用了许多办法解决consistent问题，系统相当复杂。而LightCloud直接使用tokyo tyrant的master-master复制功能，大幅简化了这部分的逻辑。所以在它的hash环上，单个节点其实是一对master-master的tokyo tyrant，焦不离孟不离焦。
对于查找数据的处理：
在新增数据节点时，可能会暂时影响所在局部数据的查找，如果没有办法找到正确的服务器，可能会找不到数据。
那么LightCloud继续采用流氓手段解决这个问题，他又给上了个环，保证不会发生意外。这两个hash环里的节点仍然是之前提到的tokyo tyrant双人组，一个环叫lookup，记录了每一个key保存在哪个storage节点上；另外一个环叫storage，这是真正存放数据的地方。于是它的结构图变成了下面这个样子：
就上图阐述一下：
- 一个名叫A的家伙，住在storage_SB地区(storage ring)。同时，我们还告诉记性好的lookup_B(lookup ring)，A君的地址为storage_SB。
- 很不幸或很幸运，咱们的数据膨胀到需要扩容了，于是新增了一个违章建筑storge_X，这个该死的建筑正好影响了我们找到A君。这时候，我们还可以问起记性好的lookup_B，A君住在哪个角落里啊？ —— lookup_B日道：他就住在sotrage_SB上~
- lookup这群家伙记性虽然好，但是也架不住人多，再也记不住这么多人的住址，所以又新来了几个记性好的lookup。这个会影响咱们找到storage住哪吗？答案是不会，因为没有新增别的违章storage建筑，咱们不需要问路也能找着人。
按照以上推论，一定要避免同时增加lookup和storage节点，这很可能会损失数据。
————————————————————————————————————————
记忆又有点模糊了。
来吧。再用这篇文章复习一下：http://blog.csdn.net/sparkliang/article/details/5279393
Hash 算法的一个衡量指标是单调性（ Monotonicity ），定义如下：
单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。
容易看到，上面的简单 hash 算法 hash(object)%N 难以满足单调性要求。
另外注意虚拟节点的作用，那就是提高哈希的公平性。
完。