7 故障转移
7.1 故障发现
Redis Cluster通过ping/pong消息实现故障发现：不需要sentinel。ping/pong不仅能传递节点与槽的对应消息，也能传递其他状态，比如：节点主从状态，节点故障等
故障发现就是通过这种模式来实现，分为主观下线和客观下线：
7.1.1 主观下线
定义
某节点认为另一节点不可用，这仅代表一个节点对另一节点的判断，不代表所有节点的认知。
流程
节点-1定时发ping消息给节点-2
若发送成功，代表节点-2正常运行，节点-2会响应PONG消息给节点1，节点1更新与2的最后通信时间
若发送失败，则节点-1与节点-2间通信异常判断连接，在下一定时任务周期时，仍然会与节点2发送ping消息
若节点-1发现与节点-2最后通信时间超过node-timeout，则把节点2标识为pfail状态
7.1.2 客观下线
定义
当半数以上持有槽的主节点都标记某节点主观下线。可以保证判断的公平性。
集群模式下，只有主节点(master)才有读写权限和集群槽的维护权限，从节点(slave)只有复制的权限。
流程
某个节点接收到其他节点发送的ping消息，如果接收到的ping消息中包含了其他pfail节点，这个节点会将主观下线的消息内容添加到自身的故障列表中，故障列表中包含了当前节点接收到的每一个节点对其他节点的状态信息
当前节点把主观下线的消息内容添加到自身的故障列表之后，会尝试对故障节点进行客观下线操作
7.2 故障恢复
从节点接收到它的主节点客观下线的通知，则进行故障恢复。
资格检查
对从节点的资格进行检查，只有难过检查的从节点才可以开始进行故障恢复
每个从节点检查与故障主节点的断线时间
超过cluster-node-timeout * cluster-slave-validity-factor数字，则取消资格
cluster-node-timeout默认为15秒，cluster-slave-validity-factor默认值为10
如果这两个参数都使用默认值，则每个节点都检查与故障主节点的断线时间，如果超过150秒，则这个节点就没有成为替换主节点的可能性
准备选举时间
使偏移量最大的从节点具备优先级成为主节点的条件。
选举投票
对选举出来的多个从节点进行投票，选出新的主节点。
替换主节点
- 当前从节点取消复制变成离节点。(slaveof no one)
- 执行cluster del slot撤销故障主节点负责的槽，并执行cluster add slot把这些槽分配给自己
- 向集群广播自己的pong消息，表明已经替换了故障从节点
8 开发运维常见问题
8.1 集群完整性
cluster-require-full-coverage默认为yes，即集群中所有节点都在服务且16384个槽都可用，集群才会提供服务，以保证集群完整性。
当某节点故障或者正在故障转移时获取数据会提示：(error)CLUSTERDOWN The cluster is down
但是大多数业务都无法容忍，建议把cluster-require-full-coverage设为no
8.2 带宽消耗
Redis Cluster节点之间会定期交换Gossip消息，以及做一些心跳检测
官方建议Redis Cluster节点数量不要超过1000个,当集群中节点数量过多时，会产生不容忽视的带宽消耗
消息发送频率：节点发现与其他节点最后通信时间超过cluster-node-timeout /2时，会直接发送PING消息
消息数据量：slots槽数组(2kb空间)和整个集群1/10的状态数据(10个节点状态数据约为1kb)
节点部署的机器规模：集群分布的机器越多且每台机器划分的节点数越均匀，则集群内整体的可用带宽越高
带宽优化
- 避免使用’大’集群：避免多业务使用一个集群，大业务可以多集群
- cluster-node-timeout:带宽和故障转移速度的均衡
- 尽量均匀分配到多机器上：保证高可用和带宽
8.3 Pub/Sub广播
- 在任意一个cluster节点执行publish，则发布的消息会在集群中传播，集群中的其他节点都会订阅到消息，这样节点的带宽的开销会很大
- publish在集群每个节点广播，加重带宽
解决方案
单独“走”一套redis sentinel。就是针对目标的几个节点构建redis sentinel，在这个里面实现广播。
8.4 集群倾斜
分布式数据库存在倾斜问题是比较常见的。集群倾斜也就是各个节点使用的内存不一致
数据倾斜原因
- 节点和槽分配不均，如果使用redis-trib.rb工具构建集群，则出现这种情况的机会不多
redis-trib.rb info ip:port查看节点，槽，键值分布 redis-trib.rb rebalance ip:port进行均衡(谨慎使用)
- 不同槽对应键值数量差异比较大
- CRC16算法正常情况下比较均匀
- 可能存在hash_tag
- cluster countkeysinslot {slot}获取槽对应键值个数
- 包含bigkey：例如大字符串，几百万的元素的hash,set等
- 在从节点：redis-cli --bigkeys
- 优化：优化数据结构
- 内存相关配置不一致
- hash-max-ziplist-value：满足一定条件情况下，hash可以使用ziplist
- set-max-intset-entries：满足一定条件情况下，set可以使用intset
- 在一个集群内有若干个节点，当其中一些节点配置上面两项优化，另外一部分节点没有配置上面两项优化
- 当集群中保存hash或者set时，就会造成节点数据不均匀
- 优化：定期检查配置一致性
- 请求倾斜：热点key
- 重要的key或者bigkey
- Redis Cluster某个节点有一个非常重要的key，就会存在热点问题
优化
- 避免bigkey
- 热键不要用hash_tag
- 当一致性不高时，可以用本地缓存+ MQ(消息队列)
9 读写分离
- 只读连接
集群模式下，从节点不接受任何读写请求。 - 当向从节点执行读请求时，重定向到负责槽的主节点
- readonly命令可以读：连接级别命令，当连接断开之后，需要再次执行
readonlyredis cluster 默认slave 也是不能读的，如果要读取，需要执行 readonly，就可以了。
读写分离：更加复杂（成本很高，尽量不要使用）
同样的问题：复制延迟，读取过期数据，从节点故障
修改客户端：cluster slaves {nodeId}
10 集群优劣
集群的限制
- key批量操作支持有限：例如mget,mset必须在一个slot
- key事务和Lua支持有限：操作的key必须在一个节点
- key是数据分区的最小粒度：不支持bigkey分区
- 不支持多个数据库：集群模式下只有一个db0
- 复制只支持一层：不支持树形复制结构
集群不一定好
- Redis Cluster满足容量和性能的扩展性，很多业务’不需要’
- 大多数时客户端性能会’降低’
- 命令无法跨节点使用：mget,keys,scan,flush,sinter等
- Lua和事务无法跨节点使用
- 客户端维护更复杂：SDK和应用本身消耗(例如更多的连接池)
很多场景Redis Sentinel已经够用了
参考
https://www.slideshare.net/iammutex/redis-cluster
https://zhuanlan.zhihu.com/p/105569485
https://sunweiguo.github.io/2019/02/01/redis/Redis-Cluster%E7%90%86%E8%AE%BA%E8%AF%A6%E8%A7%A3/
https://redis.io/topics/cluster-spec
