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

假设有n台服务器,

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

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

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

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

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

如下图所示:

gateway多节点部署架构_数据结构与算法

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

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

再向这个节点索取数据。

2.数据如何均匀的分布?(虚拟服务器)

假设服务器数量较少,

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

有些服务器就比较空闲。

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

具体的操作办法:

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

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

比如:

10.0.0.1#1

10.0.0.1#2

10.0.0.1#3

....

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

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

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

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

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

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

以此类推,

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

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

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

如下图所示

gateway多节点部署架构_数据结构与算法_02

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需要更新对照表,以此引发连锁反应

 

 

 

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

后来又仔细研究了 一致性哈希算法

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

最终形成此文。

 

 

2014年4月9号:

针对此文做了技术分享,录音文件地址: http://url.cn/KxFQw5

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

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

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