关于后端:redis的key过期策略内存淘汰策略

redis 的过期策略次要是定期删除和懒删除来实现的

redis 定时每距离大概 100ms 进行随机抽抉择 1 批 key，对过期的 key 进行删除, 并且依据过期 key 的占比以及执行的实现来是否持续循环。为了就是在可控的工夫内尽可能删除过期的 key 并且尽量不占用太多 CPU 资源影响业务申请。
具体步骤：

1. 从过期字典最近抽取 20 个 key
2. 将这个 20 个 key 中过期的 key 进行删除，如果过期的 key 占比抽样的个数占比超过 25%，反复 1 步骤；同时防止统一循环，执行工夫超过 25ms 退出循环；

通过定期删除，能够在肯定水平上删除过期的 key，然而可能删除不及时，又被申请拜访到，所以在申请拜访到过期 key 时，会触发删除，并且返回空给业务，保障过期的语义准确性。

问：发现 key 过期时进行删除时，是异步删除还是同步删除？可能存在什么问题
答：4.0 之前是同步删除，如果是 big key，同步删除会导致执行工夫长，导致命令超时曾经后续命令的执行超时等；4.0 之后，为了解决删除 big key 带来的阻塞问题，提供了异步删除机制，如果判断是 big key，将其扔到队列就返回，有专门的后盾线程进行删除。

redis 为了应答内存不足的场景，定制了 8 种策略给应用方进行配置抉择，具体如下：

Redis 4.0 之前有以下 6 种淘汰策略：
noeviction：不淘汰任何数据，当内存不足时，新增操作会报错，读申请不受影响，Redis 默认内存淘汰策略；
allkeys-lru：淘汰整个键值中最久未应用的键值；
allkeys-random：随机淘汰任意键值;
volatile-lru：淘汰所有设置了过期工夫的键值中最久未应用的键值；
volatile-random：随机淘汰设置了过期工夫的任意键值；
volatile-ttl：优先淘汰更早过期的键值。
在 Redis 4.0 版本中又新增了 2 种淘汰策略：
volatile-lfu：淘汰所有设置了过期工夫的键值中，起码应用的键值；
allkeys-lfu：淘汰整个键值中起码应用的键值。
其中 allkeys-xxx 示意从所有的键值中淘汰数据，而 volatile-xxx 示意从设置了过期键的键值中淘汰数据。

 实战倡议：生产实战中，应用最多的是 volatile-lru。同时听过配置应用容量阈值告警，个别超过 60~80% 就触发告警，评估是否须要进行扩容，避免出现超过最大内存。

redis 的 key 过期策略是怎么样的