麻豆小视频在线观看_中文黄色一级片_久久久成人精品_成片免费观看视频大全_午夜精品久久久久久久99热浪潮_成人一区二区三区四区

首頁 > 數據庫 > Redis > 正文

Redis中的數據過期策略詳解

2020-10-28 21:37:54
字體:
來源:轉載
供稿:網友

1、Redis中key的的過期時間

通過EXPIRE key seconds命令來設置數據的過期時間。返回1表明設置成功,返回0表明key不存在或者不能成功設置過期時間。在key上設置了過期時間后key將在指定的秒數后被自動刪除。被指定了過期時間的key在Redis中被稱為是不穩定的。

當key被DEL命令刪除或者被SET、GETSET命令重置后與之關聯的過期時間會被清除

127.0.0.1:6379> setex s 20 1OK127.0.0.1:6379> ttl s(integer) 17127.0.0.1:6379> setex s 200 1OK127.0.0.1:6379> ttl s(integer) 195127.0.0.1:6379> setrange s 3 100(integer) 6127.0.0.1:6379> ttl s(integer) 152127.0.0.1:6379> get s"1/x00/x00100"127.0.0.1:6379> ttl s(integer) 108127.0.0.1:6379> getset s 200"1/x00/x00100"127.0.0.1:6379> get s"200"127.0.0.1:6379> ttl s(integer) -1

使用PERSIST可以清除過期時間

127.0.0.1:6379> setex s 100 testOK127.0.0.1:6379> get s"test"127.0.0.1:6379> ttl s(integer) 94127.0.0.1:6379> type sstring127.0.0.1:6379> strlen s(integer) 4127.0.0.1:6379> persist s(integer) 1127.0.0.1:6379> ttl s(integer) -1127.0.0.1:6379> get s"test"

使用rename只是改了key值

127.0.0.1:6379> expire s 200(integer) 1127.0.0.1:6379> ttl s(integer) 198127.0.0.1:6379> rename s ssOK127.0.0.1:6379> ttl ss(integer) 187127.0.0.1:6379> type ssstring127.0.0.1:6379> get ss"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。

/*----------------------------------------------------------------------------- * Expires API *----------------------------------------------------------------------------*/ int removeExpire(redisDb *db, robj *key) { /* An expire may only be removed if there is a corresponding entry in the * main dict. Otherwise, the key will never be freed. */ redisAssertWithInfo(NULL,key,dictFind(db->dict,key->ptr) != NULL); return dictDelete(db->expires,key->ptr) == DICT_OK;} void setExpire(redisDb *db, robj *key, long long when) { dictEntry *kde, *de;  /* Reuse the sds from the main dict in the expire dict */ kde = dictFind(db->dict,key->ptr); redisAssertWithInfo(NULL,key,kde != NULL); de = dictReplaceRaw(db->expires,dictGetKey(kde)); dictSetSignedIntegerVal(de,when);} /* Return the expire time of the specified key, or -1 if no expire * is associated with this key (i.e. the key is non volatile) */long long getExpire(redisDb *db, robj *key) { dictEntry *de;  /* No expire? return ASAP */ if (dictSize(db->expires) == 0 || (de = dictFind(db->expires,key->ptr)) == NULL) return -1;  /* The entry was found in the expire dict, this means it should also * be present in the main dict (safety check). */ redisAssertWithInfo(NULL,key,dictFind(db->dict,key->ptr) != NULL); return dictGetSignedIntegerVal(de);} /* Propagate expires into slaves and the AOF file. * When a key expires in the master, a DEL operation for this key is sent * to all the slaves and the AOF file if enabled. * * This way the key expiry is centralized in one place, and since both * AOF and the master->slave link guarantee operation ordering, everything * will be consistent even if we allow write operations against expiring * keys. */void propagateExpire(redisDb *db, robj *key) { robj *argv[2];  argv[0] = shared.del; argv[1] = key; incrRefCount(argv[0]); incrRefCount(argv[1]);  if (server.aof_state != REDIS_AOF_OFF) feedAppendOnlyFile(server.delCommand,db->id,argv,2); replicationFeedSlaves(server.slaves,db->id,argv,2);  decrRefCount(argv[0]); decrRefCount(argv[1]);} int expireIfNeeded(redisDb *db, robj *key) { mstime_t when = getExpire(db,key); mstime_t now;  if (when < 0) return 0; /* No expire for this key */ /* Don't expire anything while loading. It will be done later. */ if (server.loading) return 0; /* If we are in the context of a Lua script, we claim that time is * blocked to when the Lua script started. This way a key can expire * only the first time it is accessed and not in the middle of the * script execution, making propagation to slaves / AOF consistent. * See issue #1525 on Github for more information. */ now = server.lua_caller ? server.lua_time_start : mstime(); /* If we are running in the context of a slave, return ASAP: * the slave key expiration is controlled by the master that will * send us synthesized DEL operations for expired keys. * * Still we try to return the right information to the caller, * that is, 0 if we think the key should be still valid, 1 if * we think the key is expired at this time. */ if (server.masterhost != NULL) return now > when;  /* Return when this key has not expired */ if (now <= when) return 0; /* Delete the key */ server.stat_expiredkeys++; propagateExpire(db,key); notifyKeyspaceEvent(REDIS_NOTIFY_EXPIRED, "expired",key,db->id); return dbDelete(db,key);} /*----------------------------------------------------------------------------- * Expires Commands *----------------------------------------------------------------------------*/ /* This is the generic command implementation for EXPIRE, PEXPIRE, EXPIREAT * and PEXPIREAT. Because the commad second argument may be relative or absolute * the "basetime" argument is used to signal what the base time is (either 0 * for *AT variants of the command, or the current time for relative expires). * * unit is either UNIT_SECONDS or UNIT_MILLISECONDS, and is only used for * the argv[2] parameter. The basetime is always specified in milliseconds. */void expireGenericCommand(redisClient *c, long long basetime, int unit) { robj *key = c->argv[1], *param = c->argv[2]; long long when; /* unix time in milliseconds when the key will expire. */  if (getLongLongFromObjectOrReply(c, param, &when, NULL) != REDIS_OK) return;  if (unit == UNIT_SECONDS) when *= 1000; when += basetime;  /* No key, return zero. */ if (lookupKeyRead(c->db,key) == NULL) { addReply(c,shared.czero); return; }  /* EXPIRE with negative TTL, or EXPIREAT with a timestamp into the past * should never be executed as a DEL when load the AOF or in the context * of a slave instance. * * Instead we take the other branch of the IF statement setting an expire * (possibly in the past) and wait for an explicit DEL from the master. */ if (when <= mstime() && !server.loading && !server.masterhost) { robj *aux; redisAssertWithInfo(c,key,dbDelete(c->db,key)); server.dirty++;  /* Replicate/AOF this as an explicit DEL. */ aux = createStringObject("DEL",3); rewriteClientCommandVector(c,2,aux,key); decrRefCount(aux); signalModifiedKey(c->db,key); notifyKeyspaceEvent(REDIS_NOTIFY_GENERIC,"del",key,c->db->id); addReply(c, shared.cone); return; } else { setExpire(c->db,key,when); addReply(c,shared.cone); signalModifiedKey(c->db,key); notifyKeyspaceEvent(REDIS_NOTIFY_GENERIC,"expire",key,c->db->id); server.dirty++; return; }} void expireCommand(redisClient *c) { expireGenericCommand(c,mstime(),UNIT_SECONDS);} void expireatCommand(redisClient *c) { expireGenericCommand(c,0,UNIT_SECONDS);} void pexpireCommand(redisClient *c) { expireGenericCommand(c,mstime(),UNIT_MILLISECONDS);} void pexpireatCommand(redisClient *c) { expireGenericCommand(c,0,UNIT_MILLISECONDS);} void ttlGenericCommand(redisClient *c, int output_ms) { long long expire, ttl = -1;  /* If the key does not exist at all, return -2 */ if (lookupKeyRead(c->db,c->argv[1]) == NULL) { addReplyLongLong(c,-2); return; } /* The key exists. Return -1 if it has no expire, or the actual * TTL value otherwise. */ expire = getExpire(c->db,c->argv[1]); if (expire != -1) { ttl = expire-mstime(); if (ttl < 0) ttl = 0; } if (ttl == -1) { addReplyLongLong(c,-1); } else { addReplyLongLong(c,output_ms ? ttl : ((ttl+500)/1000)); } } void ttlCommand(redisClient *c) { ttlGenericCommand(c, 0); } void pttlCommand(redisClient *c) { ttlGenericCommand(c, 1); } void persistCommand(redisClient *c) { dictEntry *de; de = dictFind(c->db->dict,c->argv[1]->ptr); if (de == NULL) { addReply(c,shared.czero); } else { if (removeExpire(c->db,c->argv[1])) {  addReply(c,shared.cone);  server.dirty++; } else {  addReply(c,shared.czero); } }}

但僅是這樣是不夠的,因為可能存在一些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.conf 文件中關于 hz 選項的說明

也叫定時刪除,這里的“定期”指的是Redis定期觸發的清理策略,由位于src/redis.c的activeExpireCycle(void)函數來完成。

serverCron是由redis的事件框架驅動的定位任務,這個定時任務中會調用activeExpireCycle函數,針對每個db在限制的時間REDIS_EXPIRELOOKUPS_TIME_LIMIT內遲可能多的刪除過期key,之所以要限制時間是為了防止過長時間 的阻塞影響redis的正常運行。這種主動刪除策略彌補了被動刪除策略在內存上的不友好。

因此,Redis會周期性的隨機測試一批設置了過期時間的key并進行處理。測試到的已過期的key將被刪除。

典型的方式為,Redis每秒做10次如下的步驟:

  • 隨機測試100個設置了過期時間的key
  • 刪除所有發現的已過期的key
  • 若刪除的key超過25個則重復步驟1

這是一個基于概率的簡單算法,基本的假設是抽出的樣本能夠代表整個key空間,redis持續清理過期的數據直至將要過期的key的百分比降到了25%以下。這也意味著在任何給定的時刻已經過期但仍占據著內存空間的key的量最多為每秒的寫操作量除以4.

Redis-3.0.0中的默認值是10,代表每秒鐘調用10次后臺任務。

除了主動淘汰的頻率外,Redis對每次淘汰任務執行的最大時長也有一個限定,這樣保證了每次主動淘汰不會過多阻塞應用請求,以下是這個限定計算公式:

#define ACTIVE_EXPIRE_CYCLE_SLOW_TIME_PERC 25 /* CPU max % for keys collection */ ... 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時間,建議:

  • 盡量不要觸發maxmemory,最好在mem_used內存占用達到maxmemory的一定比例后,需要考慮調大hz以加快淘汰,或者進行集群擴容。
  • 如果能夠控制住內存,則可以不用修改maxmemory-samples配置;如果Redis本身就作為LRU cache服務(這種服務一般長時間處于maxmemory狀態,由Redis自動做LRU淘汰),可以適當調大maxmemory-samples。

以下是上文中提到的配置參數的說明

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

Replication link和AOF文件中的過期處理

為了獲得正確的行為而不至于導致一致性問題,當一個key過期時DEL操作將被記錄在AOF文件并傳遞到所有相關的slave。也即過期刪除操作統一在master實例中進行并向下傳遞,而不是各salve各自掌控。這樣一來便不會出現數據不一致的情形。當slave連接到master后并不能立即清理已過期的key(需要等待由master傳遞過來的DEL操作),slave仍需對數據集中的過期狀態進行管理維護以便于在slave被提升為master會能像master一樣獨立的進行過期處理。

總結

以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作能帶來一定的幫助,如果有疑問大家可以留言交流。

發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
主站蜘蛛池模板: 国产精品久久久久久久不卡 | 99国产精品国产免费观看 | 13一14毛片免费看 | 日本在线观看中文字幕 | 亚洲成人第一页 | 亚洲午夜1000理论片aa | 久久亚洲视频网 | xxxxhdvideosex| 国产成人高潮免费观看精品 | 国产精品www | 久久久久久艹 | 精品国产乱码久久久久久久 | 91网站永久免费看 | 看91| 毛片在线免费播放 | 成人在线视频播放 | 久久国产精品成人免费网站 | 视频一区二区三区在线播放 | 成人福利视频网站 | 国产一级小视频 | 亚洲国产色婷婷 | 中文字幕四区 | 久久成人激情视频 | 狠狠干夜夜草 | 亚洲第五色综合网 | 国产成人高潮免费观看精品 | 99国产精成人午夜视频一区二区 | 最新一级毛片 | 免费三级大片 | 最新中文字幕免费视频 | 欧美一页 | 国产乱淫a∨片免费观看 | 日本在线免费观看 | 一级做a爱片性色毛片 | 久综合色 | 羞羞草视频 | 欧美精品一区二区三区久久久 | 一本色道久久99精品综合蜜臀 | 免费看毛片网站 | 色综合久久久久久 | 国产成人77亚洲精品www |