redis主从不一致的问题问题解决 redis 主从不一致

1. 目录

• 1. 目录
• 2. Redis删除策略

• 2.1. 惰性删除
• 2.2. 定时删除
• 2.3. 内存淘汰机制

• 3. 过期数据

• 3.1. 读取 Master
• 3.2. 读取 Slave

• 3.2.1. 版本过低
• 3.2.2. 过期时间设置

• 4. 主从不一致

2. Redis删除策略

2.1. 惰性删除

数据到达过期时间，并不做处理，而是等下次访问该数据时，先判断该数据是否过期，未过期，返回数据 ；发现已过期，删除该数据，返回不存在。 这种方式虽然节约 CPU 性能，发现必须删除的时候才删除。但是对内存压力很大，会出现长期占用内存的数据。

2.2. 定时删除

通过定时器，当 key 设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作，虽然节约内存，到时即删除，快速释放不必要的内存，但是给 CPU 带来压力很大，均会占据 CPU ，如果遇到高峰期，会对响应 和 指令吞吐量有影响。

2.3. 内存淘汰机制

Redis 提供 6 种内存淘汰机制：

• volatitle-lru：least recently used，从设置已过期时间的数据集中，挑选最近使用最少的数据淘汰。
• volatitle-ttl：从设置已过期时间的数据集中挑选即将要过期数据淘汰。
• volatitle-random：从设置已过期时间的数据集中随机任意选择数据淘汰。
• allkeys-lru：当内存不足在键空间中，移除最近最少使用的 key。
• allkeys-random：当内存不足在键空间中，随机任意选择数据淘汰。
• no-eviction：禁止驱除数据，内存不足，禁止新数据写入，对新写入的操作会报错。<极端方式，真实场景下，这种策略不值得推荐>

在 4.0 后增加了两种模式：

• volatitle-lfu(least frequently used)：从设置已过期时间的数据集中移除最不经常使用的数据淘汰。
• allkeys-lfu(least frequently used)：当内存不足在键空间中，移除最不经常使用的数据淘汰。

3. 过期数据

有这样一种场景，应用1 向主节点写数据，并且设置失效时间。

3.1. 读取 Master

应用数据已经过期，主库的惰性删除会发生作用，主动对该数据进行删除操作，保证 客户端应用不会拿到过期的数据。

3.2. 读取 Slave

如果 读取的是 Slave 库，则有可能会拿到过期数据，一般造成这样原因有两个。

3.2.1. 版本过低

这样的场景由于 Redis 控制不住过期数据被客户端应用误读，形成数据不安全。但是 Redis 从 3.2 版本后，对此类场景的数据问题做过滤，并且返回空值。所以 如果有应用此场景，需要对 Redis 进行升级操作。

3.2.2. 过期时间设置

与过期时间设置方式有关系，一般我们采用 EXPIRE 和 PEXPIRE，都表示从执行命令那个时刻即 开始时间 开始，往后延长 ttl 时间，严重依赖于 开始时间 从什么时候算起。

上图描述的过程大致如下：

• Master 在 t1 时刻写入一个带过期时间的数据，数据的有效期一直到 t3
• 由于网络波动或者所在服务器自身执行问题，Slave 实际执行开始时间为 t2，数据有效期一直到 t5。
• 如果客户端应用在 t3 至 t4 时间段内访问，则可能获取到过期时间。

一般此种场景解决方案就是要求 主从节点服务器NTP时间服务保持时钟同步

4. 主从不一致

上图描述的过程大致如下：

• 在 T1 时间点，主库将主键 key1 的内容改为 100，此时通过主从异步同步，从库中的 key1 会拿到该数据
• 在 T2 时间点，主库将主键 key1 的内容改为 200，此时由于主从之间的网络问题，或者服务器正在处理 pipline 批处理操作，无法及时同步执行。

针对上述问题，我们建议针对 Redis 部署有如下要求：

• 主从服务器尽量部署在同一个机房，并保持服务器间的网络良好通畅
• 监控主从库间的同步进度，通过 info replication 命令 ，查看主库接收写命令的进度信息（master_repl_offset），从库的复制写命令的进度信息（slave_repl_offset）