Redis集群是否会出现数据丢失？丢失后如何处理？

### 作用 Redis 集群在主从切换、网络异常等场景下**仍可能出现数据丢失**，但可以通过配置将丢失范围控制在可接受范围内，并在故障恢复后通过主从同步恢复数据一致性。 ### 原理 #### 1. 可能导致数据丢失的情况 - **异步复制导致丢失** - Redis 的 `master -> slave` 复制是异步的。 - 客户端写入 master 后，master 写入内存即可返回成功，不必等待 slave 确认。 - 如果部分数据还未同步到 slave，master 就宕机，这部分未同步的数据可能丢失。 - **脑裂导致丢失** - master 因网络问题与 slave、哨兵断开连接，但 master 进程实际仍在运行。 - 哨兵可能误判 master 下线，并将某个 slave 选举为新的 master，集群中因此出现两个 master。 - 客户端如果仍向旧 master 写入，旧 master 恢复网络后会被降级为 slave，并清空本地数据、重新从新 master 同步。 - 脑裂期间写入旧 master 的数据就会丢失。 #### 2. 处理与降低丢失的方法 可通过以下参数限制 master 在从库复制异常时继续接收写入： ```conf min-slaves-to-write x min-slaves-max-lag y ``` 含义是：在 `y` 秒内，至少要有 `x` 个 slave 正常完成同步并返回 ACK，master 才允许处理写请求。 - **应对异步复制丢失** - 当 slave 复制延迟过大、ACK 超时，master 拒绝新的写请求。 - 这样可以避免 master 积压大量尚未同步的数据，降低宕机后的数据丢失量。 - 应用侧也可以配合限流、降级，或将临时写入放入 MQ，待复制恢复后再回流 Redis。 - **应对脑裂丢失** - 脑裂时旧 master 无法连接指定数量的 slave，超过配置时间后会拒绝客户端写入。 - 从而避免客户端继续向旧 master 写入大量数据。 - 例如配置要求至少 1 个 slave 在 10 秒内 ACK，则脑裂场景下旧 master 最多只会短暂接收写入，可将丢失窗口控制在配置时间附近。 #### 3. 丢失后的恢复 - 故障节点恢复后，会作为 slave 重新加入集群。 - 它会清空本地不一致的数据，并从新的 master 重新同步数据。 - 集群最终以新 master 的数据为准恢复主从一致性。 - 已经错过持久化和主从复制窗口的数据无法由 Redis 自动找回，需要依赖业务重试、MQ 重放、备份恢复或上游数据源补偿。