本篇文章给大家谈谈redis设置超时时间，以及redis阻塞连接超时对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。
本文目录
一、Redis过期时间
给一个 key设置超时时间。在一个超时时间结束后，这个键将会被自动删除。一个拥有关联过期时间的键在Redis术语里通常被认为不稳定的。
只有删除或者覆盖键的内容的命令，包括 DEL, SET, GETSET和所有的*STORE命令，才会把过期时间清除。这意味着从理论上讲，所有改变键上存储的值而不是使用新的值来替换的操作，都将会保持过期时间不变。例如，使用 INCR增加一个键的值，使用 LPUSH讲一个新的值放到列表中，或者使用 HSET改变一个哈希的字段的值都将会使过期时间保持不变。
使用 PERSIST命令将一个键变成持久化的键，过期时间也会被清除。
如果一个键被 RENAME重命名，关联的生存时间将会被转移到新的键名上。
如果一个键被 RENAME重命名，就像在一个已经存在的键 Key_A，它被一个调用 RENAME Key_B Key_A所覆盖，原始的 Key_A是否关联过期时间是没关系的，新的键 Key_A将会继承 Key_B的所有特征。
注意，使用负数调用 EXPIRE/ PEXPIRE，或者使用过去的时间调用 EXPIREAT/ PEXPIREAT将会使键被删除，而不是过期(相应的，弹出的 key event将会是 del，而不是 expired)。
可以使用一个已经有过期时间集的键作为参数来调用 EXPIRE。在这种情况下，一个键的生存时间已经更新为一个新值。对此很多应用，下面的 Navigation session模式一节记录了一个例子。
在Redis 2.1.3之前的版本中，使用一个命令改变一个拥有过期时间的键的值，效果跟彻底移除这个键一样。这种语义是必须的，因为复制层的限制现在已经确定了。
EXPIRE将会返回0，并且不会使用一个过期时间 *** 来改变一个键的过期时间。
redis> SET mykey"Hello World"
想象你有一个网页服务，并且你对用户最近访问的N个页面有兴趣，这样每个临近的页面视图的执行时间不会超过前一个页面视图执行的60秒。理论上来讲，你可以认为用户访问的页面 *** 为 Navigation session，其中就可以包含用户在寻找哪些他或她感兴趣的产品信息，因此你可以推荐关联的产品。
你可以非常容易的使用下面的策略在Redis中建模这种类型：每次用户访问一个页面你就调用下面的命令：
如果用户闲置超过60秒，这个键将会被删除，只有访问时间差值小于60秒的页面才会被记录。
这个模式可以很容易的修改为使用 INCR做计数器来替代使用 RPUSH的列表。
通常情况下创建Redis的键时不关联生存时间。这个键将会简单的一直生存，除非用户显示的删除它，例如使用 DEL命令。
EXPIRE家族命令能够把一个过期时间关联到一个给定的键，代价是这个键会使用额外的内存。当一个键设置了过期时间，Redis将会确保当指定的时间过去之后移除这个键。
一个键的生存时间可以被 EXPIRE命令更新，或者被 PERSIST命令完全移除(或其他严格相关的命令)。
在Redis2.4版本中，过期时间可能不是非常精确的，并且它可能是在0到1秒之间的出入。从Redis2.6版本开始，过期时间误差是从0到1毫秒。
键的过期信息以绝对的Unix时间戳形式保存(Redis2.6以及更新的版本毫秒内)。这意味着甚至当Redis实例未启动时时间就流走了。
为了过期时间能工作的很好，计算机时间必须保持稳定。如果你从两个时钟巨大不同步的计算机上移动一个RDB文件，有趣的事情将会发生(像所有的键在加载时变成过期)。
实际上运行中的实例将一直会检查计算机的时钟，举例来说，如果你给一个键设置1000秒的生存时间，然后在未来将你的计算机设置在2000秒以后，这个键将会立即失效，而不是持续1000秒。
Redis键将会通过两种方式过期：一个被动的方式，和一个主动的方式。
一个键的被动过期是很简单的，当一些客户端尝试访问它，然后这个键被发现超时了。
当然，这是不够的，因为有一些键将永远不会被再次访问。这些键无论如何都应该被过期。所以，Redis会定期的在过期的 *** 中随机范围内测试少量的键。所有的已过期的键将会被从键空间被删除。
这就是Redis会在每秒做10次的事情：
这是一个小概率的算法，基本的设想是我们的样本代表整个键空间，然后我们继续失效直到将要失效的键百分比小于25%。
这意味着在任何一个时刻，正在使用内存的已经过期的更大数量的键等于每秒更大写操作数量除以4.
为了获得正确的行为而不牺牲一致性，当一个键失效， DEL操作会同时在AOF文件和附属的副节点执行。这种方式失效进程是在主实例集中的，也不会出现一致性错误。
然而，当副本已经连接到主节点后将不会独立的失效键(但将会等待来自主节点的 DEL)，他们仍将会获取数据集中的全部过期状态，所以当一个副本被选举为主节点后，它将能够独立的失效这些键，完全像一个主节点。
二、redis expire 0秒会怎么样
memcached和 redis的set命令都有expire参数，可以设置key的过期时间。但是redis是一个可以对数据持久化的key-value database，它的key过期策略还是和memcached有所不同的。梳理，整理如下：
redis通过expire命令来设置key的过期时间。
语法：redis.expire(key, expiration)
1.在小于2.1.3的redis版本里，只能对key设置一次expire。redis2.1.3和之后的版本里，可以多次对key使用expire命令，更新key的expire time。
2. redis术语里面，把设置了expire time的key叫做：volatile keys。意思就是不稳定的key。
3.如果对key使用set或del命令，那么也会移除expire time。尤其是set命令，这个在编写程序的时候需要注意一下。
4. redis2.1.3之前的老版本里，如果对volatile keys做相关写入操作(LPUSH,LSET)，和其他一些触发修改value的操作时，redis会删除该key。也就是说：
三、Redis RDB持久化和AOF持久化详细讲解
Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成的数据丢失问题，当下次重启时利用之前持久化的文件即可实现数据恢复。Redis支持两种方式的持久化，一种是RDB方式，一种是AOF方式。可以单独使用其中一种或将二者结合使用。
RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。
手动触发分别对应save和bgsave命令：
除了执行命令手动触发之外，Redis内部还存在自动触发RDB的持久化机制。如以下场景：
1）使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改时，自动触发bgsave。
2）如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
3）执行debug reload命令重新加载Redis时，也会自动触发save操作。
4）默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则自动执行bgsave。
bgsave是主流的触发RDB持久化方式，它的运作流程如下图：
1）执行bgsave命令，Redis父进程判断当前是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回。
2）父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats命令查看latest_fork_usec选项，可以获取最近一个fork操作的耗时，单位为微秒。
3）父进程fork完成后，bgsave命令返回“Background saving started”信息并不再阻塞父进程，可以继续响应其他命令。
4）子进程创建RDB文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计的rdb_last_save_time选项。
5）进程发送信号给父进程表示完成，父进程更新统计信息。
保存：RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定。可以通过执行config set dir{newDir}和config setdbfilename{newFileName}运行期动态执行，当下次运行时RDB文件会保存到新目录。
压缩：Redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可以通过参数config set rdbcompression{yes|no}动态修改。
校验：如果Redis加载损坏的RDB文件时拒绝启动，并打印如下日志：
这时可以使用Redis提供的redis-check-dump工具检测RDB文件并获取对应的错误报告。
AOF（append only file）持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。
开启AOF功能需要设置配置：appendonly yes，默认不开启。AOF文件名通过appendfilename配置设置，默认文件名是appendonly.aof。保存路径同RDB持久化方式一致，通过dir配置指定。
AOF的工作流程操作：命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）。如下图所示：
1）所有的写入命令会追加到aof_buf（缓冲区）中。
2）AOF缓冲区根据对应的策略向硬盘做同步操作。
3）随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的。
4）当Redis服务器重启时，可以加载AOF文件进行数据恢复。
AOF命令写入的内容直接是文本协议格式，开启AOF后，所有写入命令都包含追加操作，直接采用文本协议格式，避免了二次处理开销。
Redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制。
always:命令写入aof_buf后，调用系统ysnyc操作同步到AOF文件，ysnyc完成后线程返回。
everysec:命令写入aof_buf后，调用系统write操作,write完成后线程返回。ysnyc同步文件操作由专门线程每秒调用一次。
no：命令写入aof_buf后，调用系统write操作，不对AOF文件做ysnyc同步，同步硬盘操作由操作系统负责，通常同步周期最长30秒。
Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。
AOF重写机制压缩文件体积的原因：
1）进程内已经超时的数据不再写入文件。
2）旧的AOF文件含有无效命令，重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令。
3）多条写命令可以合并为一个，为了防止单条命令过大造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。
AOF重写过程可以手动触发和自动触发：
auto-aof-rewrite-min-size：表示运行AOF重写时文件最小体积，默认为64MB。auto-aof-rewrite-percentage：代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的比值。
自动触发时机=aof_current_size>auto-aof-rewrite-min-size&&（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewrite-percentage。其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看。
1）执行AOF重写请求。如果当前进程正在执行AOF重写，请求不执行并返回如下响应：
如果当前进程正在执行bgsave操作，重写命令延迟到bgsave完成之后再执行，返回如下响应：
2）父进程执行fork创建子进程，开销等同于bgsave过程。
3.1）主进程fork操作完成后，继续响应其他命令。所有修改命令依然写入AOF缓冲区并根据appendfsync策略同步到硬盘，保证原有AOF机制正确性。
3.2）由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用“AOF重写缓冲区”保存这部分新数据，防止新AOF文件生成期间丢失这部分数据。
4）子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认为32MB，防止单次刷盘数据过多造成硬盘阻塞。
5.1）新AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息，具体见info persistence下的aof_*相关统计。
5.2）父进程把AOF重写缓冲区的数据写入到新的AOF文件。
5.3）使用新AOF文件替换老文件，完成AOF重写。
AOF和RDB文件都可以用于服务器重启时的数据恢复。Redis持久化文件加载流程如下图：
1）AOF持久化开启且存在AOF文件时，优先加载AOF文件，打印如下日志：
2）AOF关闭或者AOF文件不存在时，加载RDB文件，打印如下日志：
3）加载AOF/RDB文件成功后，Redis启动成功。
4）AOF/RDB文件存在错误时，Redis启动失败并打印错误信息。
加载损坏的AOF文件时会拒绝启动，并打印如下日志：
对于错误格式的AOF文件，先进行备份，然后采用redis-check-aof--fix命令进行修复，修复后使用diff-u对比数据的差异，找出丢失的数据，有些可以人工修改补全。
AOF文件可能存在结尾不完整的情况，Redis为我们提供了aof-load-truncated配置来兼容这种情况，默认开启。加载AOF时，当遇到此问题时会忽略并继续启动，同时打印如下警告日志：
OK，本文到此结束，希望对大家有所帮助。
