redis不设置过期时间(redis不设置过期时间为0)
1. redis不设置过期时间为0
EXPIRE 接口定义：EXPIRE key "seconds"
接口描述：设置一个key在当前时间"seconds"(秒)之后过期。返回1代表设置成功，返回0代表key不存在或者无法设置过期时间。
例如：EXPIRE aa 60
PEXPIRE 接口定义：PEXPIRE key "milliseconds"
接口描述：设置一个key在当前时间"milliseconds"(毫秒)之后过期。返回1代表设置成功，返回0代表key不存在或者无法设置过期时间。
例如：EXPIRE aa 60
(integer) 1 //设置
2. redis默认过期时间是多少
你访问数据之前会检查数据是否过期，过期的话就会回收，保证你不会读取到过期的数据。 redis里会有一个遍历器不停的遍历所有的key发现过期后就会回收内存。 内存不足时会加大过期数据回收的力度。
3. redis没有设置过期时间会删除吗
30分钟
下单时，订单状态是待支付。将订单编号作为key，下单的时间戳作为value，设置过期时间是30分钟。服务器监听redis的key过期事件，如果是订单过期（还会有其他key过期），则修改订单的状态为已取消。当30分钟后未支付则触发redis过期事件，只需修改订单状态即可。若30分钟内支付成功，则需要删除此订单在redis的值。
4. redis过期时间-1
首先，在Redis社区版本中正常的主从复制也会出现过期时间不一致问题，主要是由于主从进行全同步期间，如果主库此时有expire 命令，那么到从库中，该命令将会被延迟执行。因为全同步需要耗费时间，数据量越大，那么过期时间差距就越大。
这个问题其实已经是官方的已知问题，解决方案有两个：
1、业务采用expireat timestamp 方式，这样命令传送到从库就没有影响
2、在Redis代码中将expire命令转换为expireat命令
官方没有做第二个选择，反而是提供expireat命令来给用户选择。其实从另外一个角度来看，从库的过期时间大于主库的过期时间，其实影响不大。因为主库会主动触发过期删除，如果该key删除之后，主库也会向从库发送删除的命令。但是如果主库的key已经到了过期时间，redis没有及时进行淘汰，这个时候访问从库该key，那么这个key是不会被触发淘汰的，这样如果对于过期时间要求非常苛刻的业务还是会有影响的。
而且目前针对于我们大规模迁移的时间，在进行过期时间校验的时候，发现大量key的过期时间都不一致，这样也不利于我们进行校验。
所以针对第一个问题，我们将expire/pexpire/setex/psetex 命令在复制到从库的时候转换成时间戳的方式，比如expire 转成expireat命令，setex转换成set和expireat命令
2、迁移前后Redis key 数量不一致。
针对于第二个问题，Redis key 迁移前后数量不一致问题，其实在Redis社区版本的主从复制中，也会经常出现key数量不一致。其中一个非常关键的问题是，redis在做主从复制的时候，会对当前的存量数据做一个RDB快照（bgsave命令），然后将RDB快照传给从库，从库会解析RDB文件并且load到内存中。然而在下面的两个步骤中Redis会忽略过期的key：
1、主库在做RDB快照文件的时候，发现key已经过期了，则此时不会将过期时间写在RDB中
2、从库在load RDB 文件到内存中的时候，发现key已经过期了，则此时不会将过期的key load进去
针对上述问题，目前我们将以上两个步骤都改为不忽略过期key，过期key的删除统一由主库触发删除，然后将删除命令传送到从库中。这样key的数量就完全一致了。
最终在打上以上两个patch之后，再进
5. redis设置默认过期时间
过期时间删除的方法有三种：
1、删除这个key，使用del command
2、用set or getset 命令会将key的expiration清空，事实上set和getset命令是替换了key对应的value，所以key的过期时间也就不复存在。所以，需要注意的是：incr，LPUSH，HSET命令是不会改变key的过期时间的。原来是多久，这三条命令执行完之后还是多久。
3、使用persist命令清楚key的过期时间。
rename命令是将keyA变为keyB，无论keyB是否已经存在，keyA的过期时间都会被keyB继承过去。
6. redis如果不设置过期时间
redis可以通过设置key的过期时间，setExpire(key, 30)，key30秒后会自动过期掉。
7. redis过期时间一般设置多久
redis在使用分布式锁时最好给锁设置一个自动过期时间，合理的自动过期时间可以避免redis服务出现异常时产生死锁，设置了自动过期时间则会自动释放锁
8. redis设置过期时间的方法
一、有效时间设置：
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指令后才会删除过期键。