1.数据是如何被分布到多个服务器上的？（一致性哈希算法）

假设有n台服务器，

计算这n台服务器的IP地址的哈希值，

把这些哈希值从小到大按顺时针排列组成一个“服务器节点环”，

客户端需要存储一系列的“键值对”到这些服务器上去，

计算这些“键”的哈希值，

看看这些“键”的哈希值落在“服务器环”的哪些区间，

如下图所示：

根据上图示意，数据将被存储在“顺时针方向上的下一个服务器节点”

读取数据时，也是先根据“键”的哈希值，找到这个服务器节点，

再向这个节点索取数据。

2.数据如何均匀的分布？（虚拟服务器）

假设服务器数量较少，

很可能造成有些服务器存储的数据较多、承担的压力较大，

有些服务器就比较空闲。

这时就要把一台服务器虚拟化成多台服务器，

具体的操作办法：

在计算服务器对应的哈希值时

可以在IP地址字符串加多个“尾缀”

比如：

10.0.0.1#1

10.0.0.1#2

10.0.0.1#3

....

这样，一台物理服务器就被虚拟化成多台服务器，

对应“服务器环”上的多个节点。

3.如何实现数据的热备份？

以顺时针方向看“服务器环”

当有客户端把数据存储在第1台服务器上后，

第1台服务器负责把该数据拷贝一份给第2台服务器

以此类推，

也就是说“服务器环”上的每一个节点，都是上一个节点的热备份节点

同时，一个服务器上存了两类数据，一类是自身的业务数据，一类是上一节点的热备数据。

注意：这里所说的服务器，都是物理服务器，不是虚拟服务器。

如下图所示

4.如何让客户端发现所有服务端？

每个服务器节点都要维护一个对照表

这个对照表中包含所有服务器，（IP地址和IP地址的哈希值对照表）

配置客户端时，只要让客户端知道任意一个服务器的IP地址即可

客户端可以通过获取这个服务器的对照表从而知道所有的服务器

客户端初始化的时候，这个对照表也存储在客户端一份

客户端根据这个对照表来存取数据

注意：这个对照表是有一个版本号的，具体的用途见下面的描述

5.如何应对服务器异常？

假设数据在节点1上读写不成功，

我们就认为这个节点存在异常，要把它从服务器群集中拿掉。

客户端先在节点2（节点1的热备节点）上完成相应的读写工作，这时客户端就可以去做其他工作了。

然后节点2向节点0索取数据（这些数据是本应该备份在节点1上的数据）

然后节点2向节点3推送数据(这些数据是节点1上的数据，现在要备份在节点3上)

然后节点2更新其对照表，把节点1从其对照表中移除，并更新对照表的版本号

当有任何客户端与节点2交互的时候，

就会发现节点2上的对照表的版本号比自己持有的对照表要高

此时，客户端就更新自己的对照表

这些客户端再与其他服务器交互的时候

其他服务器发现客户端携带的对照表版本号比自己持有的要高

此时，其他服务器更新自己的对照表

注意：这是一个“发散式的连锁反应”，不会影响生产。

还可以让节点2告知节点3需要更新对照表

当节点3更新完之后，再让节点3告知节点4....

以此引发“环式的连锁反应”

注意：

当“服务器环”上连续两台服务器同时故障的时候，那么这个系统就崩溃了

可以对数据做两次热备份，以提高安全性，但性能和硬件利用率会有所损耗。

6.如何增加服务器？

首先需要通过配置让这台服务器知道节点环上的任意一台服务器的IP地址（假设是10.0.0.1）

此服务端运行之后，他就会从10.0.0.1上获取对照表，

以此知道自己在节点环中的具体位置，

它首先需要从它的下一个节点中迁移一部分数据（也就是它上一个节点热备份的一部分数据）

然后从上一个节点中索取一部分数据(也就是该自己存储的一部分数据)

然后它把自己加入对照表中，

然后告知10.0.0.1需要更新对照表，以此引发连锁反应

 

 

 

此文最初的想法是一个 跟我说的，

后来又仔细研究了 法

并加入了我自己的想法（热备机制、配置表保存及升级机制）

最终形成此文。

 

 

2014年4月9号：

针对此文做了技术分享，录音文件地址：

第一个问题：此文利用IP地址（虚拟IP地址）计算哈希值的办法尚待进一步考虑和验证

第二个问题：增减服务器节点均是在"物理节点环"上完成，与“虚拟节点环”没有关系

第三个问题：除了热备，还可以在热备的基础上实现负载均衡