《懶 Redis 是更好的 Redis》要點：
本文介紹了懶 Redis 是更好的 Redis，希望對您有用。如果有疑問，可以聯系我們。

大家都知道 Redis 是單線程的.對 Redis 內行 的人會告訴你,Redis 其實也不完全是單線程的,因為還有一些線程在處理特定的慢的磁盤操作.到目前為止,這些線程里的操作都集中在 I/O 上,以至于這些線程用到的庫被稱為 bio.c,也便是后臺 I/O(Background I/O).

不過之前我提交了一個 issue,承諾給 Redis 新增一個很多人(包含我自己)都想要的特性,被稱為延遲釋放(Lazy free).可以參考這個 issue：https://github.com/antirez/redis/issues/1748.

這個 issue 的主要描述了,Redis 的 DEL 操作通常是阻塞的,所以如果你發送了“DEL mykey”命令,而你的 key 包括了5千萬的對象,那么服務器就會阻塞幾秒鐘,這段時間不能提供其他服務.以前,這被看作是 Redis 設計上的副作用,是可以接受的,只是在特定場景下是受限制的.DEL不是唯一會阻塞的命令,不過比較特別,因為我們通常會說：Redis 在使用 O(1) 和 O(log_N) 命令的時候是非?？斓?你也可以使用 O(N)的命令,不過我們沒有為這些命令做優化,性能上可能會有問題.

這貌似合理,不外就算是用快的命令創建的對象,在刪除的時候也會讓Redis阻塞住.

第一次嘗試

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

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

適配是困難的

你知道這里最困難的部分是哪里嗎?這次我們是在增量式的做一件很特其余事情：釋放內存.如果內存的釋放是增量式的,服務器的內容增長將會非?？?最后為了得到更少的延時,會消耗調無限的內存.這很糟,想象一下,有下面的操作：

WHILE 1????SADD myset element1 element2 … many many many elements? ? DEL mysetEND

如果慢慢的在后臺去刪除 myset,同時 SADD 調用又在賡續的添加大量的元素,內存使用量將會一直增長.

好在經過一段測驗考試之后,我找到一種可以工作的很好的方式.定時器函數里使用了兩個想法來適應內存的壓力：

1. 檢測內存趨勢：增加還是減少?以決定釋放的力度.
2. 同時適配定時器的頻率,避免在只有很少必要釋放的時候去浪費 CPU,不用頻繁的去中斷事件循環.當確實必要的時候,定時器也可以達到大約 300Hz 的頻率.

這里有一小段代碼,不過這個想法現在已經不再實現了：

/* 計算內存趨勢,只要是上次和這次內存都在增加,就傾向于認為內存趨勢是增加的 */if (prev_mem < mem) mem_trend = 1;mem_trend *= 0.9; /* Make it slowly forget. */int mem_is_raising = mem_trend > .1;/* 釋放一些元素 */size_t workdone = lazyfreeStep(LAZYFREE_STEP_SLOW);/* 根據現有狀態調整定時器頻率 */if (workdone) {    if (timer_period == 1000) timer_period = 20;    if (mem_is_raising && timer_period > 3)        timer_period--; /* 提升調用頻率 */else if (!mem_is_raising && timer_period < 20)    timer_period++; /* 降低調用頻率 */} else {    timer_period = 1000;    /* 1 HZ */}

還有,現在也可以在其他線程實現針對聚合數據類型的特定的慢操作,可以讓某些 key 被“阻塞”,但是所有其他的客戶端不會被阻塞.這個可以用很類似現在的阻塞操作的方式去完成(參考 blocking.c),只是增加一個哈希表保存那些正在處理的 key 和對應的客戶端.于是一個客戶端哀求類似 SMEMBERS 這樣的命令,可能只是僅僅阻塞住這一個 key,然后會創建輸出緩存處理數據,之后在釋放這個 key.只有那些嘗試訪問相同的 key 的客戶端,才會在這個 key 被阻塞的時候被阻塞住.這是一個小技巧,工作的也很好.不過郁悶的是我們還是不得不在單線程里執行.要做好需要有很多的邏輯,而且當延遲釋放(lazy free)周期很繁忙的時候,每秒能完成的操作會降到平時的65%左右.

如果是在另一個線程去釋放工具,那就簡單多了：如果有一個線程只做釋放操作的話,釋放總是要比在數據集里添加數據來的要快.

當然,主線程和延遲釋放線程直接對內存分配器的使用肯定會有競爭,不外 Redis 在內存分配上只用到一小部分時間,更多的時間用在 I/O、命令分發、緩存失敗等等.

不過,要實現線程化的延遲釋放有一個大問題,那就是 Redis 自身.內部實現完全是追求對象的共享,最終都是些引用計數.干嘛不盡可能的共享呢?這樣可以節省內存和時間.例如：SUNIONSTORE 命令最后得到的是目標集合的共享對象.類似的,客戶端的輸出緩存包括了作為返回結果發送給 socket 的對象的列表,于是在類似 SMEMBERS 這樣的命令調用之后,集合的所有成員都有可能最終在輸出緩存里被共享.看上去對象共享是那么有效、漂亮、精彩,還特別酷.

但是,嘿,還需要再多說一句的是,如果在 SUNIONSTORE 命令之后重新加載了數據庫,對象都取消了共享,內存也會突然回復到最初的狀態.這可不太妙.接下來我們發送哀求應答給客戶端,會怎么樣?當對象比較小時,我們實際上是把它們拼接成線性的緩存,要不然進行多次 write 調用效率是不高的!(友情提示,writev() 對此并無幫助).于是我們大部分情況下是已經復制了數據.對于編程來說,沒有用的東西卻存在,通常意味著是有問題的.

事實上,拜訪一個包含聚合類型數據的key,需要經過下面這些遍歷過程：

key -> value_obj -> hash table -> robj -> sds_string

如果去掉整個 tobj 布局體,把聚合類型轉換成 SDS 字符串類型的哈希表(或者跳轉表)會怎么樣?(SDS 是 Redis 內部使用的字符串類型).

這樣做有個問題,假設有個命令：SADD myset myvalue,舉個例子來說,我們做不到通過 client->argv[2] 來引用某個用來實現集合的哈希表的元素.我們不得不很多次的把值復制出來,即使數據已經在客戶端命令解析后創建的參數 vector 里,也沒方法去復用.Redis 的性能受控于緩存失效,我們也許可以用稍微間接一些的方法來彌補一下.

于是我在這個 lazyfree 的分支上開始了一項工作,并且在 Twitter 上聊了一下,但是沒有頒布上下文的細節,結果所有的人都覺得我像是絕望或者瘋狂了(甚至有人喊道 lazyfree 到底是什么玩意).那么,我到底做了什么呢?

1. 把客戶端的輸出緩存由 robj 結構體改成動態字符串.在創建 reply 的時候總是復制值的內容.
2. 把所有的 Redis 數據類型轉換成 SDS 字符串,而不是使用共享對象結構.聽上去很簡單?實際上這花費了數周的時間,涉及到大約800行高風險的代碼修改.不過現在全都測試通過了.
3. 把 lazyfree 重寫成線程化的.

結果是 Redis 現在在內存使用上更加高效,因為在數據結構的實現上不再使用 robj 結構體(不過由于某些代碼還涉及到大量的共享,所以 robj 依然存在,例如在命令分發和復制部分).線程化的延遲釋放工作的很好,比增量的方式更能減少內存的使用,雖然增量方式在實現上與線程化的方式相似,而且也沒那么糟糕.現在,你可以刪除一個巨大的 key,性能損失可以忽略不計,這非常有用.不過,最有趣的事情是,在我測過的一些操作上,Redis 現在都要更快一些.消除間接引用(Less indirection)最后勝出,即使在不相關的一些測試上也更快一些,還是因為客戶端的輸出緩存現在更加簡單和高效.

最后,我把增量式的延遲釋放實現從分支里刪除,只保存了線程化的實現.

關于 API 的一點備注

不過 API 又怎么樣了呢?DEL 命令仍然是阻塞的,默認還跟以前一樣,因為在 Redis 中 DEL 命令就意味著釋放內存,我并不打算改變這一點.所以現在你可以用新的命令 UNLINK,這個命令更清晰的注解了數據的狀態.

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

我們也實現了 FLUSHALL/FLUSHDB 的非阻塞版本,不過沒有新增的 API,而是增加了一個 LAZY 選項,說明是否變動命令的行為.

不只是延遲釋放

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

所有這些需求引起了更激烈的內部變化,但這里的底線我們已很少顧忌.我們可以補償對象復制時間來減少高速緩存的缺失,以更小的內存占用聚合數據類型,所以我們現在可按照線程化的 Redis 來進行無共享化設計,這一設計,可以很容易超越我們的單線程.在過去,一個線程化的 Redis 看起來總像是一個壞主意,因為為了實現并發訪問數據結構和對象其必定是一組互斥鎖,但幸運的是還有別的選擇獲得這兩個環境的優勢.如果我們想要,我們依然可以選擇快速操作服務,就像我們過去在主線程所做的那樣.這包含在復雜的代價之上,獲取執行智能(performance-wise).

計劃表

我在內部增加了很多器械,明天就上線看上去是不現實的.我的計劃是先讓3.2版(已經是 unstable 狀態)成為候選版本(RC)狀態,然后把我們的分支合并到進入 unstable 的3.4版本.

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

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

起源：開源中國 原文：http://antirez.com/news/93作者： antirez

維易PHP培訓學院每天發布《懶 Redis 是更好的 Redis》等實戰技能，PHP、MYSQL、LINUX、APP、JS,CSS全面培養人才。

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/9260.html