主从集群有延迟，主节点刚存数据未同步就挂了，从节点无数据如何处理

在主从集群中，主节点写入数据但未同步到从节点就宕机，会导致从节点数据缺失（即数据丢失）。解决方法包括： 1. 接受部分丢失：业务允许少量数据丢失，依赖从节点提升为主继续服务。 2. 增强同步机制：配置同步策略（如半同步复制）减少延迟。 3. 故障恢复：主节点恢复后，利用日志或快照补齐数据。 4. 架构优化：引入多副本或分布式一致性（如 Raft）避免单点丢失。

1. 问题分析

场景描述

主节点写入数据（如 SET key value）。
数据未同步到从节点（因网络延迟或异步复制）。
主节点宕机，Sentinel/Cluster 切换从节点为主。
新主节点无该数据，客户端查询不到。

原因

异步复制：Redis 默认异步，主写后立即返回，不等从同步。
同步延迟：网络、磁盘 IO 或从节点负载导致。
结果：主从不一致，切换后数据丢失。

示例

主: SET key "value"  // 未同步
主宕机 -> 从提升为主
从: GET key          // 返回 nil

2. 解决方法

(1) 接受部分丢失（业务允许）

适用场景：数据非强一致性（如缓存、日志）。
操作：
从节点提升为主，继续服务。
原数据丢失，客户端重试或忽略。
前提：
业务容忍少量丢失。
优点：
简单，服务可用性高。
缺点：
数据永久丢失。

(2) 配置半同步复制

原理：
主节点写入后，等待至少一个从节点确认才返回。
Redis 配置（有限支持）：
Redis 默认无原生半同步，但可通过 WAIT 命令模拟：

SET key value
WAIT 1 1000  // 等待 1 个从节点同步，超时 1000ms

效果：
降低丢失风险，但不完全消除（仍可能超时）。
优点：
减少延迟窗口。
缺点：
性能下降，主节点写变慢。

(3) 主节点恢复后补齐

原理：
主节点宕机前持久化（如 AOF），恢复后同步给从节点。
步骤：
主节点启用 AOF（appendonly yes）。
宕机后重启，加载 AOF。
从节点全量同步（RDB + 增量）。
优点：
数据可找回。
缺点：
恢复时间长，服务中断。

(4) 架构优化

多主多从：
多节点写，数据冗余。
如 Redis Cluster，分片存储带副本。
一致性协议：
用 Raft/Paxos（如 Redis Enterprise 或 etcd）替代主从。
写入需多数节点确认。
消息队列：
数据先入 Kafka，异步写 Redis，丢失可重放。
优点：
高可靠性，几乎无丢失。
缺点：
复杂度高，性能成本大。

(5) 客户端重试

原理：
主写失败，客户端感知后重试写入新主。
实现：
客户端 SDK 检测异常，重发请求。
优点：
简单，弥补丢失。
缺点：
依赖客户端，增加开发成本。

3. 方案对比

方法	数据丢失	可用性	复杂度	适用场景
接受丢失	是	高	低	非核心数据
半同步复制	减少	中	中	平衡一致性和性能
主恢复补齐	否	低	中	可中断服务
多主/一致性协议	极低	高	高	高一致性需求
客户端重试	减少	高	中	客户端可控

4. Redis 现状与局限

默认异步：
replicaof 是异步复制，主不等从。
改进：
WAIT 命令有限同步。
Redis 6.0+ 支持 PSYNC（部分同步），减少全量。
局限：
无原生强一致性，需外部方案。

5. 延伸与面试角度

优化延迟：
增大 repl-backlog-size，缓冲未同步数据。
优化网络（内网、高带宽）。
实际案例：
电商库存：用 MQ + Redis 保证不丢。
聊天记录：AOF + 主从。
预防措施：
监控复制延迟（INFO REPLICATION）。
Sentinel 快速切换。
面试点：
问“解决”时，提半同步和 AOF。
问“架构”时，提 Cluster 或 Raft。

示例

# 主节点 AOF
redis-server --appendonly yes
# 从节点同步
redis-server --replicaof 192.168.1.100 6379
# 客户端重试
SET key value
WAIT 1 1000 || retry

总结

主从延迟导致数据丢失，可通过接受丢失、半同步、主恢复、架构优化或客户端重试解决。Redis 默认异步，需结合持久化和高可用弥补。面试时，可提 AOF + Sentinel 或画流程图，展示理解深度。