当前位置：Gxlcms > redis > redis数据过期时间设置

redis数据过期时间设置

时间：2021-07-01 10:21:17 帮助过：427人阅读

1、Redis中key的的过期时间

通过EXPIRE key seconds命令来设置数据的过期时间。返回1表明设置成功，返回0表明key不存在或者不能成功设置过期时间。在key上设置了过期时间后key将在指定的秒数后被自动删除。被指定了过期时间的key在Redis中被称为是不稳定的。

推荐：redis入门教程

当key被DEL命令删除或者被SET、GETSET命令重置后与之关联的过期时间会被清除

  1. 127.0.0.1:6379> setex s 20 1
  2. OK
  3. 127.0.0.1:6379> ttl s
  4. (integer) 17
  5. 127.0.0.1:6379> setex s 200 1
  6. OK
  7. 127.0.0.1:6379> ttl s
  8. (integer) 195
  9. 127.0.0.1:6379> setrange s 3 100
  10. (integer) 6
  11. 127.0.0.1:6379> ttl s
  12. (integer) 152
  13. 127.0.0.1:6379> get s
  14. "1\x00\x00100"
  15. 127.0.0.1:6379> ttl s
  16. (integer) 108
  17. 127.0.0.1:6379> getset s 200
  18. "1\x00\x00100"
  19. 127.0.0.1:6379> get s
  20. "200"
  21. 127.0.0.1:6379> ttl s
  22. (integer) -1

使用PERSIST可以清除过期时间

  1. 127.0.0.1:6379> setex s 100 test
  2. OK
  3. 127.0.0.1:6379> get s
  4. "test"
  5. 127.0.0.1:6379> ttl s
  6. (integer) 94
  7. 127.0.0.1:6379> type s
  8. string
  9. 127.0.0.1:6379> strlen s
  10. (integer) 4
  11. 127.0.0.1:6379> persist s
  12. (integer) 1
  13. 127.0.0.1:6379> ttl s
  14. (integer) -1
  15. 127.0.0.1:6379> get s
  16. "test"

使用rename只是改了key值

  1. 127.0.0.1:6379> expire s 200
  2. (integer) 1
  3. 127.0.0.1:6379> ttl s
  4. (integer) 198
  5. 127.0.0.1:6379> rename s ss
  6. OK
  7. 127.0.0.1:6379> ttl ss
  8. (integer) 187
  9. 127.0.0.1:6379> type ss
  10. string
  11. 127.0.0.1:6379> get ss
  12. "test"

说明：Redis2.6以后expire精度可以控制在0到1毫秒内，key的过期信息以绝对Unix时间戳的形式存储（Redis2.6之后以毫秒级别的精度存储），所以在多服务器同步的时候，一定要同步各个服务器的时间

2、Redis过期键删除策略

Redis key过期的方式有三种：

(1)、被动删除：当读/写一个已经过期的key时，会触发惰性删除策略，直接删除掉这个过期key

(2)、主动删除：由于惰性删除策略无法保证冷数据被及时删掉，所以Redis会定期主动淘汰一批已过期的key

(3)、当前已用内存超过maxmemory限定时，触发主动清理策略

被动删除

只有key被操作时(如GET)，REDIS才会被动检查该key是否过期，如果过期则删除之并且返回NIL。

1、这种删除策略对CPU是友好的，删除操作只有在不得不的情况下才会进行，不会其他的expire key上浪费无谓的CPU时间。

2、但是这种策略对内存不友好，一个key已经过期，但是在它被操作之前不会被删除，仍然占据内存空间。如果有大量的过期键存在但是又很少被访问到，那会造成大量的内存空间浪费。expireIfNeeded(redisDb *db, robj *key)函数位于src/db.c。

  1. /*-----------------------------------------------------------------------------
  2.  * Expires API
  3.  *----------------------------------------------------------------------------*/
  4.  
  5. int removeExpire(redisDb *db, robj *key) {
  6.     /* An expire may only be removed if there is a corresponding entry in the
  7.      * main dict. Otherwise, the key will never be freed. */
  8.     redisAssertWithInfo(NULL,key,dictFind(db->dict,key->ptr) != NULL);
  9.     return dictDelete(db->expires,key->ptr) == DICT_OK;
  10. }
  11.  
  12. void setExpire(redisDb *db, robj *key, long long when) {
  13.     dictEntry *kde, *de;
  14.  
  15.     /* Reuse the sds from the main dict in the expire dict */
  16.     kde = dictFind(db->dict,key->ptr);
  17.     redisAssertWithInfo(NULL,key,kde != NULL);
  18.     de = dictReplaceRaw(db->expires,dictGetKey(kde));
  19.     dictSetSignedIntegerVal(de,when);
  20. }
  21.  
  22. /* Return the expire time of the specified key, or -1 if no expire
  23.  * is associated with this key (i.e. the key is non volatile) */
  24. long long getExpire(redisDb *db, robj *key) {
  25.     dictEntry *de;
  26.  
  27.     /* No expire? return ASAP */
  28.     if (dictSize(db->expires) == 0 ||
  29.        (de = dictFind(db->expires,key->ptr)) == NULL) return -1;
  30.  
  31.     /* The entry was found in the expire dict, this means it should also
  32.      * be present in the main dict (safety check). */
  33.     redisAssertWithInfo(NULL,key,dictFind(db->dict,key->ptr) != NULL);
  34.     return dictGetSignedIntegerVal(de);
  35. }
  36.  
  37. /* Propagate expires into slaves and the AOF file.
  38.  * When a key expires in the master, a DEL operation for this key is sent
  39.  * to all the slaves and the AOF file if enabled.
  40.  *
  41.  * This way the key expiry is centralized in one place, and since both
  42.  * AOF and the master->slave link guarantee operation ordering, everything
  43.  * will be consistent even if we allow write operations against expiring
  44.  * keys. */
  45. void propagateExpire(redisDb *db, robj *key) {
  46.     robj *argv[2];
  47.  
  48.     argv[0] = shared.del;
  49.     argv[1] = key;
  50.     incrRefCount(argv[0]);
  51.     incrRefCount(argv[1]);
  52.  
  53.     if (server.aof_state != REDIS_AOF_OFF)
  54.         feedAppendOnlyFile(server.delCommand,db->id,argv,2);
  55.     replicationFeedSlaves(server.slaves,db->id,argv,2);
  56.  
  57.     decrRefCount(argv[0]);
  58.     decrRefCount(argv[1]);
  59. }
  60.  
  61. int expireIfNeeded(redisDb *db, robj *key) {
  62.     mstime_t when = getExpire(db,key);
  63.     mstime_t now;
  64.  
  65.     if (when < 0) return 0; /* No expire for this key */
  66.  
  67.     /* Don't expire anything while loading. It will be done later. */
  68.     if (server.loading) return 0;
  69.  
  70.     /* If we are in the context of a Lua script, we claim that time is
  71.      * blocked to when the Lua script started. This way a key can expire
  72.      * only the first time it is accessed and not in the middle of the
  73.      * script execution, making propagation to slaves / AOF consistent.
  74.      * See issue #1525 on Github for more information. */
  75.     now = server.lua_caller ? server.lua_time_start : mstime();
  76.  
  77.     /* If we are running in the context of a slave, return ASAP:
  78.      * the slave key expiration is controlled by the master that will
  79.      * send us synthesized DEL operations for expired keys.
  80.      *
  81.      * Still we try to return the right information to the caller,
  82.      * that is, 0 if we think the key should be still valid, 1 if
  83.      * we think the key is expired at this time. */
  84.     if (server.masterhost != NULL) return now > when;
  85.  
  86.     /* Return when this key has not expired */
  87.     if (now <= when) return 0;
  88.  
  89.     /* Delete the key */
  90.     server.stat_expiredkeys++;
  91.     propagateExpire(db,key);
  92.     notifyKeyspaceEvent(REDIS_NOTIFY_EXPIRED,
  93.         "expired",key,db->id);
  94.     return dbDelete(db,key);
  95. }
  96.  
  97. /*-----------------------------------------------------------------------------
  98.  * Expires Commands
  99.  *----------------------------------------------------------------------------*/
  100.  
  101. /* This is the generic command implementation for EXPIRE, PEXPIRE, EXPIREAT
  102.  * and PEXPIREAT. Because the commad second argument may be relative or absolute
  103.  * the "basetime" argument is used to signal what the base time is (either 0
  104.  * for *AT variants of the command, or the current time for relative expires).
  105.  *
  106.  * unit is either UNIT_SECONDS or UNIT_MILLISECONDS, and is only used for
  107.  * the argv[2] parameter. The basetime is always specified in milliseconds. */
  108. void expireGenericCommand(redisClient *c, long long basetime, int unit) {
  109.     robj *key = c->argv[1], *param = c->argv[2];
  110.     long long when; /* unix time in milliseconds when the key will expire. */
  111.  
  112.     if (getLongLongFromObjectOrReply(c, param, &when, NULL) != REDIS_OK)
  113.         return;
  114.  
  115.     if (unit == UNIT_SECONDS) when *= 1000;
  116.     when += basetime;
  117.  
  118.     /* No key, return zero. */
  119.     if (lookupKeyRead(c->db,key) == NULL) {
  120.         addReply(c,shared.czero);
  121.         return;
  122.     }
  123.  
  124.     /* EXPIRE with negative TTL, or EXPIREAT with a timestamp into the past
  125.      * should never be executed as a DEL when load the AOF or in the context
  126.      * of a slave instance.
  127.      *
  128.      * Instead we take the other branch of the IF statement setting an expire
  129.      * (possibly in the past) and wait for an explicit DEL from the master. */
  130.     if (when <= mstime() && !server.loading && !server.masterhost) {
  131.         robj *aux;
  132.  
  133.         redisAssertWithInfo(c,key,dbDelete(c->db,key));
  134.         server.dirty++;
  135.  
  136.         /* Replicate/AOF this as an explicit DEL. */
  137.         aux = createStringObject("DEL",3);
  138.         rewriteClientCommandVector(c,2,aux,key);
  139.         decrRefCount(aux);
  140.         signalModifiedKey(c->db,key);
  141.         notifyKeyspaceEvent(REDIS_NOTIFY_GENERIC,"del",key,c->db->id);
  142.         addReply(c, shared.cone);
  143.         return;
  144.     } else {
  145.         setExpire(c->db,key,when);
  146.         addReply(c,shared.cone);
  147.         signalModifiedKey(c->db,key);
  148.         notifyKeyspaceEvent(REDIS_NOTIFY_GENERIC,"expire",key,c->db->id);
  149.         server.dirty++;
  150.         return;
  151.     }
  152. }
  153.  
  154. void expireCommand(redisClient *c) {
  155.     expireGenericCommand(c,mstime(),UNIT_SECONDS);
  156. }
  157.  
  158. void expireatCommand(redisClient *c) {
  159.     expireGenericCommand(c,0,UNIT_SECONDS);
  160. }
  161.  
  162. void pexpireCommand(redisClient *c) {
  163.     expireGenericCommand(c,mstime(),UNIT_MILLISECONDS);
  164. }
  165.  
  166. void pexpireatCommand(redisClient *c) {
  167.     expireGenericCommand(c,0,UNIT_MILLISECONDS);
  168. }
  169.  
  170. void ttlGenericCommand(redisClient *c, int output_ms) {
  171.     long long expire, ttl = -1;
  172.  
  173.     /* If the key does not exist at all, return -2 */
  174.     if (lookupKeyRead(c->db,c->argv[1]) == NULL) {
  175.         addReplyLongLong(c,-2);
  176.         return;
  177.     }
  178.     /* The key exists. Return -1 if it has no expire, or the actual
  179.      * TTL value otherwise. */
  180.     expire = getExpire(c->db,c->argv[1]);
  181.     if (expire != -1) {
  182.         ttl = expire-mstime();
  183.         if (ttl < 0) ttl = 0;
  184.     }
  185.     if (ttl == -1) {
  186.         addReplyLongLong(c,-1);
  187.     } else {
  188.         addReplyLongLong(c,output_ms ? ttl : ((ttl+500)/1000));
  189.     }
  190. }
  191.  
  192. void ttlCommand(redisClient *c) {
  193.     ttlGenericCommand(c, 0);
  194. }
  195.  
  196. void pttlCommand(redisClient *c) {
  197.     ttlGenericCommand(c, 1);
  198. }
  199.  
  200. void persistCommand(redisClient *c) {
  201.     dictEntry *de;
  202.  
  203.     de = dictFind(c->db->dict,c->argv[1]->ptr);
  204.     if (de == NULL) {
  205.         addReply(c,shared.czero);
  206.     } else {
  207.         if (removeExpire(c->db,c->argv[1])) {
  208.             addReply(c,shared.cone);
  209.             server.dirty++;
  210.         } else {
  211.             addReply(c,shared.czero);
  212.         }
  213.     }
  214. }

但仅是这样是不够的，因为可能存在一些key永远不会被再次访问到，这些设置了过期时间的key也是需要在过期后被删除的，我们甚至可以将这种情况看作是一种内存泄露----无用的垃圾数据占用了大量的内存，而服务器却不会自己去释放它们，这对于运行状态非常依赖于内存的Redis服务器来说，肯定不是一个好消息

主动删除

先说一下时间事件，对于持续运行的服务器来说， 服务器需要定期对自身的资源和状态进行必要的检查和整理， 从而让服务器维持在一个健康稳定的状态， 这类操作被统称为常规操作（cron job）

在 Redis 中， 常规操作由 redis.c/serverCron 实现， 它主要执行以下操作：

更新服务器的各类统计信息，比如时间、内存占用、数据库占用情况等。

清理数据库中的过期键值对。

对不合理的数据库进行大小调整。

关闭和清理连接失效的客户端。

尝试进行 AOF 或 RDB 持久化操作。

如果服务器是主节点的话，对附属节点进行定期同步。

如果处于集群模式的话，对集群进行定期同步和连接测试。

Redis 将 serverCron 作为时间事件来运行， 从而确保它每隔一段时间就会自动运行一次， 又因为 serverCron 需要在 Redis 服务器运行期间一直定期运行， 所以它是一个循环时间事件： serverCron 会一直定期执行，直到服务器关闭为止。

在 Redis 2.6 版本中， 程序规定 serverCron 每秒运行 10 次， 平均每 100 毫秒运行一次。 从 Redis 2.8 开始， 用户可以通过修改 hz选项来调整 serverCron 的每秒执行次数。

也叫定时删除，这里的“定期”指的是Redis定期触发的清理策略，由位于src/redis.c的activeExpireCycle(void)函数来完成。

serverCron是由redis的事件框架驱动的定位任务，这个定时任务中会调用activeExpireCycle函数，针对每个db在限制的时间REDIS_EXPIRELOOKUPS_TIME_LIMIT内迟可能多的删除过期key，之所以要限制时间是为了防止过长时间 的阻塞影响redis的正常运行。这种主动删除策略弥补了被动删除策略在内存上的不友好。

因此，Redis会周期性的随机测试一批设置了过期时间的key并进行处理。测试到的已过期的key将被删除。典型的方式为,Redis每秒做10次如下的步骤：

(1)随机测试100个设置了过期时间的key

(2)删除所有发现的已过期的key

(3)若删除的key超过25个则重复步骤1

这是一个基于概率的简单算法，基本的假设是抽出的样本能够代表整个key空间，redis持续清理过期的数据直至将要过期的key的百分比降到了25%以下。这也意味着在任何给定的时刻已经过期但仍占据着内存空间的key的量最多为每秒的写操作量除以4.

Redis-3.0.0中的默认值是10，代表每秒钟调用10次后台任务。

除了主动淘汰的频率外，Redis对每次淘汰任务执行的最大时长也有一个限定，这样保证了每次主动淘汰不会过多阻塞应用请求，以下是这个限定计算公式：

  1. #define ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC 25 /* CPU max % for keys collection */ 
  2. ... 
  3. timelimit = 1000000*ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC/server.hz/100;

hz调大将会提高Redis主动淘汰的频率，如果你的Redis存储中包含很多冷数据占用内存过大的话，可以考虑将这个值调大，但Redis作者建议这个值不要超过100。我们实际线上将这个值调大到100，观察到CPU会增加2%左右，但对冷数据的内存释放速度确实有明显的提高（通过观察keyspace个数和used_memory大小）。

可以看出timelimit和server.hz是一个倒数的关系，也就是说hz配置越大，timelimit就越小。换句话说是每秒钟期望的主动淘汰频率越高，则每次淘汰最长占用时间就越短。这里每秒钟的最长淘汰占用时间是固定的250ms（1000000*ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC/100），而淘汰频率和每次淘汰的最长时间是通过hz参数控制的。

从以上的分析看，当redis中的过期key比率没有超过25%之前，提高hz可以明显提高扫描key的最小个数。假设hz为10，则一秒内最少扫描200个key（一秒调用10次*每次最少随机取出20个key），如果hz改为100，则一秒内最少扫描2000个key；另一方面，如果过期key比率超过25%，则扫描key的个数无上限，但是cpu时间每秒钟最多占用250ms。

当REDIS运行在主从模式时，只有主结点才会执行上述这两种过期删除策略，然后把删除操作”del key”同步到从结点。

maxmemory

当前已用内存超过maxmemory限定时，触发主动清理策略：

volatile-lru：只对设置了过期时间的key进行LRU（默认值）

allkeys-lru ： 删除lru算法的key

volatile-random：随机删除即将过期key

allkeys-random：随机删除

volatile-ttl ： 删除即将过期的

noeviction ： 永不过期，返回错误当mem_used内存已经超过maxmemory的设定，对于所有的读写请求，都会触发redis.c/freeMemoryIfNeeded(void)函数以清理超出的内存。注意这个清理过程是阻塞的，直到清理出足够的内存空间。所以如果在达到maxmemory并且调用方还在不断写入的情况下，可能会反复触发主动清理策略，导致请求会有一定的延迟。

当mem_used内存已经超过maxmemory的设定，对于所有的读写请求，都会触发redis.c/freeMemoryIfNeeded(void)函数以清理超出的内存。注意这个清理过程是阻塞的，直到清理出足够的内存空间。所以如果在达到maxmemory并且调用方还在不断写入的情况下，可能会反复触发主动清理策略，导致请求会有一定的延迟。

清理时会根据用户配置的maxmemory-policy来做适当的清理（一般是LRU或TTL），这里的LRU或TTL策略并不是针对redis的所有key，而是以配置文件中的maxmemory-samples个key作为样本池进行抽样清理。

maxmemory-samples在redis-3.0.0中的默认配置为5，如果增加，会提高LRU或TTL的精准度，redis作者测试的结果是当这个配置为10时已经非常接近全量LRU的精准度了，并且增加maxmemory-samples会导致在主动清理时消耗更多的CPU时间，建议：

(1)尽量不要触发maxmemory，最好在mem_used内存占用达到maxmemory的一定比例后，需要考虑调大hz以加快淘汰，或者进行集群扩容。

(2)如果能够控制住内存，则可以不用修改maxmemory-samples配置；如果Redis本身就作为LRU cache服务（这种服务一般长时间处于maxmemory状态，由Redis自动做LRU淘汰），可以适当调大maxmemory-samples。

以下是上文中提到的配置参数的说明

  1. # Redis calls an internal function to perform many background tasks, like 
  2. # closing connections of clients in timeout, purging expired keys that are 
  3. # never requested, and so forth. 
  4. # 
  5. # Not all tasks are performed with the same frequency, but Redis checks for 
  6. # tasks to perform according to the specified "hz" value. 
  7. # 
  8. # By default "hz" is set to 10. Raising the value will use more CPU when 
  9. # Redis is idle, but at the same time will make Redis more responsive when 
  10. # there are many keys expiring at the same time, and timeouts may be 
  11. # handled with more precision. 
  12. # 
  13. # The range is between 1 and 500, however a value over 100 is usually not 
  14. # a good idea. Most users should use the default of 10 and raise this up to 
  15. # 100 only in environments where very low latency is required. 
  16. hz 10 
  17.  
  18. # MAXMEMORY POLICY: how Redis will select what to remove when maxmemory 
  19. # is reached. You can select among five behaviors: 
  20. # 
  21. # volatile-lru -> remove the key with an expire set using an LRU algorithm 
  22. # allkeys-lru -> remove any key according to the LRU algorithm 
  23. # volatile-random -> remove a random key with an expire set 
  24. # allkeys-random -> remove a random key, any key 
  25. # volatile-ttl -> remove the key with the nearest expire time (minor TTL) 
  26. # noeviction -> don't expire at all, just return an error on write operations 
  27. # 
  28. # Note: with any of the above policies, Redis will return an error on write 
  29. #       operations, when there are no suitable keys for eviction. 
  30. # 
  31. #       At the date of writing these commands are: set setnx setex append 
  32. #       incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd 
  33. #       sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby 
  34. #       zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby 
  35. #       getset mset msetnx exec sort 
  36. # 
  37. # The default is: 
  38. # 
  39. maxmemory-policy noeviction 
  40.  
  41. # LRU and minimal TTL algorithms are not precise algorithms but approximated 
  42. # algorithms (in order to save memory), so you can tune it for speed or 
  43. # accuracy. For default Redis will check five keys and pick the one that was 
  44. # used less recently, you can change the sample size using the following 
  45. # configuration directive. 
  46. # 
  47. # The default of 5 produces good enough results. 10 Approximates very closely 
  48. # true LRU but costs a bit more CPU. 3 is very fast but not very accurate. 
  49. # 
  50. maxmemory-samples 5

Replication link和AOF文件中的过期处理

为了获得正确的行为而不至于导致一致性问题，当一个key过期时DEL操作将被记录在AOF文件并传递到所有相关的slave。也即过期删除操作统一在master实例中进行并向下传递，而不是各salve各自掌控。

这样一来便不会出现数据不一致的情形。当slave连接到master后并不能立即清理已过期的key（需要等待由master传递过来的DEL操作），slave仍需对数据集中的过期状态进行管理维护以便于在slave被提升为master会能像master一样独立的进行过期处理。

以上就是redis数据过期时间设置的详细内容，更多请关注Gxlcms其它相关文章！

人气教程排行

本站所有资源全部来源于网络，若本站发布的内容侵害到您的隐私或者利益，请联系我们删除！