大家好，又见面了，我是你们的朋友全栈君。
一、有效时间设置：
redis对存储值的过期处理实际上是针对该值的键（key）处理的，即时间的设置也是设置key的有效时间。Expires字典保存了所有键的过期时间，Expires也被称为过期字段。 四种处理策略
- EXPIRE 将key的生存时间设置为ttl秒
- PEXPIRE 将key的生成时间设置为ttl毫秒
- EXPIREAT 将key的过期时间设置为timestamp所代表的的秒数的时间戳
- PEXPIREAT 将key的过期时间设置为timestamp所代表的的毫秒数的时间戳
其实以上几种处理方式都是根据PEXPIREAT来实现的，设置生存时间的时候是redis内部计算好时间之后在内存处理的，最终的处理都会转向PEXPIREAT。 1、2两种方式是设置一个过期的时间段，就是咱们处理验证码最常用的策略，设置三分钟或五分钟后失效，把分钟数转换成秒或毫秒存储到redis中。 3、4两种方式是指定一个过期的时间 ，比如优惠券的过期时间是某年某月某日，只是单位不一样。
二、过期处理
过期键的处理就是把过期键删除，这里的操作主要是针对过期字段处理的。 Redis中有三种处理策略：定时删除、惰性删除和定期删除。
- 定时删除：在设置键的过期时间的时候创建一个定时器，当过期时间到的时候立马执行删除操作。不过这种处理方式是即时的，不管这个时间内有多少过期键，不管服务器现在的运行状况，都会立马执行，所以对CPU不是很友好。
- 惰性删除：惰性删除策略不会在键过期的时候立马删除，而是当外部指令获取这个键的时候才会主动删除。处理过程为：接收get执行、判断是否过期（这里按过期判断）、执行删除操作、返回nil（空）。
- 定期删除：定期删除是设置一个时间间隔，每个时间段都会检测是否有过期键，如果有执行删除操作。这个概念应该很好理解。
看完上面三种策略后可以得出以下结论： 4. 1、3为主动删除，2为被动删除。 5. 1是实时执行的，对CPU不是很友好，但是这在最大程度上释放了内存，所以这种方式算是一种内存优先优化策略。 6. 2、3为被动删除，所以过期键应该会存在一定的时间，这样就使得过期键不会被立马删除，仍然占用着内存。但是惰性删除的时候一般是单个删除，相对来说对CPU是友好的。 7. 定期键这种删除策略是一种让人很蛋疼的策略，它既有避免1、2两种策略劣势的可能，也有同时发生1、2两种策略劣势的可能。如果定期删除执行的过于频繁就可能会演变成定时删除，如果执行的过少就有可能造成过多过期键未被删除而占用过多内存，如果时间的设置不是太好，既可能占用过多内存又同时对CPU产生不好的影响。所以。使用定期删除的时候一定要把握好这个删除的时间点。
三、主从服务器删除过期键处理
有三种：RDB持久化、AOF持久化和复制功能。
RDB： 1. 主服务器模式运行在载入RDB文件时，程序会检查文件中的键，只会加载未过期的，过期的会被忽略，所以RDB模式下过期键不会对主服务器产生影响。 2. 从服务器运行载入RDB文件时，会载入所有键，包括过期和未过期。当主服务器进行数据同步的时候，从服务器的数据会被清空，所以RDB文件的过期键一般不会对从服务器产生影响。
AOF： AOF文件不会受过期键的影响。如果有过期键未被删除，会执行以下动作： 客户端请求时（过期键）：
- 从数据库充删除被访问的过期键；
- 追加一条DEL 命令到AOF文件；
- 向执行请求的客户端回复nil（空）。
复制：
- 主服务器删除过期键之后，向从服务器发送一条DEL指令，告知删除该过期键。
- 从服务器接收到get指令的时候不会对过期键进行处理，只会当做未过期键一样返回。（为了保持主从服务器数据的一致性）
- 从服务器只有接到主服务器发送的DEL指令后才会删除过期键。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/189377.html原文链接：https://javaforall.cn
