深入Redis：复杂的集群

广义的集群，可能说只要是多台机器组成了分布式系统，就可以称之为集群。

狭义的集群，指的是Redis提供的集群模式，这个集群模式之下，主要是解决存储空间不足的问题，以及如何拓展存储空间。

之前的哨兵模式，本质上还是一个节点存储数据，要求一个主节点/从节点存储整个数据的“全集”。

假设有1TB的数据，拿两台机器和四台机器来存，每台机器就只需要存储512G和256G，只要机器的规模足够多就可以存储任意大小的数据了。

但是此处把数据分成多份，应该怎么分？

分片(Sharding)

• Master1 和 Slave11 和 Slave12保存的是同样的数据，占总数据的1/3
• Master2 和 Slave21 和 Slave22保存的是同样的数据，占总数据的1/3
• Master3 和 Slave31 和 Slave32保存的是同样的数据，占总数据的1/3

这三组数据存储的数据都是不同的，每个红框的部分可以称之为一个分片。如果全量数据进一步增加，只需要再增加更多的分片就可以解决。

具体来说，如何分片？存储一个key的时候，这个数据应该存储再哪个分片上？读取的时候又应该去哪个分片读取？有比较主流的三个方式：

哈希求余

借鉴了哈希表的基本思想，用hash函数把一个key映射到整数，再针对数据的长度求余，就可以得到一个数组下标。

假设有个key，现在有3个分片。根据这个key来计算hash值，再把这个结果%3，结果是多少就分到哪个片区上。后续获取key的时候，也是针对这个key求hash，再对N求余，就可以找到对应的片区编号了。

优点：简单高效，数据分配均匀

缺点：一旦需要进行扩容，片区数目改变了，原有的映射规则就不起作用了。所有的查询操作都查不到key。此时要进行数据之间的片区转移，重新排列，以满足新的映射规则。这样的数据转移，资源消耗量极大。

如上可以看到，整个扩容一共21个key，只有3个key没有进行搬运，其他的都要搬运。

一致性哈希算法

为了改进上面的方法，能够高效进行扩容，“一致性哈希算法”就诞生了。

我们把2^32 -1均匀地映射到一个圆环上面，并且规律的切分好1号分片，2号分片，3号分片。

此时有一个key，计算这个key的hash值，算出来的值顺时针往下找，找到的第一个分片是哪个就属于哪个分片。

扩容的时候，原有的分片在环上的位置不动，只需要在环上安排一个新的分片即可。此时只需要把原来分片里面的部分数据，搬运给新的分片即可。剩下两个分片里面的数据和区间都是不变的。

优点：大大降低了扩容的时候数据搬运的规模，提高了扩容操作的效率。

缺点：数据分配不均匀，数据倾斜。

哈希槽分区算法

为了解决搬运成本高和数据分配不均匀，引入了哈希槽（hash slots）算法。

 hash_slot = crc16(key) % 16384
  哈希槽    计算hash的算法

、相当于把整个哈希值，映射到16384个槽位上，也就是[0,16383]。

再把这些槽位均匀的分配给每个分片，每个分片的节点都需要自己记录持有哪些分片。

假设当前有三个分片，一种可能的分配方式：

• 0号分片：[0,5461]，共5462个槽位
• 1号分片：[5462,10923]，共5462个槽位
• 2号分片：[10924,16383]，共5460个槽位

这里的分片规则是很灵活的，每个分片持有的槽位也不⼀定连续，每个分片的节点使用位图来表示自己持有哪些槽位。对于16384个槽位来说，需要2048个字节(2KB)大小的内存空间表示。

如果需要增加一个分片，就可以针对原来的槽位进行重新分配，比如把之前每个分片持有的槽位，各拿出来一点，分给新的分片。

• 0号分片：[0, 4095]，共4096个槽位。
• 1号分片：[5462, 9557]，共4096个槽位。
• 2号分片：[10924, 15019]，共4096个槽位。
• 3号分片：[4096, 5461] + [9558, 10923] + [15019, 16383]，共4096个槽位。

在实际使用Redis集群分片的时候，我们不需要手动指定哪些槽位分配给某个分片，只需要告诉某个分片应该持有多少个槽位即可。Redis会自动完成后续的槽位分配，以及对应的key搬运工作。

问题一：Redis集群是最多有16384个分片吗？

如果一个分片只有一个槽位，这对于集群的数据均匀是难以保证的。Redis作者建议分片数不应该超过1000。

问题二：为什么是16384个槽位？

Redis作者的回答：

节点之间通过心跳包通信。心跳包中包含了该节点持有哪些slots，这个是使用位图这样的数据结构表示的。表示16384（16k）个slots，需要的位图大小是2KB。如果给定的slots数更多了，比如65536个了，此时就需要消耗更多的空间，8KB位图表示了。8KB对于内存来说不算什么，但是在频繁的网络心跳包中，还是一个不小的开销。

另一方面，Redis集群一般不建议超过1000个分片。所以16k对于最大1000个分片来说是够用的，同时也会使对应的槽位配置位图体积不至于很大。

集群搭建

集群搭建基于docker，搭建一个集群，每一个节点都是一个容器。只需要创建11个redis节点，这些redis的配置文件内容大同小异。但是11个如果要手动添加的话太繁琐了，此时就可以使用脚本来批量生成。在Linux上，以 .sh 为后缀结尾的文件，称为“shell脚本”。

首先要停止原来启动的节点。分别到redis-data和redis-sentinel文件夹里，启动运行docker-compose down 命令就可以停止掉原来的docker容器。

在redis文件夹中创建reids-cluster，内部创建好两个文件，再把.sh文件的内容完成，就可以通过bash命令启动.sh文件了。很方便的，11个redis文件夹就被创建出来了。

#!/bin/bash

# 创建Redis实例目录并生成配置文件
for port in $(seq 1 9); do
  mkdir -p redis${port}/
  touch redis${port}/redis.conf
  cat << EOF > redis${port}/redis.conf
port 6379
bind 0.0.0.0
protected-mode no
appendonly yes
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-announce-ip 172.30.0.10${port}
cluster-announce-port 6379
cluster-announce-bus-port 16379
EOF
done

# 注意：cluster-announce-ip 的值有变化

# 创建额外的Redis实例目录并生成配置文件
for port in $(seq 10 11); do
  mkdir -p redis${port}/
  touch redis${port}/redis.conf
  cat << EOF > redis${port}/redis.conf
port 6379
bind 0.0.0.0
protected-mode no
appendonly yes
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
cluster-announce-ip 172.30.0.1${port}
cluster-announce-port 6379
cluster-announce-bus-port 16379
EOF
done

每个redis文件夹中都有一个redis.conf文件，并且每个配置文件都不同。区别在于每个配置中的cluster-announce-ip都是不同的，其他部分都相同。这里的ip要和yml中的ip对应上。

当我们确认docker和redis都关闭后，此时执行启动容器的命令，就可以看到11个redis服务器都被启动起来了。

但是到此，我们还没有把这些redis配置成集群，他们还只是各干各的。

通过命令可以把前9个主机构建成集群，后两个主机暂时不用：

redis-cli --cluster create 172.30.0.101:6379 172.30.0.102:6379 
172.30.0.103:6379 172.30.0.104:6379 172.30.0.105:6379 172.30.0.106:6379 
172.30.0.107:6379 172.30.0.108:6379 172.30.0.109:6379  --cluster-replicas 2
最后一串字符指的是：从节点2个

此时，redis节点被自动分配好了主节点和从节点，并且会自动分配好16384个槽位。此时101-109九个节点，是一个整体。使用客户端连接上任意一个节点，本质上都是等价的。

cluster nodes 
查看当前集群的信息

设置成集群模式之后，当前数据就分片了。可以在启动redis-cli的时候，加上 -c 选项，客户端发现当前key的操作不在当前分片上的时候，就能够自动的重定向到对应的分片主机。

但是也需要注意，如果key是分散在不同的分片上，用之前的操作就可能会有些问题。

故障转移

此处的故障转移，和哨兵那里的还不太一样~手动停止一个主节点，来观察效果。

集群中的所有节点都会周期性的使用心跳包进行通信。进行一系列判定之后，最终才会把某个节点标记成FAIL（客观下线）。

如果我们停掉了主节点1，此时会有一个slave节点变成新的主节点，哪怕我们重新启动原来的主节点1，这个节点也仅仅是变成slave。

Reft算法

上述选举的过程就称之为Raft算法，这是一种在分布式系统中广泛使用的算法。再随机休眠时间的加持下，基本上就是谁先唤醒，谁就能竞选成功。

集群扩容

现在101-109，9个主机构成了3主6从结构的集群了。此时我们把110和111主机也加入到集群中去，以110为master，111为slave，把数据分片从3变成4。

集体扩容是一件风险高、成本高的操作！

把新的主节点加入到集群

 redis-cli --cluster add-node 172.30.0.110:6379 172.30.0.101:6379

add-node后的第⼀组地址是新节点的地址，第⼆组地址是集群中的任意节点地址。

重新分配slots

 redis-cli --cluster reshard 172.30.0.101:6379

reshard后的地址是集群中的任意节点地址。

执行之后，会进入交互式操作，redis会提示输入以下内容： 

• 多少个slots要进行reshard?(此处我们填写4096)
• 哪个节点来接收这些slots?(此处我们填写 172.30.0.110 这个节点的集群节点id) 
• 这些slots从哪些节点搬运过来?(此处我们填写all，表示从其他所有的节点都进行搬运)

给新的主节点添加从节点

redis-cli --cluster add-node 172.30.0.111:6379 172.30.0.101:6379 --cluster
slave --cluster-master-id [172.30.1.110 节点的nodeId]

此外，还有集群缩容，代码连接集群等知识，考虑到本文篇幅就不再继续了，接下来，我们会开启缓存的学习~