欧美中文字幕在线,www.久久爱.com,欧美日韩精品免费观看视一区二区

主頁(yè) > 知識(shí)庫(kù) > Redis 2.8-4.0過(guò)期鍵優(yōu)化過(guò)程全紀(jì)錄

Redis 2.8-4.0過(guò)期鍵優(yōu)化過(guò)程全紀(jì)錄

前言

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

先從一個(gè)問(wèn)題來(lái)看，運(yùn)行環(huán)境如下：

Redis: 2.8.19
db0:keys=10000000,expires=10000000
主從結(jié)構(gòu)

從下圖中可以看到，在從節(jié)點(diǎn)get hello非空，在主節(jié)點(diǎn)get hello為空，之后從節(jié)點(diǎn)get hello為空，經(jīng)排查主從同步offset基本正常，但出現(xiàn)了主從不一致。

原因先不說(shuō)，本文來(lái)探討下Redis2.8-4.0版本迭代中，針對(duì)過(guò)期鍵的fix，看看能不能找到答案。

一、過(guò)期功能回顧

當(dāng)你執(zhí)行了一條setex命令后，Redis會(huì)向內(nèi)部的dict和expires哈希結(jié)構(gòu)中分別插入數(shù)據(jù):

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

例如：

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

二、Redis過(guò)期鍵的刪除策略：

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

1.惰性刪除策略：

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

下面是讀寫(xiě)key相關(guān)的入口：

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);
}

可以看到每次讀寫(xiě)key前，所有的Redis命令在執(zhí)行之前都會(huì)調(diào)用expireIfNeeded函數(shù)：

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) 主庫(kù)：過(guò)期則expireIfNeeded會(huì)刪除過(guò)期鍵，刪除成功返回1，否則返回0。

(2) 從庫(kù)：expireIfNeeded不會(huì)刪除key，而會(huì)返回一個(gè)邏輯刪除的結(jié)果，過(guò)期返回1，不過(guò)期返回0 。

但是從庫(kù)過(guò)期鍵刪除由主庫(kù)的synthesized DEL operations控制。

2.定時(shí)刪除策略：

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

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

(1)主庫(kù): 會(huì)定時(shí)刪除過(guò)期鍵。

(2)從庫(kù): 不執(zhí)行定期刪除。

綜上所述：

主庫(kù)：

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

(2) 定期執(zhí)行調(diào)用一次activeExpireCycle，每次隨機(jī)刪除部分鍵（定時(shí)刪除）。

從庫(kù)：

過(guò)期鍵刪除由主庫(kù)的synthesized DEL operations控制。

三、過(guò)期讀寫(xiě)問(wèn)題

Redis過(guò)期刪除策略帶來(lái)的問(wèn)題。我們只從用戶操作的角度來(lái)討論。

1、過(guò)期鍵讀操作

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

(1) Redis2.8主從不一致

2.8中的讀操作中都先調(diào)用lookupKeyRead函數(shù)：

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;
}

•對(duì)于主庫(kù)，執(zhí)行expireIfNeeded時(shí)，過(guò)期會(huì)刪除key。lookupKey返回 NULL。

•對(duì)于從庫(kù)，執(zhí)行expireIfNeeded時(shí)，過(guò)期不會(huì)刪除key。lookupKey返回value。

所以對(duì)于過(guò)期鍵的讀操作，主從返回就會(huì)存在不一致的情況，也就是開(kāi)篇提到的問(wèn)題。

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

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

3.2-rc1讀操作中同樣先調(diào)用了lookupKeyRead，實(shí)際上調(diào)用的是lookupKeyReadWithFlags函數(shù)：

robj *lookupKeyReadWithFlags(redisDb *db, robj *key) {
  robj *val;
  if (expireIfNeeded(db,key) == 1) { 
    if (server.masterhost == NULL) return NULL;
    if (server.current_client  //當(dāng)前客戶端存在
      server.current_client != server.master  //當(dāng)前客戶端不是master請(qǐng)求建立的（用戶請(qǐng)求的客戶端）
      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;
  }

可以看到，相對(duì)于2.8，增加了對(duì)expireIfNeeded返回結(jié)果的判斷：

•對(duì)于主庫(kù)，執(zhí)行expireIfNeeded時(shí)，過(guò)期會(huì)刪除key，返回1。masterhost為空返回NULL。

•對(duì)于從庫(kù)，執(zhí)行expireIfNeeded時(shí)，過(guò)期不會(huì)刪除key，返回1。滿足當(dāng)前客戶端不為 master且為讀命令時(shí)返回NULL。

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

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

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

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

2、過(guò)期鍵寫(xiě)操作

在具體說(shuō)這個(gè)問(wèn)題之前，我們先說(shuō)一下可寫(xiě)從庫(kù)的使用場(chǎng)景。

(1).主從分離場(chǎng)景中，利用從庫(kù)可寫(xiě)執(zhí)行耗時(shí)操作提升性能。

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

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 舉了一個(gè)更具體的例子：

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.

也就是說(shuō)在讀寫(xiě)分離的場(chǎng)景中，可以使用過(guò)期鍵的機(jī)制將從庫(kù)作為一個(gè)緩存，去緩存從庫(kù)上耗時(shí)操作的結(jié)果，提升整體性能。

(2). 遷移數(shù)據(jù)時(shí)，需要先將從庫(kù)設(shè)置為可寫(xiě)。

比如下列場(chǎng)景：線上Redis服務(wù)正常，但可能遇到一些硬件的情況，需要對(duì)該機(jī)器上的Redis主從集群遷移。遷數(shù)據(jù)的方式就是搭建一個(gè)新的主從集群，讓新主成為舊主的從。

進(jìn)行如下操作：

•(1）主（舊主）從（新主）同步，rdb傳輸完畢90s之后，設(shè)置從庫(kù)（新主）可寫(xiě)。

•(2）在主庫(kù)（舊主）完全沒(méi)有業(yè)務(wù)連接后，從庫(kù)（新主）執(zhí)行slaveof no one。

這種場(chǎng)景下，為了保證數(shù)據(jù)完全同步，并且盡量減少對(duì)業(yè)務(wù)的影響，就會(huì)先設(shè)置從庫(kù)可寫(xiě)。

接著我們來(lái)做一個(gè)測(cè)試：

3.2版本主庫(kù)執(zhí)行的操作，主庫(kù)的過(guò)期鍵正常過(guò)期。

3.2版本可寫(xiě)從庫(kù)執(zhí)行以下操作，從庫(kù)的過(guò)期鍵并不會(huì)過(guò)期。

4.0rc3版本可寫(xiě)從庫(kù)執(zhí)行以下操作，從庫(kù)的過(guò)期鍵卻能夠過(guò)期。

其實(shí)可寫(xiě)從庫(kù)過(guò)期鍵問(wèn)題包含兩個(gè)問(wèn)題：

•(1）從庫(kù)中的過(guò)期鍵由主庫(kù)同步過(guò)來(lái)的，過(guò)期操作由主庫(kù)執(zhí)行（未變更過(guò)）。

•(2）從庫(kù)中的過(guò)期鍵的設(shè)置是從庫(kù)上操作的。

redis4.0rc3之前，存在過(guò)期鍵泄露的問(wèn)題。當(dāng)expire直接在從庫(kù)上操作，這個(gè)key是不會(huì)過(guò)期的。作者也在https://redis.io/topics/replication 提到過(guò)：

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.

過(guò)期鍵泄露問(wèn)題在https://github.com/antirez/redis/commit/c65dfb436e9a5a28573ec9e763901b2684eadfc4中得到了解決。

四.總結(jié)

1、針對(duì)過(guò)期鍵讀操作

(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、針對(duì)過(guò)期鍵的寫(xiě)操作：

Redis2.8~4.0都只返回物理結(jié)果。

3、從庫(kù)中對(duì)key執(zhí)行expire操作，key不會(huì)過(guò)期。

Redis4.0 rc3解決從庫(kù)中設(shè)置的過(guò)期鍵不過(guò)期問(wèn)題 https://github.com/antirez/redis/commit/c65dfb436e9a5a28573ec9e763901b2684eadfc4

4、如果slave非讀寫(xiě)分離、上述遷移使用，基本本文問(wèn)題不會(huì)出現(xiàn)。還有就是Redis 4非常靠譜，后面也會(huì)有文章介紹相關(guān)內(nèi)容。（付磊）

總結(jié)

以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。

您可能感興趣的文章:

redis學(xué)習(xí)之RDB、AOF與復(fù)制時(shí)對(duì)過(guò)期鍵的處理教程
大家都應(yīng)該知道的Redis過(guò)期鍵與過(guò)期策略
redis鍵空間通知使用實(shí)現(xiàn)
Redis開(kāi)啟鍵空間通知實(shí)現(xiàn)超時(shí)通知的步驟詳解
使用redis實(shí)現(xiàn)延遲通知功能(Redis過(guò)期鍵通知)

標(biāo)簽：定州拉薩甘南泰州南寧伊春畢節(jié) 河源

巨人網(wǎng)絡(luò)通訊聲明：本文標(biāo)題《Redis 2.8-4.0過(guò)期鍵優(yōu)化過(guò)程全紀(jì)錄》，本文關(guān)鍵詞 Redis,2.8-4.0,過(guò)期,鍵,優(yōu)化,；如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問(wèn)題，煩請(qǐng)?zhí)峁┫嚓P(guān)信息告之我們，我們將及時(shí)溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò)，涉及言論、版權(quán)與本站無(wú)關(guān)。