新增一个Redis 从节点为什么与主节点的key数量不一样呢？

在日常的 Redis 运维过程中，经常会发生重载 RDB 文件操作，主要情形有：

• 主从架构如果主库宕机做高可用切换，原从库会挂载新主库重新获取数据
• 主库 QPS 超过10万，需要做读写分离，重新添加从库节点
• 服务器资源整合、机房迁移、架构调整等

在上述操作之后，你会发现新从库的 keys 数量和原主库的数量不一致，那么，为什么会这样呢？

问题解密：

在Redis中，内存的大小是有限的，所以为了防止内存饱和，需要由键淘汰策略对过期键做清除操作，主要有两种方法。

1. 内存释放策略

每当执行一个命令的时候，就会调用函数 freeMmoryIfNeeded 来检测内存是否够用，如果已用内存大于最大内存maxmemory限制，它就会根据以下策略进行内存释放，通过策略删除某些key，以达到释放内存保护自身进程的目的，参数maxmemory-policy可设定不同策略，已有策略如下：

• volatile-lru：驱逐keys，优先删除已设置过期的keys中最近最少使用的keys(云DB平台Redis默认策略)
• allKeys-lru：驱逐keys，优先删除所有最近最少使用的keys
• volatile-random：随机驱逐已设置过期的keys
• allKeys-random：随机驱逐所有keys以释放内存
• volatile-lfu：使用LFU算法驱逐keys，在过期的keys中驱逐（Redis V4.0版本新增策略）
• allKeys-lfu：使用LFU算法驱逐所有keys（Redis V4.0版本新增策略）
• volatile-ttl：驱逐设定过期时间且将要过期的key
• noeviction：达到最大内存限制，客户端尝试执行命令时，直接返回错误（DEL命令和其他很少命令例外）

2. 过期键删除策略
(1) 惰性删除
放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话，就删除该键;如果没有过期，就返回该键。
该策略对 CPU 来说是最友好的，只会在取出键时才对键进行过期检查，这可以保证删除过期键的操作只会在非做不可的情况下进行， 并且删除的目标仅限于当前处理的键，这个策略不会在删除其他无关的过期键上花费任何CPU时间。
惰性删除策略的缺点是，它对内存是最不友好的: 如果一个键已经过期，而这个键又仍然保留在数据库中，那么只要这个过期键不被删除，它所占用的内存就不会释放。
在使用惰性删除策略时，如果数据库中有非常多的过期键，而这些过期键又恰好没有被访问到的话，那么它们也许永远也不会被删除(除非用户手动执行FLUSHDB)。
我们甚至可以将这种情况看作是一种内存泄漏一一无用的垃圾数据占用了大量的内存，而服务器却不会自己去释放它们，这对于运行状态非常依赖于内存的Redis服务器来说，肯定不是一个好消息。
举个例子，对于一些和时间有关的数据，比如日志(log) ，在某个时间点之后，对它们的访问就会大大减少，甚至不再访问，如果这类过期数据大量地积压在数据库中，用户以为服务器已经自动将它们删除了，但实际上这些键仍然存在， 而且键所占用的内存也没有释放，那么造成的后果肯定是非常严重的。

(2) 定期删除

定期删除策略每隔一段时间执行一次删除过期键操作，并通过限制删除操作执行的时长和频率来减少删除操作对CPU 时间的影响。除此之外，通过定期删除过期键，定期删除策略有效地减少了因为过期键而带来的内存浪费。

定期删除策略的难点是确定删除操作执行的时长和频率:如果删除操作执行得太频繁，或者执行的时间太长，定期删除策略就会退化成定时删除策略，以至于将 CPU 时间过多地消耗在删除过期键上面。

如果删除操作执行得太少，或者执行的时间太短，定期删除策略又会和惰性删除策略一样，出现浪费内存的情况。因此，如果采用定期删除策略的话，服务器必须根据情况，合理地设置删除操作的执行时长和执行频率（通过参数 hz 调节）。

(3) 定时删除
定时删除策略对内存是最友好的:通过使用定时器，定时删除策略可以保证过期键会尽可能快地被删除，并释放过期键所占用的内存。另一方面，定时删除策略的缺点是，它对CPU 时间是最不友好的:在过期键比较多的情况下，删除过期键这一行为可能会占用相当一部分CPU 时间，在内存不紧张但是CPU 时间非常紧张的情况下.将CPU 时间用在删除和当前任务无关的过期键上，无疑会对服务器的响应时间和吞吐量造成影响。例如，如果正有大量的命令请求在等待服务器处理，并且服务器当前不缺少内存，那么服务器应该优先将CPU 时间用在处理客户端的命令请求上面，而不是用在删除过期键上面。

除此之外，创建一个定时器需要用到Redis 服务器中的时间事件，而当前时间事件的实现方式一一无序链表，查找一个事件的时间复杂度为O(N)一并不能高效地处理大量时间事件。因此，要让服务器创建大量的定时器，从而实现定时删除策略，在现阶段来说并不现实。

主从 keys 数量不一致原因
根据上面过期键删除策略，在从库重新挂载主库时，一般都会通过RDB文件重载数据，那么原主库在执行save命令或者BGSAVE命令创建一个新的RDB文件时，程序会对数据库中的键进行检查。已过期的键不会被保存到新创建的RDB文件中，但是仍然存在于原主库，这样在从库中看到的keys数量就会比主库少，此为正常现象。

看完本文有收获？请转发分享给更多人

关注「数据库架构师」公号，提升数据库技能