主頁 > 知識庫 > 為啥懶 Redis 是更好的 Redis

為啥懶 Redis 是更好的 Redis

熱門標簽:太原營銷外呼系統(tǒng) 地圖標注費用 玄武湖地圖標注 竹間科技AI電銷機器人 百度商家地圖標注怎么做 西藏教育智能外呼系統(tǒng)價格 小紅書怎么地圖標注店 最簡單的百度地圖標注 地圖標注如何即時生效

英文原文:Lazy Redis is better Redis

前言

大家都知道 Redis 是單線程的。真正的內(nèi)行會告訴你,實際上 Redis 并不是完全單線程,因為在執(zhí)行磁盤上的特定慢操作時會有多線程。目前為止多線程操作絕大部分集中在 I/O 上以至于在不同線程執(zhí)行異步任務(wù)的小型庫被稱為 bio.c: 也就是 Background I/O。

然而前陣子我提交了一個問題,在問題里我承諾提供一個很多人(包括我自己)都想要的功能,叫做“免費懶加載”。原始的問題在這

問題的根本在于,Redis 的 DEL 操作通常是阻塞的。因此如果你發(fā)送 Redis “DEL mykey” 命令,碰巧你的 key 有 5000萬個對象,那么服務(wù)器將會阻塞幾秒鐘,在此期間服務(wù)器不會處理其他請求。歷史上這被當做 Redis 設(shè)計的副作用而被接受,但是在特定的用例下這是一個局限。DEL 不是唯一的阻塞式命令,卻是特殊的一個命令,因為我們認為:Redis 非常快,只要你用復(fù)雜度為 O(1) 和 O(log_N) 的命令。你可以自由使用 O(N) 的命令,但是要知道這不是我們優(yōu)化的用例,你需要做好延遲的準備。

這聽起來很合理,但是同時即便用快速操作創(chuàng)建的對象也需要被刪除。在這種情況下,Redis 會阻塞。

第一次嘗試

對于單線程服務(wù)器,為了讓操作不阻塞,最簡單的方式就是用增量的方式一點點來,而不是一下子把整個世界都搞定。例如,如果要釋放一個百萬級的對象,可以每一個毫秒釋放1000個元素,而不是在一個 for() 循環(huán)里一次性全做完。CPU 的耗時是差不多的,也許會稍微多一些,因為邏輯更多一些,但是從用戶來看延時更少一些。當然也許實際上并沒有每毫秒刪除1000個元素,這只是個例子。重點是如何避免秒級的阻塞。在 Redis 內(nèi)部做了很多事情:最顯然易見的是 LRU 淘汰機制和 key 的過期,還有其他方面的,例如增量式的對 hash 表進行重排。

剛開始我們是這樣嘗試的:創(chuàng)建一個新的定時器函數(shù),在里面實現(xiàn)淘汰機制。對象只是被添加到一個鏈表里,每次定時器調(diào)用的時候,會逐步的、增量式的去釋放。這需要一些小技巧,例如,那些用哈希表實現(xiàn)的對象,會使用 Redis 的 SCAN 命令里相同的機制去增量式的釋放:在字典里設(shè)置一個游標來遍歷和釋放元素。通過這種方式,在每次定時器調(diào)用的時候我們不需要釋放整個哈希表。在重新進入定時器函數(shù)時,游標可以告訴我們上次釋放到哪里了。

適配是困難的

你知道這里最困難的部分是哪里嗎?這次我們是在增量式的做一件很特別的事情:釋放內(nèi)存。如果內(nèi)存的釋放是增量式的,服務(wù)器的內(nèi)容增長將會非???,最后為了得到更少的延時,會消耗調(diào)無限的內(nèi)存。這很糟,想象一下,有下面的操作:

WHILE 1
    SADD myset element1 element2 … many many many elements
    DEL myset
END

如果慢慢的在后臺去刪除myset,同時SADD調(diào)用又在不斷的添加大量的元素,內(nèi)存使用量將會一直增長。

好在經(jīng)過一段嘗試之后,我找到一種可以工作的很好的方式。定時器函數(shù)里使用了兩個想法來適應(yīng)內(nèi)存的壓力:

1.檢測內(nèi)存趨勢:增加還是減少?以決定釋放的力度。

2.同時適配定時器的頻率,避免在只有很少需要釋放的時候去浪費CPU,不用頻繁的去中斷事件循環(huán)。當確實需要的時候,定時器也可以達到大約300HZ的頻率。
這里有一小段代碼,不過這個想法現(xiàn)在已經(jīng)不再實現(xiàn)了:

/計算內(nèi)存趨勢,只要是上次和這次內(nèi)存都在增加,就傾向于認為內(nèi)存趨勢
 是增加的 */

if (prev_mem lt; mem) mem_trend = 1;
   
mem_trend *= 0.9; /* 逐漸衰減 */
   
int mem_is_raising = mem_trend gt; .1;

   
/* 釋放一些元素 */
   
size_t workdone = lazyfreeStep(LAZYFREE_STEP_SLOW);

   
/* 根據(jù)現(xiàn)有狀態(tài)調(diào)整定時器頻率 */
   
if (workdone) {
       
    if (timer_period == 1000) timer_period = 20;

    if (mem_is_raising timer_period gt; 3)
           
        timer_period--; /* Raise call frequency. */
       
    else if (!mem_is_raising timer_period lt; 20)

        timer_period++; /* Lower call frequency. */
   
} else {
       
  timer_period = 1000;    /* 1 HZ */
   
}

這是一個小技巧,工作的也很好。不過郁悶的是我們還是不得不在單線程里執(zhí)行。要做好需要有很多的邏輯,而且當延遲釋放(lazy free)周期很繁忙的時候,每秒能完成的操作會降到平時的65%左右。
如果是在另一個線程去釋放對象,那就簡單多了:如果有一個線程只做釋放操作的話,釋放總是要比在數(shù)據(jù)集里添加數(shù)據(jù)來的要快。

當然,主線程和延遲釋放線程直接對內(nèi)存分配器的使用肯定會有競爭,不過 Redis 在內(nèi)存分配上只用到一小部分時間,更多的時間用在I/O、命令分發(fā)、緩存失敗等等。
不過,要實現(xiàn)線程化的延遲釋放有一個大問題,那就是 Redis 自身。內(nèi)部實現(xiàn)完全是追求對象的共享,最終都是些引用計數(shù)。干嘛不盡可能的共享呢?這樣可以節(jié)省內(nèi)存和時間。例如:SUNIONSTORE 命令最后得到的是目標集合的共享對象。類似的,客戶端的輸出緩存包含了作為返回結(jié)果發(fā)送給socket的對象的列表,于是在類似 SMEMBERS 這樣的命令調(diào)用之后,集合的所有成員都有可能最終在輸出緩存里被共享。看上去對象共享是那么有效、漂亮、精彩,還特別酷。

但是,嘿,還需要再多說一句的是,如果在 SUNIONSTORE 命令之后重新加載了數(shù)據(jù)庫,對象都取消了共享,內(nèi)存也會突然回復(fù)到最初的狀態(tài)。這可不太妙。接下來我們發(fā)送應(yīng)答請求給客戶端,會怎么樣?當對象比較小時,我們實際上是把它們拼接成線性的緩存,要不然進行多次 write() 調(diào)用效率是不高的?。ㄓ亚樘崾?,writev() 并沒有幫助)。于是我們大部分情況下是已經(jīng)復(fù)制了數(shù)據(jù)。對于編程來說,沒有用的東西卻存在,通常意味著是有問題的。
事實上,訪問一個包含聚合類型數(shù)據(jù)的key,需要經(jīng)過下面這些遍歷過程:

key -gt; value_obj -gt; hash table -gt; robj -gt; sds_string

如果去掉整個 tobj 結(jié)構(gòu)體,把聚合類型轉(zhuǎn)換成 SDS 字符串類型的哈希表(或者跳表)會怎么樣?(SDS是Redis內(nèi)部使用的字符串類型)。

這樣做有個問題,假設(shè)有個命令:SADD myset myvalue,舉個例子來說,我們做不到通過client->argv[2] 來引用用來實現(xiàn)集合的哈希表的某個元素。我們不得不很多次的把值復(fù)制出來,即使數(shù)據(jù)已經(jīng)在客戶端命令解析后創(chuàng)建的參數(shù) vector 里,也沒辦法去復(fù)用。Redis的性能受控于緩存失效,我們也許可以用稍微間接一些的辦法來彌補一下。
于是我在這個 lazyfree 的分支上開始了一項工作,并且在 Twitter 上聊了一下,但是沒有公布上下文的細節(jié),結(jié)果所有的人都覺得我像是絕望或者瘋狂了(甚至有人喊道 lazyfree 到底是什么玩意)。那么,我到底做了什么呢?

把客戶端的輸出緩存由 robj 結(jié)構(gòu)體改成動態(tài)字符串。在創(chuàng)建 reply 的時候總是復(fù)制值的內(nèi)容。
把所有的 Redis 數(shù)據(jù)類型轉(zhuǎn)換成 SDS 字符串,而不是使用共享對象結(jié)構(gòu)。聽上去很簡單?實際上這花費了數(shù)周的時間,涉及到大約800行高風(fēng)險的代碼修改。不過現(xiàn)在全都測試通過了。
把 lazyfree 重寫成線程化的。
結(jié)果是 Redis 現(xiàn)在在內(nèi)存使用上更加高效,因為在數(shù)據(jù)結(jié)構(gòu)的實現(xiàn)上不再使用 robj 結(jié)構(gòu)體(不過由于某些代碼還涉及到大量的共享,所以 robj 依然存在,例如在命令分發(fā)和復(fù)制部分)。線程化的延遲釋放工作的很好,比增量的方式更能減少內(nèi)存的使用,雖然增量方式在實現(xiàn)上與線程化的方式相似,并且也沒那么糟糕?,F(xiàn)在,你可以刪除一個巨大的 key,性能損失可以忽略不計,這非常有用。不過,最有趣的事情是,在我測過的一些操作上,Redis 現(xiàn)在都要更快一些。消除間接引用(Less indirection)最后勝出,即使在不相關(guān)的一些測試上也更快一些,還是因為客戶端的輸出緩存現(xiàn)在更加簡單和高效。

最后我把增量式的延遲釋放實現(xiàn)從分支里刪除,只保留了線程化的實現(xiàn)。

關(guān)于 API 的一點備注

不過 API 又怎么樣了呢?DEL 命令仍然是阻塞的,默認還跟以前一樣,因為在 Redis 中 DEL 命令就意味著釋放內(nèi)存,我并不打算改變這一點。所以現(xiàn)在你可以用新的命令 UNLINK,這個命令更清晰的表明了數(shù)據(jù)的狀態(tài)。

UNLINK 是一個聰明的命令:它會計算釋放對象的開銷,如果開銷很小,就會直接按 DEL 做的那樣立即釋放對象,否則對象會被放到后臺隊列里進行處理。除此之外,這兩個命令在語義上是相同的。

我們也實現(xiàn)了 FLUSHALL/FLUSHDB 的非阻塞版本,不過沒有新增的 API,而是增加了一個 LAZY 選項,說明是否更改命令的行為。

不只是延遲釋放

現(xiàn)在聚合數(shù)據(jù)類型的值都不再共享了,客戶端的輸出緩存也不再包含共享對象了,這一點有很多文章可做。例如,現(xiàn)在終于可以在 Redis 里實現(xiàn)線程化的 I/O,從而不同的客戶端可以由不同的線程去服務(wù)。也就是說,只有訪問數(shù)據(jù)庫才需要全局的鎖,客戶端的讀寫系統(tǒng)調(diào)用,甚至是客戶端發(fā)送的命令的解析,都可以在線程中去處理。這跟 memcached 的設(shè)計理念類似,我比較期待能夠被實現(xiàn)和測試。

還有,現(xiàn)在也可以在其他線程實現(xiàn)針對聚合數(shù)據(jù)類型的特定的慢操作,可以讓某些 key 被“阻塞”,但是所有其他的客戶端不會被阻塞。這個可以用很類似現(xiàn)在的阻塞操作的方式去完成(參考blocking.c),只是增加一個哈希表保存那些正在處理的 key 和對應(yīng)的客戶端。于是一個客戶端請求類似 SMEMBERS 這樣的命令,可能只是僅僅阻塞住這一個 key,然后會創(chuàng)建輸出緩存處理數(shù)據(jù),之后在釋放這個 key。只有那些嘗試訪問相同的 key 的客戶端,才會在這個 key 被阻塞的時候被阻塞住。
所有這些需求起了更激烈的內(nèi)部變化,但這里的底線我們已很少顧忌。我們可以補償對象復(fù)制時間來減少高速緩存的缺失,以更小的內(nèi)存占用聚合數(shù)據(jù)類型,所以我們現(xiàn)在可依照線程化的 Redis 來進行無共享化設(shè)計,這一設(shè)計,可以很容易超越我們的單線程。在過去,一個線程化的 Redis 看起來總像是一個壞主意,因為為了實現(xiàn)并發(fā)訪問數(shù)據(jù)結(jié)構(gòu)和對象其必定是一組互斥鎖,但幸運的是還有別的選擇獲得這兩個環(huán)境的優(yōu)勢。如果我們想要,我們依然可以選擇快速操作服務(wù),就像我們過去在主線程所做的那樣。這包含在復(fù)雜的代價之上,獲取執(zhí)行智能(performance-wise)。

計劃表

我在內(nèi)部增加了很多東西,明天就上線看上去是不現(xiàn)實的。我的計劃是先讓3.2版(已經(jīng)是unstable狀態(tài))成為候選版本(RC)狀態(tài),然后把我們的分支合并到進入unstable的3.4版本。

不過在合并之前,需要對速度做細致的回歸測試,這有不少工作要做。

如果你現(xiàn)在就想嘗試的話,可以從Github上下載lazyfree分支。不過要注意的是,當前我并不是很頻繁的更新這個分支,所以有些地方可能會不能工作。

您可能感興趣的文章:
  • 超強、超詳細Redis數(shù)據(jù)庫入門教程
  • redis常用命令、常見錯誤、配置技巧等分享
  • Redis操作命令總結(jié)
  • Redis中5種數(shù)據(jù)結(jié)構(gòu)的使用場景介紹
  • 30個php操作redis常用方法代碼例子
  • 64位Windows下安裝Redis教程
  • Linux下Redis的安裝和部署

標簽:廣東 澳門 唐山 贛州 香港 景德鎮(zhèn) 林芝 揚州

巨人網(wǎng)絡(luò)通訊聲明:本文標題《為啥懶 Redis 是更好的 Redis》,本文關(guān)鍵詞  為啥,懶,Redis,是,更,好的,;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 下面列出與本文章《為啥懶 Redis 是更好的 Redis》相關(guān)的同類信息!
  • 本頁收集關(guān)于為啥懶 Redis 是更好的 Redis的相關(guān)信息資訊供網(wǎng)民參考!
  • 推薦文章