6. Redis Cluster 常见运维开发问题和故障转移

1. 集群完整性：

　cluster-require-full-coverage yes

• 设置集群中全部16384个槽都可用时才对外提供服务，保证集群完整性，默认为 yes
• 节点故障或者正在故障转移时整个集群对外不可用，此时会报 (error) CLUSTERDOWN The cluster is down
• 此配置大多数业务无法容忍，建议设置为 no，此时即使部分节点故障其他节点仍能提供服务 

2. 带宽消耗：

　官方建议：<= 1000

　三个方面

• 消息发送频率：节点发现与其它节点最后通信是时间超过 cluster-node-timeout/2 时会直接发送 ping 消息
• 消息数据量：slots 槽数组（2KB）和整个集群 1/10 的状态数据（10个节点状态数据约 1KB）
• 节点部署机器规模：集群分布的机器越多且每台机器划分的节点数越均匀，则集群内整体的可用带宽越多

　带宽消耗优化建议：

• 集群拆分，不同的业务用不同的集群，避免多个业务使用同一个集群
• cluster-node-timeout 设置，值越大，集群带宽消耗越小
• 集群分布到多台服务器，避免单台服务器上有多个集群共同消耗带宽

3. Pub/Sub：

• 集群的发布/订阅会将一个节点上的数据同步到所有节点，加重带宽消耗
• 解决方法：单独走一套 Redis Sentinel

4. 集群倾斜：

1. 数据倾斜
   
   1. 节点间 slot 分配不均，有的 slot 分配少，有的多
   2. 不同 slot 对应的 key value 数值差异较大
   3. 包含 bigkey
   4. 内存相关配置不一致
2. 请求倾斜：
   1. 某些大量使用的 key 或 bigkey 被分配到了相同的 slot 或 node，（热点 key）

5. 集群限制：

• key 的批量操作支持有限：例如 mget、mset 必须在同一个 slot
• key 事务和 Lua 支持有限：操作的key 必须在同一个节点
• key 是数据分区的最小粒度：不支持 bigkey 分区
• 不支持多个数据库：集群模式下只有一个 db 0
• 复制只支持一层：不支持树形复制结构

6. Redis 故障发现

• 主观下线：某个节点认为另一个节点不可用，就设置这个节点为主观下线，具体是节点间的最后心跳时间超过 node-timeout，即可标记为 pfail 状态
• 节点将自己认为主观下线的其他节点信息通过心跳发送给其他可用节点，其他节点更新故障列表
• 客观下线：当半数以上持有槽的主节点都标记某个节点主观下线，即认为这个节点客观下线
• 尝试客观下线：先计算有效下线报告数量，如果大于槽节点总数一半，更新为客观下线，向集群广播下线节点的 fail 消息，通知集群内所有节点标记故障节点为客观下线，通知故障节点的从节点触发故障转移流程

7.Redis 故障恢复

1. 资格检查
   1. 每个从节点检查与故障主节点的断线时间
   2. 超过 cluster-node-timeout * cluster-slave-validity-factor 取消资格
   3. cluster-slave-validity-factor 默认为10
2. 准备选举时间
   1. 根据从节点数据偏移量来设定每个节点的选举时间，偏移量越大的从节点代表数据越新，其选举时间也越早，更可能被选为新的 master
3. 选举投票
   1. 集群中的每个其他的 master 节点对选定的从节点投票，投票数 > 总主节点数 N / 2 + 1，代表可以替换原来的主节点
4. 替换主节点
   1. 当前从节点取消复制变为主节点
   2. 执行 clusterDelSlot 撤销故障主节点负责的 slot，并执行 clusterAddSlot 把这些槽分配给自己
   3. 向集群广播自己的 pong 消息，表明已经替换了故障节点