Redis主从架构通过服务端配置实现读写分离：主节点处理写操作并异步复制数据，从节点只读并分担读请求；Java应用只需按角色路由请求，不参与复制过程。
Java 本身不直接配置 Redis 主从架构，而是通过客户端连接和运维层部署来配合 Redis 服务端的主从复制机制。真正实现多机热备份与读写分离的关键，在于 Redis 服务端的 Master-Slave 配置，Java 应用只需按角色区分连接即可。
Redis 服务端主从部署要点
主从复制是 Redis 内置能力，需在每台 Redis 实例的 redis.conf 中明确角色：
-
Master（主节点）：无需特殊配置，但必须开启持久化（
save或appendonly yes），否则宕机重启后内存为空，同步会清空所有从机数据； -
Slave（从节点）：在配置文件中添加两行（Redis 5.0+ 推荐用
replicaof，旧版本用slaveof）：replicaof 192.168.1.100 6379masterauth your_master_password（若主节点启用了requirepass）； - 每个从节点需独立配置：
port、pidfile、logfile、dbfilename、dir，避免端口/文件冲突； - 从节点默认只读，由
slave-read-only yes控制，不可写入（写会报错READONLY You can't write against a read only slave.）。
Java 客户端如何配合读写分离
Java 程序不参与复制过程，但需按业务逻辑将读写请求路由到不同节点：
- 写操作（
SET、HSET、DEL等）统一走 Master 连接池，例如用Jedis或Lettuce直连主节点地址； - 读操作（
GET、HGET、KEYS等）可轮询或随机分发到任意一个 Slave 连接池，提升并发吞吐； - 推荐使用 Lettuce 的
MasterSlaveClient或自定义负载均衡策略（如加权轮询），避免硬编码 IP； - 注意：从节点可能有短暂延迟（毫秒级），对强一致性读场景，仍应走 Master。
验证与容灾关键点
部署后务必验证三项核心行为：
立即学习“Java免费学习笔记（深入）”；
- 执行
INFO REPLICATION：Master 显示connected_slaves:2，Slave 显示role:slave且master_link_status:up； - 在 Master 写入新 key（如
SET test_java "ok"），稍等 1–2 秒后在任一 Slave 执行GET test_java应返回值； - 手动停掉一台 Slave，再启，它会自动重连并完成增量同步（Redis 2.8+ 支持 PSYNC 断点续传）；
- Master 宕机时，Slave 不会自动升级为主——这是设计使然，需人工执行
SLAVEOF NO ONE或交由哨兵（Sentinel）接管。
为什么不建议纯靠 Java 实现“动态主从切换”
主从关系由 Redis 服务端维护，Java 客户端无法干预数据同步过程。所谓“Java 配置主从”，本质是：
- 用 Java 启动脚本调用
redis-server --replicaof ...（不推荐，运维耦合高）； - 用 Java 调用 Redis 命令动态设置
REPLICAOF（仅临时生效，重启失效，且需权限）； - 真正可靠的做法：把主从拓扑固化在 redis.conf + 运维编排（如 systemd / Docker Compose），Java 只做连接发现与流量分发。
