异步复制的“确认即成功”本质是Redis主节点写入内存和AOF缓冲区后立即返回OK，不等待从节点确认；若此时主节点崩溃且未同步，数据永久丢失。
异步复制的“确认即成功”本质
Redis主节点收到写请求后，只要把命令写入自己的内存和AOF缓冲区（如果开启），就立刻返回OK——它**不等从节点响应**。这个行为是设计使然，不是bug。所以从你调用SET cart:1001 "item:A,qty:2"到主节点返回的那一刻起，数据其实只存在于主节点内存里；若此时主节点崩溃且未同步完成，这部分数据就永久消失。
常见错误现象：压测时一切正常，但真实故障中突然发现购物车清空、库存多扣、计数器归零。这类问题往往不是代码逻辑错，而是误以为OK = 数据已落盘+已复制。
-
min-replicas-to-write 1和min-replicas-max-lag 10是唯一能干预该行为的配置：当没有从节点在10秒内完成同步，主节点会拒绝写入，主动牺牲可用性保一致性 - 但注意：该配置只对主从架构（哨兵）有效，在Redis Cluster中不起作用——Cluster靠
cluster-require-full-coverage no和客户端重试兜底，本身不阻塞写 - 开启
appendonly yes+appendfsync everysec只能防止主节点本地宕机丢失，无法解决主从间断连导致的复制断层
故障转移窗口期：从检测到切换之间的“黑箱时间”
哨兵或Cluster检测主节点失联，到选出新主并通知客户端，中间存在不可忽略的时间差。以默认配置为例：cluster-node-timeout 15000 表示节点超时判定为15秒；而从节点要参与选举，还必须满足replica-validity-factor限制（比如10 × 15s = 150秒内有过有效心跳）。这意味着：旧主可能还在接收写请求，而集群尚未达成新主共识。
使用场景：电商秒杀、支付回调、实时排行榜更新——这些操作一旦落在这个窗口，极大概率丢失。
- 脑裂发生时，旧主恢复后降级为从，会强制清空自身数据并全量同步新主，导致窗口期内所有写入被覆盖
- 客户端若未启用
READONLY自动切换或未监听+switch-master事件，仍会往旧主发写命令，加剧丢失 - 不要依赖
INFO replication中的lag值做实时判断——它是采样统计，非精确延迟，且不反映网络瞬断期间的积压
为什么“最终一致”不等于“可接受丢失”
Redis官方文档称Cluster提供“最终一致性”，但这只是指：只要系统持续运行、无进一步故障，所有节点的数据终将收敛。它**不承诺任何时间范围，也不保证中间状态可见性**。对业务而言，“最终”可能是几秒、几十秒，甚至因配置不当变成“永不”。
性能/兼容性影响：强行追求强一致（如用Lua脚本+WAIT命令）会显著拖慢吞吐。例如WAIT 1 1000要求至少1个从节点在1秒内确认，高负载下极易超时失败。
-
WAIT只作用于当前连接发出的写命令，无法跨命令、跨连接保障事务级一致性 - Cluster中
WAIT仅限于当前哈希槽所在主节点及其直连从节点，跨槽操作（如MGET多个key）无法统一等待 - 部分客户端（如Jedis早期版本）不自动解析
MOVED/ASK响应，导致WAIT在重定向后失效，反而掩盖问题
真正可控的防线只有三处
别指望靠“等一等”或“再试一次”来兜住关键数据。生产环境中真正能落地的防线非常有限，且每条都有明确代价。
- 业务层双写：写Redis同时记一条DB日志（如MySQL binlog），故障后用日志补偿。代价是增加RT和DB压力，但胜在可控
- 客户端幂等+重试：对
INCR、HINCRBY等操作，用带版本号的key（如counter:order:20260313:v2）避免重复累加；配合服务端去重逻辑 - 放弃Redis单点强一致幻想：把订单创建、支付结果等核心状态下沉到MySQL或TiDB，Redis只做缓存加速，用
Cache-Aside模式管理生命周期
最容易被忽略的是：很多团队花大量精力调优repl-backlog-size或client-output-buffer-limit，却没梳理清楚哪些数据真的允许丢失。比配置更重要的是，画出你的写路径图，标出每个环节的SLA容忍度——那里才是决策起点。
