原文出处:Java 技术驿站 『chenssy』
前面两篇博客已经详细介绍了主从复制的原理,相信各位对 Redis 的主从复制有了一个比较深入的了解,这篇博客主要介绍主从复制的应用以及它的一些问题。
读写分离
我们都知道对于读多写少的场景,我们可以使用读写分离的方式来提供整体的并发量,对于 Redis 也一样,由于从节点是主节点的副本,我们可以利用主节点提供写服务,一个或者多个从节点提供读服务,这样就最大化 Redis 的读负载能力。当然,这样并不是说主从架构下的读写分离没有问题,恰恰是有大问题,在这种情况下,业务需要面对如下几个问题:
数据延迟
读到过期数据
从节点故障
数据延迟
在命令传送阶段,Redis 主从节点同步命令的过程是异步的,所以势必会导致主从节点的数据不一致性,如果我们的应用对数据的不一致性接受程度不是很高,则我们可以从以下几个方面优化:
优化主从节点的网络环境(比如主从节点部署在同机房)
监控从节点的延迟性,如果延迟过大,则通知应用不从该节点读取数据,这种方案需要改造客户端,工作量不小,一般不推荐
从节点的 slave-serve-stale-data 参数便与其有关,它控制着从节点对读请求的响应情况,如果为 yes(默认值),则从节点可以响应客户端的命令,如果为 NO,则只能响应 info、slaveof 等少数命令。所以如果应用对数据一致性要求较高,则应该将该参数设置为 NO。
读到过期数据
Redis 内部对过期数据的删除有两种方