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需要更新对照表,以此引发连锁反应
此文最初的想法是一个alexqiu跟我说的,
后来又仔细研究了一致性哈希算法
并加入了我自己的想法(热备机制、配置表保存及升级机制)
最终形成此文。
2014年4月9号:
针对此文做了技术分享,录音文件地址:http://url.cn/KxFQw5
第一个问题:此文利用IP地址(虚拟IP地址)计算哈希值的办法尚待进一步考虑和验证
第二个问题:增减服务器节点均是在"物理节点环"上完成,与“虚拟节点环”没有关系
第三个问题:除了热备,还可以在热备的基础上实现负载均衡