Redis 2.8-4.0過期鍵優化過程全紀錄

前言

之前 白馨(陌陌-技術保障部存儲工程師 )在Redis技術交流群里，總結了一下Redis從2.8~4.0關于過期鍵相關的fix記錄，非常有幫助，但有些東西未盡詳細，本文將進行詳細說明。

先從一個問題來看，運行環境如下：

Redis: 2.8.19
db0:keys=10000000,expires=10000000
主從結構

從下圖中可以看到，在從節點get hello非空，在主節點get hello為空，之后從節點get hello為空，經排查主從同步offset基本正常，但出現了主從不一致。

原因先不說，本文來探討下Redis2.8-4.0版本迭代中，針對過期鍵的fix，看看能不能找到答案。

一、過期功能回顧

當你執行了一條setex命令后，Redis會向內部的dict和expires哈希結構中分別插入數據:

dict------dict[key]:value
expires---expires[key]:timeout

例如：

127.0.0.1:6379> setex hello 120 world
OK
127.0.0.1:6379> info
# 該數據庫中設置為過期鍵并且未被刪除的總量（如果曾設置為過期鍵且刪除則不計入）
db0:keys=1,expires=1,avg_ttl=41989
# 歷史上每一次刪除過期鍵就做一次加操作,記錄刪除過期鍵的總數。
expired_keys:0

二、Redis過期鍵的刪除策略：

當鍵值過期后，Redis是如何處理呢？綜合考慮Redis的單線程特性，有兩種策略：惰性刪除和定時刪除。

1.惰性刪除策略：

在每次執行key相關的命令時，都會先從expires中查找key是否過期，下面是3.0.7的源碼(db.c)：

下面是讀寫key相關的入口：

robj *lookupKeyRead(redisDb *db, robj *key) {
 robj *val;

 expireIfNeeded(db,key);
 val = lookupKey(db,key);
 ......
 return val;
}

robj *lookupKeyWrite(redisDb *db, robj *key) {
 expireIfNeeded(db,key);
 return lookupKey(db,key);
}

可以看到每次讀寫key前，所有的Redis命令在執行之前都會調用expireIfNeeded函數：

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 */
 now = server.lua_caller ? server.lua_time_start : mstime();
 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(NOTIFY_EXPIRED,
  "expired",key,db->id);
 return dbDelete(db,key);
}

從代碼可以看出，主從邏輯略有不同：

(1) 主庫：過期則expireIfNeeded會刪除過期鍵，刪除成功返回1，否則返回0。

(2) 從庫：expireIfNeeded不會刪除key，而會返回一個邏輯刪除的結果，過期返回1，不過期返回0 。

但是從庫過期鍵刪除由主庫的synthesized DEL operations控制。

2.定時刪除策略：

單單靠惰性刪除，肯定不能刪除所有的過期key，考慮到Redis的單線程特性，Redis使用了定期刪除策略，采用策略是從一定數量的數據庫的過期庫中取出一定數量的隨機鍵進行檢查，不為空則刪除。不保證實時刪除。有興趣的同學可以看看activeExpireCycle中具體實現，還是挺有意思的，下圖是個示意圖

if (server->masterhost == NULL) activeExpireCycle();

(1)主庫: 會定時刪除過期鍵。

(2)從庫: 不執行定期刪除。

綜上所述： 

主庫：

(1) 在執行所有操作之前調用expireIfNeeded惰性刪除。

(2) 定期執行調用一次activeExpireCycle，每次隨機刪除部分鍵（定時刪除）。

從庫：

過期鍵刪除由主庫的synthesized DEL operations控制。

三、過期讀寫問題

Redis過期刪除策略帶來的問題。我們只從用戶操作的角度來討論。

1、過期鍵讀操作

下面是Redis 2.8~4.0過期鍵讀操作的fix記錄

(1) Redis2.8主從不一致

2.8中的讀操作中都先調用lookupKeyRead函數：

robj *lookupKeyRead(redisDb *db, robs *key) {
  robj *val;
  expireIfNeeded(db,key);
  val = lookupKey(db,key);
  if (val == NULL)
    server.stat_keyspace_misses++;
  else
    server.stat_keyspace_hits++;
  return val;
}

•對于主庫，執行expireIfNeeded時，過期會刪除key。lookupKey返回 NULL。

•對于從庫，執行expireIfNeeded時，過期不會刪除key。lookupKey返回value。

所以對于過期鍵的讀操作，主從返回就會存在不一致的情況，也就是開篇提到的問題。

(2) Redis 3.2主從除exists之外都一致

https://github.com/antirez/redis/commit/06e76bc3e22dd72a30a8a614d367246b03ff1312

3.2-rc1讀操作中同樣先調用了lookupKeyRead，實際上調用的是lookupKeyReadWithFlags函數：

robj *lookupKeyReadWithFlags(redisDb *db, robj *key) {
  robj *val;
  if (expireIfNeeded(db,key) == 1) { 
    if (server.masterhost == NULL) return NULL;
    if (server.current_client && //當前客戶端存在
      server.current_client != server.master && //當前客戶端不是master請求建立的（用戶請求的客戶端）
      server.current_client->cmd &&
      server.current_client->cmd->flags & REDIS_CMD_READONLY) { //讀命令
        return NULL;
       }
  val = lookupKey(db,key,flags);
  if (val == NULL)
    server.stat_keyspace_misses++;
  else
    server.stat_keyspace_hits++;
  return val;
  }

可以看到，相對于2.8，增加了對expireIfNeeded返回結果的判斷：

•對于主庫，執行expireIfNeeded時，過期會刪除key，返回1。masterhost為空返回NULL。

•對于從庫，執行expireIfNeeded時，過期不會刪除key，返回1。滿足當前客戶端不為 master且為讀命令時返回NULL。

除非程序異常。正常情況下對于過期鍵的讀操作，主從返回一致。

(2) Redis 4.0.11解決exists不一致的情況

https://github.com/antirez/redis/commit/32a7a2c88a8b8cca8119b849eee7976b8ada8936

3.2并未解決exists這個命令的問題，雖然它也是個讀操作。之后的4.0.11中問題才得以解決.

2、過期鍵寫操作

在具體說這個問題之前，我們先說一下可寫從庫的使用場景。

(1).主從分離場景中，利用從庫可寫執行耗時操作提升性能。

作者在https://redis.io/topics/replication 中提到過：

For example computing slow Set or Sorted set operations and storing them into local keys is an use case for writable slaves that was observed multiple times.

在 https://github.com/antirez/redis/commit/c65dfb436e9a5a28573ec9e763901b2684eadfc4 舉了一個更具體的例子：

For instance imagine having slaves replicating certain Sets keys from the master. When accessing the data on the slave, we want to peform intersections between
such Sets values. However we don't want to intersect each time: to cache the intersection for some time often is a good idea.

也就是說在讀寫分離的場景中，可以使用過期鍵的機制將從庫作為一個緩存，去緩存從庫上耗時操作的結果，提升整體性能。

(2). 遷移數據時，需要先將從庫設置為可寫。

比如下列場景：線上Redis服務正常，但可能遇到一些硬件的情況，需要對該機器上的Redis主從集群遷移。遷數據的方式就是搭建一個新的主從集群，讓新主成為舊主的從。

進行如下操作：

•(1）主（舊主）從（新主）同步，rdb傳輸完畢90s之后，設置從庫（新主）可寫。

•(2）在主庫（舊主）完全沒有業務連接后，從庫（新主）執行slaveof no one。

這種場景下，為了保證數據完全同步，并且盡量減少對業務的影響，就會先設置從庫可寫。

接著我們來做一個測試：

3.2版本主庫執行的操作，主庫的過期鍵正常過期。

3.2版本可寫從庫執行以下操作，從庫的過期鍵并不會過期。

4.0rc3版本可寫從庫執行以下操作，從庫的過期鍵卻能夠過期。

其實可寫從庫過期鍵問題包含兩個問題：

•(1）從庫中的過期鍵由主庫同步過來的，過期操作由主庫執行（未變更過）。

•(2）從庫中的過期鍵的設置是從庫上操作的。

redis4.0rc3之前，存在過期鍵泄露的問題。當expire直接在從庫上操作，這個key是不會過期的。作者也在https://redis.io/topics/replication 提到過：

However note that writable slaves before version 4.0 were incapable of expiring keys with a time to live set. This means that if you use EXPIRE or other commands that set a maximum TTL for a key, the key will leak, and while you may no longer see it while accessing it with read commands, you will see it in the count of keys and it will still use memory. So in general mixing writable slaves (previous version 4.0) and keys with TTL is going to create issues.

過期鍵泄露問題在https://github.com/antirez/redis/commit/c65dfb436e9a5a28573ec9e763901b2684eadfc4中得到了解決。

四.總結

1、針對過期鍵讀操作

(1) Redis2.8主從不一致 

(2) Redis3.2-rc1主從除exists之外都一致： https://github.com/antirez/redis/commit/06e76bc3e22dd72a30a8a614d367246b03ff1312

(3) Redis4.0.11主從一致：

https://github.com/antirez/redis/commit/32a7a2c88a8b8cca8119b849eee7976b8ada8936

2、針對過期鍵的寫操作：

Redis2.8~4.0都只返回物理結果。

3、從庫中對key執行expire操作，key不會過期。

Redis4.0 rc3解決從庫中設置的過期鍵不過期問題 https://github.com/antirez/redis/commit/c65dfb436e9a5a28573ec9e763901b2684eadfc4

4、如果slave非讀寫分離、上述遷移使用，基本本文問題不會出現。還有就是Redis 4非常靠譜，后面也會有文章介紹相關內容。（付磊）

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對億速云的支持。