[redis] 数据库相关 -- 过期键的删除策略

被动删除策略：惰性删除

每次从键空间中获取键时，都检查键是否过期，过期就删除键。否则就返回键
优点：对 cpu 友好
缺点：占用已过期的键，但还没被删除的内存空间。

	实现函数 expireIfNeeded，位置 db.c / expireIfNeeded；

流程：

GET 命令流程：

主动删除策略：定期删除

每个一段时间，redis 程序对数据库进行一次检查，删除过期键。
优点：有效减少内存浪费
缺点：占用部分 cpu

	实现函数 activeExpireCycle，位置如下：
	版本 2.8: redis.c    / activeExpireCycle
	版本 5.0: expire.c  / activeExpireCycle

策略如下：内容来源于《Redis 深度历险：核心原理与应用实践 : 扩展4》

	Redis 默认会每秒进行十次过期扫描，过期扫描不会遍历过期字典中所有的 key，而是采用了一种简单的贪心策略。
		1. 从过期字典中随机 20 个 key；
		2. 删除这 20 个 key 中已经过期的 key；
		3. 如果过期的 key 比率超过 25%，那就重复步骤 1；
		同时，为了保证过期扫描不会出现循环过度，导致线程卡死现象，算法还增加了扫描时间的上限，
		默认不会超过 25ms。
	
	若 Redis 实例中所有的 key 在同一时间过期了，会出现怎样的结果？
				毫无疑问，Redis 会持续扫描过期字典 (循环多次)，直到过期字典中过期的 key 变得稀疏，
		才会停止 (循环次数明显下降)。这就会导致线上读写请求出现明显的卡顿现象。
		导致这种卡顿的另外一种原因是内存管理器需要频繁回收内存页，这也会产生一定的 CPU 消耗。
			    当客户端请求到来时，服务器如果正好进入过期扫描状态，客户端的请求将会等待至少 25ms 后才会进行处理，
		如果客户端将超时时间设置的比较短，比如 10ms，那么就会出现大量的链接因为超时而关闭，
		业务端就会出现很多异常。而且这时你还无法从 Redis 的 slowlog 中看到慢查询记录，
		因为慢查询指的是逻辑处理过程慢，不包含等待时间。
		         所以业务开发人员一定要注意过期时间，如果有大批量的 key 过期，
		要给过期时间设置一个随机范围，而不宜全部在同一时间过期，分散过期处理的压力。

AOF、RDB 和复制对过期键的处理

1. AOF
   • AOF 写入：如果过期键未被删除，则会被保存到 AOF 文件中；当过期键被删除时，会向 AOF 文件中追加删除命令，来显式的记录该键被删除；
   • AOF 重写：已过期的键不会保存到重写后的 AOF 文件中；
2. RDB
   • 执行 SAVE 或 BGSAVE 命令时，已过期的键不会保存到新的 RDB 文件中。
   • 载入 RDB，如果服务器以主服务器模式运行，过期键会被忽略；如果以从服务器模式运行，无论键是否过期都会被载入。
3. 复制
   • 从服务器的过期键删除动作由主服务器控制；从服务器执行客户端的读命令时，如果读的是过期键，会将其当做未过期键来处理，并不会主动删除它；
   • 主服务器删除过期键时，会显式地向所有从服务器发送一个 DEL 命令，从服务器接收到命令后才会删除过期键。