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,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非常靠譜，後面也會有文章介紹相關內容。（付磊）
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對我們的支援。