java中redis主从读写分离的核心是应用层路由：写操作走主节点，读操作优先走从节点，需配置独立连接池并区分主从地址，利用lettuce等客户端自动路由，同时适配异步复制延迟与一致性要求。
Java 中使用 Redis 主从复制提升读写吞吐量，核心不是在代码里“实现复制”，而是让应用层感知主从角色、合理分发读写请求，配合 Redis 服务端已配置好的主从拓扑。主从同步由 Redis 自身完成，Java 客户端只负责路由——写走主节点，读尽量走从节点。
明确主从节点连接配置
不能把所有节点都当成普通 Redis 实例去连。你需要在 Java 应用中区分主节点（写）和从节点（读）的地址：
- 主节点：仅用于
SET、INCR、DEL等写命令，以及强一致性读（如库存扣减前校验） - 从节点：可配置多个，用于
GET、HGETALL、LRANGE等常规读操作 - 推荐用连接池分别管理：例如
JedisPool或LettuceClientResources为 master 和 slaves 各建一套
客户端读写分离路由策略
Java 本身不内置路由逻辑，需自行封装或借助轻量工具：
- 简单场景：用 if 判断 + 多个 Jedis 实例，写操作调用 masterJedis，读操作轮询 slaveJedis 列表（加权重或随机）
- 进阶做法：基于 Lettuce 的
MasterSlaveClient（Lettuce 6+ 原生支持），自动识别主从角色并按策略分发 - 关键注意：不要在事务（
multi/exec）中混用主从连接；事务必须全程走主节点
处理数据延迟带来的不一致
异步复制必然存在毫秒级延迟，Java 层要主动适配，而非等待“完全一致”：
- 对非敏感读（如用户个人中心、商品详情页）直接读从库，接受几秒内旧数据
- 对强一致场景（如支付回调查订单状态、秒杀下单前查库存），强制走主库读，或加一层版本号/时间戳比对
- 可结合 Redis 的
INFO replication输出，在监控系统里采集master_repl_offset - slave_repl_offset，延迟超阈值（如 > 5000 字节）时临时降级读主库
避免常见踩坑点
很多性能没提上来，其实是配置或用法反模式导致的：
- 从节点没开启
readonly yes（默认开启，但若手动改过配置需确认），否则可能被误写入，破坏一致性 - 主节点内存过大（>20GB）+ RDB 生成慢 → 全量同步耗时长 → 从节点长时间不可读，应控制单实例数据规模或启用无盘复制（
repl-diskless-sync yes） - 网络跨机房部署主从 → 延迟高且不稳定 → 建议同机房部署，异地容灾靠哨兵+备份方案，而非依赖跨地域主从实时同步
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
