背景

直播CDN系统通常用L1或者L2的缓存集群，缓解中心服务器压力。缓存集群需要满足2个条件

1. 写：同一份数据写在一台缓存CDN服务器上，至少是同一节点上；
2. 读：对于这份数据的读取，能尽快索引到缓存CDN服务器上；

传统方案

1. N台服务器，编号0到N-1
2. 请求作为key值，计算哈希值h = Hash(key)%N，定向到指定服务器

存在问题

• 哈希重定向

1. 出现故障节点，大量请求需要迁移到其他节点
2. 集群扩容时，为了负载均衡，也需要迁移部分缓存请求。

• 举例

以N为3为例，请求0分配到0%3=0节点a，请求3分配到3%3=0节点a如下，扩容节点d后，出现大量请求迁移。

#节点a：请求0，请求3，请求6，请求9
#节点b：请求1，请求4，请求7
#节点c：请求2，请求5，请求8

#====扩容 节点d====#

#节点a：请求0，请求4，请求8
#节点b：请求1，请求5，请求9
#节点c：请求2，请求6
#节点d：请求3，请求7

哈希环方案

上述哈希重定向问题，出现的根本原因是哈希空间是个开放空间，所以解决方法就是把这个哈希空间封闭掉，采用哈希环来解决这个问题。

即采用类似桶排序的思路，建立请求和服务器之间的关系。

举例

1. 请求0到请求9，分别ascii码是48-57，乘以4；
2. 节点a到z的ascii码分别是97-122，加104；

定义哈希环的取值空间如下：

# 请求0：192
# 请求1：196
# 请求2：200
                        # 节点a：203
# 请求3：204
# 请求4：208
                        # 节点g：209
# 请求5：212
# 请求6：216
# 请求7：220
# 请求8：224
# 请求9：228            # 节点z：228

定义哈希环规则如下：

# 小于等于203的请求，调度到 节点a
# 大于203，小于等于209的请求，调度到 节点g
# 大于209，小于等于228的请求，调度到 节点z
# 大于228的请求，调度到 节点a

调度结果

#节点a：请求0，请求1，请求2
#节点g：请求3，请求4
#节点z：请求5，请求6，请求7，请求8，请求9

#====扩容 节点n，n的hash值是216====#

#节点a：请求0，请求1，请求2
#节点g：请求3，请求4
#节点n：请求5，请求6
#节点z：请求7，请求8，请求9

效果图

扩展细节

• 节点不均匀的问题：增加虚拟节点，例如服务器IP后加编号，节点1#1，节点1#2，都是节点1，但是虚拟成了2个节点。虚拟节点数一般是32或者32的倍数。
• 优雅扩容的方法：扩容机器过多时，直接加入会导致大量缓存失效，一点点慢慢扩容，会导致扩容时间很长，增加运维成本。通常采用的方案为【双环并跑策略】，即：

# 哈希环h1：节点a、b、c

# === 扩容节点d、e、f === #

# 哈希环h2：节点a、b、c，节点d、e、f

# 新请求 ---> 哈希环h2 ---> 哈希环h1

节点a、b、c组成的哈希环h1，节点a、b、c与新增机器d、e、f组成新的哈希环h2，h1和h2并跑，新数据写入新环h2，读数据先从h2读，h2读不到，再从h1读。命中率达到阈值后，下线哈希环h1调度策略。