数据面
Gossip
集群是一个分片内的所有副本不能共一台机器，如果不同分片的副本共一台机器。该部署方式会导致单机故障影响多个副本，集群可用性低，共识达成慢，故障恢复时间较长。
N 个 Master 的集群，1 个 Master 节点挂掉仍然可用的概率是：
1-(1/(N*2-1))
代理模式 Proxy Mode
cross-slots query ，等同于在 Proxy 层扇出。单一分片故障的情况下，业务侧的重试会增加集群其他分片的流量，进而影响服务的稳定性。其次，由于 Redis 自身原子性的保证，目前 Redis 协议并不支持部分失败。
哈希槽 vs 分片
在限流、熔断等场景下，节点 IP 并不适合作为逻辑概念使用。其一在于会发生主从切换，其二在于硬件维护场景下节点迁移 IP 会发生变化。而 Slot 代表的是数据的逻辑概念，跟机器并不存在绑定关系。缺少 Shard 的概念，将难以基于 Shard 实现相关功能
备注：Redis 7.2 加入了 Shard 的概念，CLUSTER SLOTS 的相关命令也逐渐被 CLUSTER SHARDS 替代
重新分片 Resharding
当正在对 key 所属的 hash slots 进行重新分片时，多 key 操作可能变得不可用。
更具体地说，即使在重新分片期间，针对所有存在且仍哈希到同一 hash slot（重新分片的源节点或目标节点）的多 key 操作仍然可用。
对不存在的 key 或在重新分片期间被拆分到源节点和目标节点之间 key 的多 key 操作将产生 -TRYAGAIN 错误。客户端可以在一段时间后尝试该操作，或报告错误。
一旦指定 hash slot 的迁移终止，该 hash slot 的所有多 key 操作都将再次可用。
同步搬迁遇到 Big key 会阻塞 Redis 处理请求，导致请求（延迟）毛刺
从可读 Read from Slave
因为 migrating 状态没有被同步到副本，所以当重新分片期间被拆分到源节点和目标节点之间 key 的多 key 操作，存在在另外一个节点的 key 读取到的数据为 nil
复制 Replication
全量同步导致内存翻倍、数据复制导致 CPU 毛刺
Redis 并不适合绑定在单个 CPU 上。Redis fork 会运行 CPU 密集型的后台任务，如BGSAVE 或 BGREWRITEAF。如果 Redis 实例绑定在给定核心上，后台作业也将在同样的核心，抢占 CPU 核心，与 Redis 事件竞争 CPU 的循环。它产生了巨大的性能 Redis 实例的降级（延迟、吞吐量）
最好将 Redis 绑定到 NUMA 节点（即多个核心），并在此基础上保持至少一个核心空闲支持后台任务
数据写入量大，主从同步落后，导致频繁全量同步
在使用 Redis 复制的设置中，强烈建议在主服务器和副本中启用持久化。当这不能实现时，例如，由于磁盘速度非常慢导致的延迟问题，应配置实例以 避免 reboot 后自动重启。
为了更好地理解为什么将持久化关闭的 master 配置为自动重新启动是危险的，请防止以下故障模式，即从 master 及其所有副本中擦除数据：
- 有一个设置，节点 A 充当 master 节点，持久化被关闭，节点 B 和 C 从节点 A 复制。
- 节点 A 崩溃，但它有配置自动重启可以重启进程。但是，由于持久化已关闭，节点将以空数据集重新启动。
- 节点 B 和 C 将从空的节点 A 复制，因此它们将实际上销毁已有的数据副本。
当 Redis Sentinel 用于高可用性时，关闭主机上的持久化，并且配置自动重启进程，是危险的。例如，Master 节点可能快速重启，使 Sentinel 无法检测到故障，从而出现上述故障模式。
默认情况下，副本将忽略 “maxmemory”（除非在故障切换后或手动将其升级为 Master 副本）。副本不会主动淘汰数据，而会等待 Master 的 DEL 命令。最终可能会使用比 maxmemory 设置更多的内存（因为复制副本上有某些缓冲区可能更大，或者数据结构有时会占用更多内存等等）。要更改此行为，可以允许复制副本不忽略最大内存。要使用的配置指令是：
replica-ignore-maxmemory no
故障转移 Failover
执行手动故障切换时，连接到 Master 节点的客户端都会被停止（延迟毛刺）。同时，Master 将复制偏移量发送给副本，副本等待该侧的偏移量到达。
当达到复制偏移量时，故障切换将启动，并通知旧 Master 有关配置切换的信息。旧 Master 取消阻止客户端时，它们将重定向到新 Master。
当副本想要成为 Master 时，没有分配 slots 的 Master 不参与选举过程。
容灾 Disaster recovery
Redis 环境中的灾难恢复与备份基本相同，而且能够在许多不同的外部数据中心传输这些备份。即使在某些灾难性事件影响到运行 Redis 并生成其快照的主数据中心的情况下，也可以通过这种方式保护数据。
- 备份 RDB
- RPO：小时级
- RTO：小时级
- 备份 AOF（Redis 7.0.0 以上）
- RPO：分钟级
- RTO：分钟级
RPO 和 RTO 较高
异构 DR 实现难度高
控制面
重新分片 Resharding
搬迁数据只能顺序进行，速度慢。
迁移状态不会广播给从节点，迁移过程中发生 failover，新的 master 迁移状态会丢失，需要重新设置
因为 SET SLOT 是先生效再共识，迁移过程 SET SLOT 的操作需要严格有序，先设置 Dst Node 确认生效再设置 Src Node。
移除节点 Forget node
移除节点需要在 1 分钟内通知所有节点，该节点下线。否则节点会可能再次加入集群
监控指标 Metrics
Prometheus 一般 间隔 通过 Redis Exporter 调用 INFO 命令拉取 Redis 监控数据。有些指标是瞬时值，可能不会被记录下来。 例如 Loading 状态
本文作者 ： cyningsun
本文地址 ： https://www.cyningsun.com/02-14-2023/details-about-redis-cluster.html
版权声明 ：本博客所有文章除特别声明外，均采用 CC BY-NC-ND 3.0 CN 许可协议。转载请注明出处！
