Redis 读写分离

读写分离：

对于读占比较高的场景，可以通过把一部分流量分摊导出从节点(salve) 来减轻主节点（master）压力，同时需要主要只对主节点执行写操作，如下图：

当使用从节点响应读请求时，业务端可能会遇到以下问题：

• 复制数据延迟
• 读到过期数据
• 从节点故障

1.数据延迟

Redis 复制数的延迟由于异步复制特性是无法避免的，延迟取决于网络带宽和命令阻塞情况，对于无法容忍大量延迟场景，可以编写外部监控程序监听主从节点的复制偏移量，当延迟较大时触发报警或者通知客户端避免读取延迟过高的从节点，实现逻辑如下图：

说明如下：

1） 监控程序(monitor) 定期检查主从节点的偏移量，主节点偏移量在info replication 的master_repl_offset 指标记录，从节点 偏移量可以查询主节点的slave0 字段的offset指标，它们的差值就是主从节点延迟的字节 量。

2）当延迟字节量过高时，比如超过10M。监控程序触发报警并通知客户端从节点延迟过高。可以采用Zookeeper的监听回调机制实现客户端通知。

3） 客户端接到具体的从节点高延迟通知后，修改读命令路由到其他从节点或主节点上。当延迟回复后，再次通知客户端，回复从节点的读命令请求。

这种方案成本较高，需要单独修改适配Redis的客户端类库。

2.读到过期数据

当主节点存储大量设置超时的数据时，如缓存数据，Redis内部需要维护过期数据删除策略，删除策略主要有两种：惰性删除和定时删除。

惰性删除：主节点每次处理读取命令时，都会检查键是否超时，如果超时则执行del命令删除键对象那个，之后del命令也会异步 发送给 从节点

需要注意的是为了保证复制的一致性，从节点自身永远不会主动删除超时数据，如上图。

定时删除：

Redis主节点在内部定时任务会循环采样一定数量的键，当发现采样的键过期就执行del命令，之后再同步给从节点，如下图

如果此时 数据的大量超时，主节点采样速度跟不上过期速度且主节点没有读取过期键的操作，那么从节点将无法收到del命令，这时在从节点 上可以读取到已经超时的数据。Redis在3.2 版本解决了这个问题，从节点 读取数据之前会检查键的过期时间来决定是否返回数据，可以升级到3.2版本来规避这个问题。

3.从节点故障问题

对于从节点故障问题，需要在客户端维护可用从节点列表，当从节点故障时立刻切换到其他从节点或主节点上。

建议大家在做读写分离时，可以考虑使用Redis Cluster等分布式解决方案