redis 永不过期 java_死磕 Java

原文出处：Java 技术驿站 『chenssy』

前面两篇博客已经详细介绍了主从复制的原理，相信各位对 Redis 的主从复制有了一个比较深入的了解，这篇博客主要介绍主从复制的应用以及它的一些问题。

读写分离

我们都知道对于读多写少的场景，我们可以使用读写分离的方式来提供整体的并发量，对于 Redis 也一样，由于从节点是主节点的副本，我们可以利用主节点提供写服务，一个或者多个从节点提供读服务，这样就最大化 Redis 的读负载能力。当然，这样并不是说主从架构下的读写分离没有问题，恰恰是有大问题，在这种情况下，业务需要面对如下几个问题：

数据延迟

读到过期数据

从节点故障

数据延迟

在命令传送阶段，Redis 主从节点同步命令的过程是异步的，所以势必会导致主从节点的数据不一致性，如果我们的应用对数据的不一致性接受程度不是很高，则我们可以从以下几个方面优化：

优化主从节点的网络环境(比如主从节点部署在同机房)

监控从节点的延迟性，如果延迟过大，则通知应用不从该节点读取数据，这种方案需要改造客户端，工作量不小，一般不推荐

从节点的 slave-serve-stale-data 参数便与其有关，它控制着从节点对读请求的响应情况，如果为 yes(默认值)，则从节点可以响应客户端的命令，如果为 NO，则只能响应 info、slaveof 等少数命令。所以如果应用对数据一致性要求较高，则应该将该参数设置为 NO。

读到过期数据

Redis 内部对过期数据的删除有两种方