Redis以单线程处理命令而著称，单机读性能虽然强大，但在某些业务场景下依然会遇到瓶颈。比如社交平台的首页信息流、电商大促时的商品详情页、实时排行榜等读多写少的场景，读请求量可能是写请求的几十倍甚至上百倍，单靠一台Redis实例往往扛不住。读写分离正是解决这类问题的经典方案，它通过主从复制机制把读流量分散到多台从节点上，让整个系统的读吞吐量可以近似线性扩展。
主从复制的底层原理
理解读写分离之前，必须先弄清楚主从复制是怎么工作的。Redis的主从复制分为全量同步和增量同步两种方式。当一个从节点第一次连接主节点，或者复制积压缓冲区不足以覆盖断线期间的命令时，会触发全量同步：主节点执行BGSAVE生成RDB快照，把快照发送给从节点，从节点清空自身数据后加载快照，之后主节点再把快照期间的写命令持续发送给从节点。
增量同步则依赖两个关键结构：复制积压缓冲区（repl_backlog）和每个节点的复制ID。主节点会把最近写入的命令同时放入一个固定大小的环形缓冲区中，从节点断线重连时，会带上自己已复制的偏移量，主节点检查这个偏移量是否还在缓冲区范围内，如果在，就只补发缺少的那部分命令，避免昂贵的全量同步。
需要注意的是，复制积压缓冲区默认只有1MB，网络抖动频繁的环境下很容易不够用，导致频繁触发全量同步。生产环境建议根据写入量和网络状况调整：
# 估算公式：缓冲区大小 > 平均写入速率 * 平均断线时长 # 例如写入速率 2MB/s，预计最长断线 60 秒，至少设置 120MB redis-cli config set repl-backlog-size 128mb # 断线后缓冲区的保留时间，超过该时间没有从节点连接则释放 redis-cli config set repl-backlog-ttl 3600
搭建读写分离架构的实战配置
搭建主从架构非常简单。假设有一台主节点和两台从节点，只需要在从节点的配置文件中指定主节点地址，或者用命令行动态设置。先在主节点上确认配置，主节点本身不需要任何特殊设置，复制是单向发起的：
# 在从节点上执行（redis.conf 中对应 slaveof 或 replicaof 指令） # Redis 5.0 之前 slaveof 192.168.1.10 6379 # Redis 5.0 及之后推荐写法 replicaof 192.168.1.10 6379 # 从节点是否只读，默认 yes，强烈建议保持只读 replica-read-only yes # 主节点密码 masterauth your_password # 从节点自己的持久化可以按需关闭，减轻磁盘压力 # save "" # appendonly no
配置完成后重启从节点，执行info replication可以查看复制状态，关注master_link_status是否为up，以及master_repl_offset和slave_repl_offset是否持续增长且差距很小。三个节点都就绪后，架构就变成了：写请求全部打到主节点，读请求按策略分发到从节点。
客户端路由层面，常见做法有三种。第一种是应用层自己维护节点列表，写操作用主节点的连接池，读操作轮询从节点的连接池，优点是逻辑直观可控，缺点是节点变更时需要改代码或配置。第二种是使用代理层，比如部署Twemproxy或者使用支持Redis协议的代理服务，应用只连接代理，由代理负责读写分流，好处是对应用透明，坏处是多了一层网络转发开销。第三种是利用客户端SDK的能力，例如Java生态中的Jedis和Lettuce都支持显式区分读写连接：
// 使用 Jedis 区分读写连接
JedisPool masterPool = new JedisPool(poolConfig, "192.168.1.10", 6379);
JedisPool slavePool1 = new JedisPool(poolConfig, "192.168.1.11", 6379);
JedisPool slavePool2 = new JedisPool(poolConfig, "192.168.1.12", 6379);
// 写操作走主节点
try (Jedis jedis = masterPool.getResource()) {
jedis.set("stock:1001", "500");
}
// 读操作在从节点间轮询
List<JedisPool> slaves = Arrays.asList(slavePool1, slavePool2);
int index = counter.getAndIncrement() % slaves.size();
try (Jedis jedis = slaves.get(index).getResource()) {
String value = jedis.get("stock:1001");
}主从延迟与数据不一致的应对策略
读写分离最大的代价是一致性弱化。主从复制是异步的，主节点写入成功后立即返回客户端，命令还没同步到从节点，此时读从节点就会读到旧数据。大多数业务可以容忍毫秒级延迟，但有些场景不行，比如用户修改昵称后立刻刷新页面，如果昵称是从从节点读的，很可能还是旧值，用户会以为修改失败了。
针对强一致读的需求，常用的策略是关键读强制走主节点。也就是在读多写少的整体分流基础上，对少数强一致性的key，客户端显式使用主节点连接读取。另一种做法是会话粘连：用户写操作后的几秒内，该用户的相关读请求都路由到主节点，可以通过在网关或应用层记录一个短时间戳标记实现。还有一种思路是读从节点后校验偏移量，客户端比较从节点上报的复制偏移量是否已达到目标位置，未达到则等待或回退到主节点，这种方案实现复杂度较高，一般只在特定中间件中使用。
监控层面要重点关注主从延迟指标。可以通过info replication中的偏移量差值估算延迟，也可以直接在主节点定时写入带时间戳的探针key，从节点读取后计算差值。延迟超过阈值时应该告警，必要时自动把读流量切回主节点，避免业务感知到明显的脏读。
高可用与集群模式下的取舍
单纯的主从架构存在单点风险：主节点挂了需要人工切换。生产环境通常配合哨兵（Sentinel）使用，哨兵集群持续探测主节点状态，故障时自动把某个从节点提升为新主，并通知客户端更新连接地址。哨兵模式下客户端应该使用支持哨兵协议的SDK，例如Jedis的JedisSentinelPool，故障转移后连接会自动恢复，不需要人工干预。
如果数据量大到单机内存放不下，或者写请求也成了瓶颈，就要考虑Redis Cluster了。需要注意一个关键区别：Cluster的分片主节点之间彼此独立，从节点默认也不服务读请求，除非显式开启READONLY命令。Cluster的扩展目标是水平分片存储和写入能力，而传统主从读写分离的目标是扩展读能力，两者解决的是不同维度的问题，可以组合使用但不要混为一谈。
选型时可以参考这样的判断路径：单机内存足够、读压力大、能容忍毫秒级不一致，用主从加哨兵加读写分离；数据量超过单机内存或者写压力大，直接上Cluster，从节点按需承担部分读流量。另外别忘了最终兜底手段，热点key可以用本地缓存挡在Redis前面，多级缓存配合读写分离，往往比单纯堆从节点数量效果更好。
总结
读写分离是扩展Redis读吞吐量最直接有效的手段，核心在于主从复制机制的可靠支撑。落地时要重点做好三件事：合理配置复制积压缓冲区避免频繁全量同步，设计好客户端路由策略并预留强制读主的能力，搭配哨兵保证故障自动转移。同时要清醒认识到异步复制带来的一致性弱化，对强一致读的业务单独处理。架构没有银弹，读写分离适合读多写少场景，写入瓶颈则要另寻他路，理解每种方案的边界比掌握配置命令更重要。