本文详解 redisson 分布式锁报错 “none of slaves were synced” 的根本原因、适用场景限制及升级修复方案，重点说明为何该异常在 kafka 事件幂等处理中尤为关键，并提供安全升级与配置优化建议。
本文详解 redisson 分布式锁报错 “none of slaves were synced” 的根本原因、适用场景限制及升级修复方案，重点说明为何该异常在 kafka 事件幂等处理中尤为关键，并提供安全升级与配置优化建议。
在基于 Spring Boot + Kafka + Redis 构建的多 Pod 微服务架构中，常通过 Redisson 实现跨实例的分布式锁，以确保同一 Kafka 消息（如订单事件）仅被一个消费者处理，从而保障业务幂等性。然而，当使用 Redis 主从部署（非 Redis Cluster 模式）并启用 writeMode = "MASTER_SLAVE" 或默认配置时，调用 RLock.lock() 可能抛出以下致命异常：
java.lang.IllegalStateException: None of slaves were synced
at org.redisson.RedissonBaseLock.lambda$evalWriteAsync$0(RedissonBaseLock.java:225)该异常本质是 Redisson 强一致性写校验机制触发的保护性拒绝：当客户端尝试执行需主从同步确认的加锁脚本（如 EVAL 命令）时，Redisson 会检查所有已配置的 slave 节点是否已完成当前写操作的复制。若任意 slave 尚未 ACK（例如网络延迟、slave 故障或复制积压），则直接抛出此异常，而非降级执行——这是其“安全优先”设计的体现。
⚠️ 关键认知：
- 此错误 不表示锁功能失效，而是明确告知：当前主从拓扑无法满足强一致写入保障；
- 它常见于高吞吐 Kafka 消费场景，因频繁加锁加剧了主从同步压力；
- 绝不可通过捕获异常后重试或忽略来规避，否则将导致锁失效与数据不一致风险。
✅ 官方解决方案已在 Redisson 3.20.1 及更高版本 中正式修复。该版本优化了 evalWriteAsync 的 slave 同步判定逻辑，引入更灵活的超时与容错策略，在保证安全性的同时显著降低误报率。
推荐升级步骤：
-
更新 Maven 依赖：
<dependency> <groupId>org.redisson</groupId> <artifactId>redisson-spring-boot-starter</artifactId> <version>3.24.3</version> <!-- 建议使用最新稳定版 --> </dependency>
-
（可选）显式配置写模式，避免隐式依赖旧行为：
# application.yml redisson: config: | singleServerConfig: address: "redis://127.0.0.1:6379" # 显式指定写模式，避免自动 fallback 引发歧义 writeMode: "MASTER_SLAVE" threads: 16 nettyThreads: 32
? 注意事项：
- 若业务对强一致性要求不高（如允许极短时间内的锁冲突），可评估改用 writeMode: "MASTER"（仅写主节点），但需同步加强 Kafka 消费端幂等校验（如 DB 唯一索引 + 业务状态机）；
- 禁止在生产环境降级至 <3.20.1 版本，旧版存在该异常的不可恢复路径；
- 配合 Redis 监控（INFO replication 中 slave_repl_offset 与 master_repl_offset 差值）持续观察主从同步健康度。
总结而言，“None of slaves were synced” 是 Redisson 对分布式系统一致性的主动守门员。正确应对方式不是绕过它，而是升级到受信版本、理解其设计意图，并结合架构实际（如是否必须强同步）做出技术权衡。在 Kafka 事件驱动架构中，一次可靠的锁，远胜于一百次侥幸的成功。
