Redis读写分离通过一主多从架构实现，主节点专注写操作，从节点分担读请求，客户端需主动路由并规避主从延迟导致的数据不一致。
Redis 读写分离是应对高并发读场景最直接有效的架构手段。它不改变单节点写能力，但通过横向扩展从节点，把“读压力”从主节点卸载出去，从而整体提升系统吞吐量。
明确主从角色分工
主节点（Master）只处理写操作（SET、INCR、DEL 等），确保数据变更的唯一入口；从节点（Slave）默认只读，自动同步主节点数据，专用于承接大量 SELECT 类请求（如 GET、MGET、HGETALL）。这种刚性分工避免了读写争抢同一资源，也天然规避了锁竞争和 CPU 上下文频繁切换问题。
- 主节点专注写入，减少查询带来的 CPU 和内存抖动
- 从节点可部署多个（例如 1 主 + 3 从），读吞吐量接近线性增长
- 客户端连接时需区分数据源：写走主库地址，读走从库地址池
合理配置客户端路由策略
应用层需主动控制读写流向，不能依赖 Redis 自动分发。常见做法包括：
- 使用支持读写分离的客户端库（如 Lettuce 的 MasterSlave 模式、Redisson 的 ReadWriteLock + ReadMode.SLAVE）
- 自定义路由逻辑：对非事务性、非强一致要求的读请求，优先打到随机/轮询的从节点
- 对写后立即读（如“下单后查订单”）等敏感场景，强制走主节点，规避主从延迟导致的数据不一致
关注主从延迟与一致性取舍
Redis 主从复制是异步的，从节点数据存在毫秒级延迟（通常
- 读从库能显著提升吞吐，但无法保证实时一致性
- 业务需评估容忍度：资讯类、商品详情页等读多弱一致场景非常适合；而资金流水、库存扣减后的状态确认需绕过从库
- 可通过 INFO replication 查看 slave 的 master_repl_offset 与自身 slave_repl_offset 差值，监控延迟水位
配合哨兵或集群增强可用性
单纯主从不具备自动故障转移能力。生产环境建议叠加哨兵（Sentinel）或 Redis Cluster：
- 哨兵可监听主节点健康状态，主宕机后自动提拔一个从节点为新主，并通知客户端更新地址
- Redis Cluster 在分片基础上内置主从结构，每个哈希槽（slot）都有主+从，既实现水平扩展，又保障读写分离与高可用
- 注意：Cluster 默认将读请求发往负责该 key 的主节点；如需读从节点，需显式启用 READONLY 命令或客户端设置 readFrom = SLAVE
