Redis集群

定义

---

Redis集群是一个提供多个redis节点间共享数据的程序集。

优点： 支持多个master、自带sentinel故障转移机制、资源共享 (只需连接集群中任何一个redis节点即可获取所有数据)。
缺点： redis集群不保证数据的强一致性，即在特定的条件下，也可能会丢失一部分写请求。

哈希槽

---

redis集群没有使用一致性哈希算法，而是引入了哈希槽(slot)的概念。redis集群有16384个槽位，每个key通过CRC16算法校验后，再对16384取模来决定放到哪个槽位。

哈希槽为什么是16384？CRC16算法产生的hash值有16bit，该算法可以产生2¹⁶=65536个值，那么数据可以分布在0~65536之间，有更大的65536不用，而选择16384？
1. 每秒钟redis需要发送一定数量的ping消息作为心跳包，如果槽位是65536=8kb，那么ping消息的消息头太大了，浪费带宽。而如果槽位是16384=2kb，消息头占用的空间就比较小。
2. 集群节点越多，心跳包的消息体内携带的数据就越多。如果节点过1000个，也会导致网络拥堵。因此redis作者不建议集群节点数量超过1000个。那么对于节点数在1000以内的redis集群，16384个槽位也够用了，没有必要拓展到65536个。
3. redis主节点的配置信息中它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中会对bitmap进行压缩。如果bitmap的填充率slots/n越大(n表示节点数)，那么bitmap的压缩率就越低，即槽位越多，节点数越少，bitmap的压缩率就越低。

分片

---

使用redis集群时会将所有的数据分散到每一个redis机器上，集群中每个redis实例都被认为是整个数据的一个分片。

槽位映射

哈希取余分区

---

通过hash(key) mod n个机器数计算出哈希值，决定key最终映射到哪个redis节点上。

优点： 每台redis服务器固定处理一部分请求，类似于负载均衡的效果。
缺点： 如果需要进行扩容或缩容，导致节点数量发生变化，key的映射关系就需要重新进行计算。当某个redis服务器宕机后，会导致全部的数据重新洗牌。

一致性哈希算法分区

---

一致性哈希算法将所有的redis节点排列在哈希环上，通过计算hash(key)确定数据在哈希环上的位置，从此位置沿着环顺时针找到临近的节点，并将数据存放到该节点上。一致性哈希算法目的是解决分布式缓存数据变动和映射问题，当redis服务器个数发生变化时，尽量减少影响客户端到服务器的映射关系。

优点： 扩容和缩容只影响哈希环中顺时针方向上的相邻节点，对其它节点没有影响，具有一定的容错性和扩展性。
缺点： 当redis节点太少时，容易因为节点分布不均匀而造成数据倾斜 (大部分数据集中在某一台redis服务器上) 问题。

哈希槽分区

---

redis集群中内置了16384个哈希槽，redis会根据节点数量大致均等的将哈希槽映射到不同的节点。当需要在redis集群中放置一个key-value时，redis先对key使用CRC16算法计算出一个结果，然后用该结果对16384求余数，这样每个key都会对应一个编号在0~16383之间的哈希槽。
HASH_SLOT = CRC16(key) mod 16384

集群实战案例

---

本次使用三台机器，在每台机器上搭建一主一从，演示Redis三主三从集群实战案例。

1. 拷贝配置文件

三台机器新建/myredis/cluster目录：mkdir -p /myredis/cluster
6381：cp /opt/redis-7.0.9/redis.conf /myredis/cluster/redis6381.conf
6382：cp /opt/redis-7.0.9/redis.conf /myredis/cluster/redis6382.conf
6383：cp /opt/redis-7.0.9/redis.conf /myredis/cluster/redis6383.conf
6384：cp /opt/redis-7.0.9/redis.conf /myredis/cluster/redis6384.conf
6385：cp /opt/redis-7.0.9/redis.conf /myredis/cluster/redis6385.conf
6386：cp /opt/redis-7.0.9/redis.conf /myredis/cluster/redis6386.conf

2. 配置文件修改

上述以redis6381.conf为例，剩余几个配置文件修改与其类似，特别注意端口号要使用自己对应的端口号

3. 启动六个redis服务

关闭防火墙：systemctl stop firewalld.service

先保证三台机器之间能够相互ping通，其次关闭三台机器的防火墙，最后启动六个redis服务

4. 构建主从关系
redis-cli -a 111 --cluster create --cluster-replicas 1 192.168.195.133:6381 192.168.195.133:6382 192.168.195.135:6383 192.168.195.135:6384 192.168.195.136:6385 192.168.195.136:6386

--cluster-replicas 1：表示为每个master创建一个slave节点

5. 查看集群信息：cluster nodes

本次三主三从redis集群真实的主从分配关系如下：

master	slave	槽位区间
192.168.195.133:6381	192.168.195.135:6384	0~5460
192.168.195.135:6383	192.168.195.136:6386	5461~10922
192.168.195.136:6385	192.168.195.133:6382	10923~16383

集群读写问题演示

---

防止路由失效，在启动redis客户端时添加-c参数，即redis-cli -a 密码 -p 端口 -c

查看指定key映射的槽位：cluster keyslot key

查看指定槽位是否被占用：cluster countkeysinslot 槽位号

主从容错切换

---

当master(6381)宕机后，原来的slave(6384)变成了新的master

原来的master(6381)宕机重启后，变成了新的slave，对应的master为6384

集群节点从属调整：cluster failover

在新的slave(6381)上执行cluster failover命令，6381和6384发生主从切换，即6381变成了master，6384变成了slave

集群扩容实战案例

---

在原有三主三从Redis集群环境上扩容，新增一主一从，构成四主四从的集群环境。

1. 拷贝配置文件

6387：cp /opt/redis-7.0.9/redis.conf /myredis/cluster/redis6387.conf
6388：cp /opt/redis-7.0.9/redis.conf /myredis/cluster/redis6388.conf

新增6387和6388构成一主一从，配置文件修改参考前面redis6381.conf的修改

2. 启动redis服务

3. 将6387作为master加入集群

新节点加入集群：redis-cli -a 密码 --cluster add-node 新节点ip:端口 集群中的节点ip:端口

在上图命令中，6387作为master新增节点，6381是集群中原有节点的领路人

检查集群节点分配信息：redis-cli -a 111 --cluster check 节点ip:端口

从上图可以看到，master(6387)还没有被分配对应的槽位和slave

4. 重新分配槽位

redis-cli -a 111 --cluster reshard 节点ip:端口

在上图中4096表示本次想要分配4096个槽位，因为本次扩容为四主四从集群环境，所以16384/4=4096。将这些槽位分配给ID为f04072b4ba35e9823826faa4e7802c21a2a72233的节点，即6387节点。最后输入all即可

从上图可以看出，四个master的都有4096个槽位，master(6387)还没有 slave
master(6381)槽位区间：1365 ~ 5460
master(6383) 槽位区间：6827 ~ 10922
master(6385)槽位区间：12288 ~ 16383
master(6387)槽位区间：0~1364，5461 ~ 6826，10923 ~ 12287
可以看到 master(6387)有三个槽位区间，这是因为重新分配槽位成本太高，所以从6381、6383、6385三个节点上分别匀出一部分槽位给新节点6387

5. 将6388作为slave挂到master(6387)上

redis-cli -a 密码 --cluster add-node 新的slave节点ip:端口 对应master节点ip:端口 --cluster-slave --cluster-master-id 对应master节点ID

从上图可以看出，master(6387)添加slave(6388)成功，完成了集群扩容

集群缩容实战案例

---

在四主四从Redis集群环境上缩容，下线一主一从，构成三主三从的集群环境。

1. 获取slave(6388)节点ID

2. 在集群中删除slave(6388)节点

redis-cli -a 密码 --cluster del-node 被删除节点ip:端口 被删除节点ID

3. 将6387的槽位全部分配给6381

重新分配槽位：redis-cli -a 111 --cluster reshard 192.168.195.133:6381

上图表示将6387的4096个槽位全部分配给6381

从上图可以看出，master(6381)现在有8192个槽位，并且有两个slave(6384和6387)

4. 删除6387节点

redis-cli -a 111 --cluster del-node 192.168.195.136:6387 f04072b4ba35e9823826faa4e7802c21a2a72233

5. 检查集群信息

redis-cli -a 111 --cluster check 192.168.195.133:6381

集群是否完整才能对外提供服务

---

cluster-require-full-coverage：默认为yes，即需要集群的完整性，才可以对外提供服务，推荐使用默认值yes。如果在三主三从的集群环境中，任何一个一主一从都线下了，那么集群对外可提供三分之二的数据，整个集群是不完整的，在这种情况下，redis默认对外不提供服务。但是，如果你想要集群在不完整的情况下任然对外提供服务，将其设置为no即可。这样即使有三分之一的数据不可用，但也有三分之二的数据是可以正常使用的

总结

---

以上主要介绍了Redis集群的配置和使用，演示了Redis三主三从的集群实战案例，以及在现有的集群环境上怎样扩容和缩容。想学习Redis更多实战实用技巧的小伙伴，请关注后期发布的文章，认真看完一定能让你有所收获。