1. 目录
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）
