記憶體快取系統memcached與redis實現的對比

程式碼灣發表於2017-12-18
記憶體快取Redis

memcached和redis，作為近些年最常用的快取伺服器，相信大家對它們再熟悉不過了。前兩年還在學校時，我曾經讀過它們的主要原始碼，如今寫篇筆記從個人角度簡單對比一下它們的實現方式，權當做複習，有理解錯誤之處，歡迎指正。

文中使用的架構類的圖片大多來自於網路，有部分圖與最新實現有出入，文中已經指出。

一. 綜述

讀一個軟體的原始碼，首先要弄懂軟體是用作幹什麼的，那memcached和redis是幹啥的？眾所周知，資料一般會放在資料庫中，但是查詢資料會相對比較慢，特別是使用者很多時，頻繁的查詢，需要耗費大量的時間。怎麼辦呢？資料放在哪裡查詢快？那肯定是記憶體中。memcached和redis就是將資料儲存在記憶體中，按照key-value的方式查詢，可以大幅度提高效率。所以一般它們都用做快取伺服器，快取常用的資料，需要查詢的時候，直接從它們那兒獲取，減少查詢資料庫的次數，提高查詢效率。

二. 服務方式

memcached和redis怎麼提供服務呢？它們是獨立的程式，需要的話，還可以讓他們變成daemon程式，所以我們的使用者程式要使用memcached和redis的服務的話，就需要程式間通訊了。考慮到使用者程式和memcached和redis不一定在同一臺機器上，所以還需要支援網路間通訊。因此，memcached和redis自己本身就是網路伺服器，使用者程式通過與他們通過網路來傳輸資料，顯然最簡單和最常用的就是使用tcp連線了。另外，memcached和redis都支援udp協議。而且當使用者程式和memcached和redis在同一機器時，還可以使用unix域套接字通訊。

三. 事件模型

下面開始講他們具體是怎麼實現的了。首先來看一下它們的事件模型。

自從epoll出來以後，幾乎所有的網路伺服器全都拋棄select和poll，換成了epoll。redis也一樣，只不多它還提供對select和poll的支援，可以自己配置使用哪一個，但是一般都是用epoll。另外針對BSD，還支援使用kqueue。而memcached是基於libevent的，不過libevent底層也是使用epoll的，所以可以認為它們都是使用epoll。epoll的特性這裡就不介紹了，網上介紹文章很多。

它們都使用epoll來做事件迴圈，不過redis是單執行緒的伺服器（redis也是多執行緒的，只不過除了主執行緒以外，其他執行緒沒有event loop，只是會進行一些後臺儲存工作），而memcached是多執行緒的。 redis的事件模型很簡單，只有一個event loop，是簡單的reactor實現。不過redis事件模型中有一個亮點，我們知道epoll是針對fd的，它返回的就緒事件也是隻有fd，redis裡面的fd就是伺服器與客戶端連線的socket的fd，但是處理的時候，需要根據這個fd找到具體的客戶端的資訊，怎麼找呢？通常的處理方式就是用紅黑樹將fd與客戶端資訊儲存起來，通過fd查詢，效率是lgn。不過redis比較特殊，redis的客戶端的數量上限可以設定，即可以知道同一時刻，redis所開啟的fd的上限，而我們知道，程式的fd在同一時刻是不會重複的（fd只有關閉後才能複用），所以redis使用一個陣列，將fd作為陣列的下標，陣列的元素就是客戶端的資訊，這樣，直接通過fd就能定位客戶端資訊，查詢效率是O(1)，還省去了複雜的紅黑樹的實現（我曾經用c寫一個網路伺服器，就因為要保持fd和connect對應關係，不想自己寫紅黑樹，然後用了STL裡面的set，導致專案變成了c++的，最後專案使用g++編譯，這事我不說誰知道？）。顯然這種方式只能針對connection數量上限已確定，並且不是太大的網路伺服器，像nginx這種http伺服器就不適用，nginx就是自己寫了紅黑樹。

而memcached是多執行緒的，使用master-worker的方式，主執行緒監聽埠，建立連線，然後順序分配給各個工作執行緒。每一個從執行緒都有一個event loop，它們服務不同的客戶端。master執行緒和worker執行緒之間使用管道通訊，每一個工作執行緒都會建立一個管道，然後儲存寫端和讀端，並且將讀端加入event loop，監聽可讀事件。同時，每個從執行緒都有一個就緒連線佇列，主執行緒連線連線後，將連線的item放入這個佇列，然後往該執行緒的管道的寫端寫入一個connect命令，這樣event loop中加入的管道讀端就會就緒，從執行緒讀取命令，解析命令發現是有連線，然後就會去自己的就緒佇列中獲取連線，並進行處理。多執行緒的優勢就是可以充分發揮多核的優勢，不過編寫程式麻煩一點，memcached裡面就有各種鎖和條件變數來進行執行緒同步。

四. 記憶體分配

memcached和redis的核心任務都是在記憶體中運算元據，記憶體管理自然是核心的內容。

首先看看他們的記憶體分配方式。memcached是有自己得記憶體池的，即預先分配一大塊記憶體，然後接下來分配記憶體就從記憶體池中分配，這樣可以減少記憶體分配的次數，提高效率，這也是大部分網路伺服器的實現方式，只不過各個記憶體池的管理方式根據具體情況而不同。而redis沒有自己得記憶體池，而是直接使用時分配，即什麼時候需要什麼時候分配，記憶體管理的事交給核心，自己只負責取和釋放（redis既是單執行緒，又沒有自己的記憶體池，是不是感覺實現的太簡單了？那是因為它的重點都放在資料庫模組了）。不過redis支援使用tcmalloc來替換glibc的malloc，前者是google的產品，比glibc的malloc快。

由於redis沒有自己的記憶體池，所以記憶體申請和釋放的管理就簡單很多，直接malloc和free即可，十分方便。而memcached是支援記憶體池的，所以記憶體申請是從記憶體池中獲取，而free也是還給記憶體池，所以需要很多額外的管理操作，實現起來麻煩很多，具體的會在後面memcached的slab機制講解中分析。

五. 資料庫實現

接下來看看他們的最核心內容，各自資料庫的實現。

1. memcached資料庫實現

memcached只支援key-value，即只能一個key對於一個value。它的資料在記憶體中也是這樣以key-value對的方式儲存，它使用slab機制。

首先看memcached是如何儲存資料的，即儲存key-value對。如下圖，每一個key-value對都儲存在一個item結構中，包含了相關的屬性和key和value的值。

圖0：記憶體快取系統memcached與redis實現的對比

item是儲存key-value對的，當item多的時候，怎麼查詢特定的item是個問題。所以memcached維護了一個hash表，它用於快速查詢item。hash表適用開鏈法（與redis一樣）解決鍵的衝突，每一個hash表的桶裡面儲存了一個連結串列，連結串列節點就是item的指標，如上圖中的h_next就是指桶裡面的連結串列的下一個節點。 hash表支援擴容（item的數量是桶的數量的1.5以上時擴容），有一個primary_hashtable，還有一個old_hashtable，其中正常適用primary_hashtable，但是擴容的時候，將old_hashtable = primary_hashtable，然後primary_hashtable設定為新申請的hash表（桶的數量乘以2），然後依次將old_hashtable 裡面的資料往新的hash表裡面移動，並用一個變數expand_bucket記錄以及移動了多少個桶，移動完成後，再free原來的old_hashtable 即可（redis也是有兩個hash表，也是移動，不過不是後臺執行緒完成，而是每次移動一個桶）。擴容的操作，專門有一個後臺擴容的執行緒來完成，需要擴容的時候，使用條件變數通知它，完成擴容後，它又考試阻塞等待擴容的條件變數。這樣在擴容的時候，查詢一個item可能會在primary_hashtable和old_hashtable的任意一箇中，需要根據比較它的桶的位置和expand_bucket的大小來比較確定它在哪個表裡。

item是從哪裡分配的呢？從slab中。如下圖，memcached有很多slabclass，它們管理slab，每一個slab其實是trunk的集合，真正的item是在trunk中分配的，一個trunk分配一個item。一個slab中的trunk的大小一樣，不同的slab，trunk的大小按比例遞增，需要新申請一個item的時候，根據它的大小來選擇trunk，規則是比它大的最小的那個trunk。這樣，不同大小的item就分配在不同的slab中，歸不同的slabclass管理。 這樣的缺點是會有部分記憶體浪費，因為一個trunk可能比item大，如圖2，分配100B的item的時候，選擇112的trunk，但是會有12B的浪費，這部分記憶體資源沒有使用。

圖1：記憶體快取系統memcached與redis實現的對比

圖2：記憶體快取系統memcached與redis實現的對比

圖3：記憶體快取系統memcached與redis實現的對比

如上圖，整個構造就是這樣，slabclass管理slab，一個slabclass有一個slab_list，可以管理多個slab，同一個slabclass中的slab的trunk大小都一樣。slabclass有一個指標slot，儲存了未分配的item已經被free掉的item（不是真的free記憶體，只是不用了而已），有item不用的時候，就放入slot的頭部，這樣每次需要在當前slab中分配item的時候，直接取slot取即可，不用管item是未分配過的還是被釋放掉的。

然後，每一個slabclass對應一個連結串列，有head陣列和tail陣列，它們分別儲存了連結串列的頭節點和尾節點。連結串列中的節點就是改slabclass所分配的item，新分配的放在頭部，連結串列越往後的item，表示它已經很久沒有被使用了。當slabclass的記憶體不足，需要刪除一些過期item的時候，就可以從連結串列的尾部開始刪除，沒錯，這個連結串列就是為了實現LRU。光靠它還不行，因為連結串列的查詢是O（n）的，所以定位item的時候，使用hash表，這已經有了，所有分配的item已經在hash表中了，所以，hash用於查詢item，然後連結串列有用儲存item的最近使用順序，這也是lru的標準實現方法。

每次需要新分配item的時候，找到slabclass對於的連結串列，從尾部往前找，看item是否已經過期，過期的話，直接就用這個過期的item當做新的item。沒有過期的，則需要從slab中分配trunk，如果slab用完了，則需要往slabclass中新增slab了。

memcached支援設定過期時間，即expire time，但是內部並不定期檢查資料是否過期，而是客戶程式使用該資料的時候，memcached會檢查expire time，如果過期，直接返回錯誤。這樣的優點是，不需要額外的cpu來進行expire time的檢查，缺點是有可能過期資料很久不被使用，則一直沒有被釋放，佔用記憶體。

memcached是多執行緒的，而且只維護了一個資料庫，所以可能有多個客戶程式操作同一個資料，這就有可能產生問題。比如，A已經把資料更改了，然後B也更改了改資料，那麼A的操作就被覆蓋了，而可能A不知道，A任務資料現在的狀態時他改完後的那個值，這樣就可能產生問題。為了解決這個問題，memcached使用了CAS協議，簡單說就是item儲存一個64位的unsigned int值，標記資料的版本，每更新一次（資料值有修改），版本號增加，然後每次對資料進行更改操作，需要比對客戶程式傳來的版本號和伺服器這邊item的版本號是否一致，一致則可進行更改操作，否則提示髒資料。

以上就是memcached如何實現一個key-value的資料庫的介紹。

2. redis資料庫實現

首先redis資料庫的功能強大一些，因為不像memcached只支援儲存字串，redis支援string， list， set，sorted set，hash table 5種資料結構。例如儲存一個人的資訊就可以使用hash table，用人的名字做key，然後name super， age 24， 通過key 和 name，就可以取到名字super，或者通過key和age，就可以取到年齡24。這樣，當只需要取得age的時候，不需要把人的整個資訊取回來，然後從裡面找age，直接獲取age即可，高效方便。

為了實現這些資料結構，redis定義了抽象的物件redis object，如下圖。每一個物件有型別，一共5種：字串，連結串列，集合，有序集合，雜湊表。 同時，為了提高效率，redis為每種型別準備了多種實現方式，根據特定的場景來選擇合適的實現方式，encoding就是表示物件的實現方式的。然後還有記錄了物件的lru，即上次被訪問的時間，同時在redis 伺服器中會記錄一個當前的時間（近似值，因為這個時間只是每隔一定時間，伺服器進行自動維護的時候才更新），它們兩個只差就可以計算出物件多久沒有被訪問了。 然後redis object中還有引用計數，這是為了共享物件，然後確定物件的刪除時間用的。最後使用一個void*指標來指向物件的真正內容。正式由於使用了抽象redis object，使得資料庫運算元據時方便很多，全部統一使用redis object物件即可，需要區分物件型別的時候，再根據type來判斷。而且正式由於採用了這種物件導向的方法，讓redis的程式碼看起來很像c++程式碼，其實全是用c寫的。

//#define REDIS_STRING 0	// 字串型別
//#define REDIS_LIST 1		// 連結串列型別
//#define REDIS_SET 2		// 集合型別(無序的)，可以求差集，並集等
//#define REDIS_ZSET 3		// 有序的集合型別
//#define REDIS_HASH 4		// 雜湊型別

//#define REDIS_ENCODING_RAW 0     /* Raw representation */ //raw  未加工
//#define REDIS_ENCODING_INT 1     /* Encoded as integer */
//#define REDIS_ENCODING_HT 2      /* Encoded as hash table */
//#define REDIS_ENCODING_ZIPMAP 3  /* Encoded as zipmap */
//#define REDIS_ENCODING_LINKEDLIST 4 /* Encoded as regular linked list */
//#define REDIS_ENCODING_ZIPLIST 5 /* Encoded as ziplist */
//#define REDIS_ENCODING_INTSET 6  /* Encoded as intset */
//#define REDIS_ENCODING_SKIPLIST 7  /* Encoded as skiplist */
//#define REDIS_ENCODING_EMBSTR 8  /* Embedded sds 
                                                                     string encoding */

typedef struct redisObject {
    unsigned type:4;			// 物件的型別，包括 /* Object types */
    unsigned encoding:4;		// 底部為了節省空間，一種type的資料，
                                                // 可   以採用不同的儲存方式
    unsigned lru:REDIS_LRU_BITS; /* lru time (relative to server.lruclock) */
    int refcount;         // 引用計數
    void *ptr;
} robj;```

說到底redis還是一個key-value的資料庫，不管它支援多少種資料結構，最終儲存的還是以key-value的方式，只不過value可以是連結串列，set，sorted set，hash table等。和memcached一樣，所有的key都是string，而set，sorted set，hash table等具體儲存的時候也用到了string。 而c沒有現成的string，所以redis的首要任務就是實現一個string，取名叫sds（simple dynamic string），如下的程式碼， 非常簡單的一個結構體，len儲存改string的記憶體總長度，free表示還有多少位元組沒有使用，而buf儲存具體的資料，顯然len-free就是目前字串的長度。

struct sdshdr {
int len;
int free;
char buf[];
};

字串解決了，所有的key都存成sds就行了，那麼key和value怎麼關聯呢？key-value的格式在指令碼語言中很好處理，直接使用字典即可，C沒有字典，怎麼辦呢？自己寫一個唄（redis十分熱衷於造輪子）。看下面的程式碼，privdata存額外資訊，用的很少，至少我們發現。 dictht是具體的雜湊表，一個dict對應兩張雜湊表，這是為了擴容（包括rehashidx也是為了擴容）。dictType儲存了雜湊表的屬性。redis還為dict實現了迭代器（所以說看起來像c++程式碼）。

雜湊表的具體實現是和mc類似的做法，也是使用開鏈法來解決衝突，不過裡面用到了一些小技巧。比如使用dictType儲存函式指標，可以動態配置桶裡面元素的操作方法。又比如dictht中儲存的sizemask取size（桶的數量）-1，用它與key做&操作來代替取餘運算，加快速度等等。總的來看，dict裡面有兩個雜湊表，每個雜湊表的桶裡面儲存dictEntry連結串列，dictEntry儲存具體的key和value。

前面說過，一個dict對於兩個dictht，是為了擴容（其實還有縮容）。正常的時候，dict只使用dictht[0]，當dict[0]中已有entry的數量與桶的數量達到一定的比例後，就會觸發擴容和縮容操作，我們統稱為rehash，這時，為dictht[1]申請rehash後的大小的記憶體，然後把dictht[0]裡的資料往dictht[1]裡面移動，並用rehashidx記錄當前已經移動萬的桶的數量，當所有桶都移完後，rehash完成，這時將dictht[1]變成dictht[0], 將原來的dictht[0]變成dictht[1]，並變為null即可。不同於memcached，這裡不用開一個後臺執行緒來做，而是就在event loop中完成，並且rehash不是一次性完成，而是分成多次，每次使用者操作dict之前，redis移動一個桶的資料，直到rehash完成。這樣就把移動分成多個小移動完成，把rehash的時間開銷均分到使用者每個操作上，這樣避免了使用者一個請求導致rehash的時候，需要等待很長時間，直到rehash完成才有返回的情況。不過在rehash期間，每個操作都變慢了點，而且使用者還不知道redis在他的請求中間新增了移動資料的操作，感覺redis太賤了

相關文章