歡迎大家前往騰訊雲+社群，獲取更多騰訊海量技術實踐乾貨哦~

本文由Super發表於雲+社群專欄

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的值。

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的浪費，這部分記憶體資源沒有使用。

如上圖，整個構造就是這樣，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太賤了 :-D

typedef struct dict {
    dictType *type;    // 雜湊表的相關屬性
    void *privdata;    // 額外資訊
    dictht ht[2];    // 兩張雜湊表，分主和副，用於擴容
    int rehashidx; /* rehashing not in progress if rehashidx == -1 */ // 記錄當前資料遷移的位置，在擴容的時候用的
    int iterators; /* number of iterators currently running */    // 目前存在的迭代器的數量
} dict;

typedef struct dictht {
    dictEntry **table;  // dictEntry是item，多個item組成hash桶裡面的連結串列，table則是多個連結串列頭指標組成的陣列的指標
    unsigned long size;    // 這個就是桶的數量
    // sizemask取size - 1, 然後一個數據來的時候，通過計算出的hashkey, 讓hashkey & sizemask來確定它要放的桶的位置
    // 當size取2^n的時候，sizemask就是1...111，這樣就和hashkey % size有一樣的效果，但是使用&會快很多。這就是原因
    unsigned long sizemask;  
    unsigned long used;        // 已經數值的dictEntry數量
} dictht;

typedef struct dictType {
    unsigned int (*hashFunction)(const void *key);     // hash的方法
    void *(*keyDup)(void *privdata, const void *key);    // key的複製方法
    void *(*valDup)(void *privdata, const void *obj);    // value的複製方法
    int (*keyCompare)(void *privdata, const void *key1, const void *key2);    // key之間的比較
    void (*keyDestructor)(void *privdata, void *key);    // key的析構
    void (*valDestructor)(void *privdata, void *obj);    // value的析構
} dictType;

typedef struct dictEntry {
    void *key;
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
    } v;
    struct dictEntry *next;
} dictEntry;

有了dict，資料庫就好實現了。所有資料讀儲存在dict中，key儲存成dictEntry中的key（string），用void* 指向一個redis object，它可以是5種類型中的任何一種。如下圖，結構構造是這樣，不過這個圖已經過時了，有一些與redis3.0不符合的地方。

5中type的物件，每一個都至少有兩種底層實現方式。string有3種：REDIS_ENCODING_RAW, REDIS_ENCIDING_INT, REDIS_ENCODING_EMBSTR， list有：普通雙向連結串列和壓縮連結串列，壓縮連結串列簡單的說，就是講陣列改造成連結串列，連續的空間，然後通過儲存字串的大小資訊來模擬連結串列，相對普通連結串列來說可以節省空間，不過有副作用，由於是連續的空間，所以改變記憶體大小的時候，需要重新分配，並且由於儲存了字串的位元組大小，所有有可能引起連續更新（具體實現請詳細看程式碼）。set有dict和intset（全是整數的時候使用它來儲存）， sorted set有：skiplist和ziplist， hashtable實現有壓縮列表和dict和ziplist。skiplist就是跳錶，它有接近於紅黑樹的效率，但是實現起來比紅黑樹簡單很多，所以被採用（奇怪，這裡又不造輪子了，難道因為這個輪子有點難？）。 hash table可以使用dict實現，則改dict中，每個dictentry中key儲存了key（這是雜湊表中的鍵值對的key），而value則儲存了value，它們都是string。 而set中的dict，每個dictentry中key儲存了set中具體的一個元素的值，value則為null。圖中的zset（有序集合）有誤，zset使用skiplist和ziplist實現，首先skiplist很好理解，就把它當做紅黑樹的替代品就行，和紅黑樹一樣，它也可以排序。怎麼用ziplist儲存zset呢？首先在zset中，每個set中的元素都有一個分值score，用它來排序。所以在ziplist中，按照分值大小，先存元素，再存它的score，再存下一個元素，然後score。這樣連續儲存，所以插入或者刪除的時候，都需要重新分配記憶體。所以當元素超過一定數量，或者某個元素的字元數超過一定數量，redis就會選擇使用skiplist來實現zset（如果當前使用的是ziplist，會將這個ziplist中的資料取出，存入一個新的skiplist，然後刪除改ziplist，這就是底層實現轉換，其餘型別的redis object也是可以轉換的）。 另外，ziplist如何實現hashtable呢？其實也很簡單，就是儲存一個key，儲存一個value，再儲存一個key，再儲存一個value。還是順序儲存，與zset實現類似，所以當元素超過一定數量，或者某個元素的字元數超過一定數量時，就會轉換成hashtable來實現。各種底層實現方式是可以轉換的，redis可以根據情況選擇最合適的實現方式，這也是這樣使用類似面向物件的實現方式的好處。

需要指出的是，使用skiplist來實現zset的時候，其實還用了一個dict，這個dict儲存一樣的鍵值對。為什麼呢？因為skiplist的查詢只是lgn的（可能變成n），而dict可以到O(1)， 所以使用一個dict來加速查詢，由於skiplist和dict可以指向同一個redis object，所以不會浪費太多記憶體。另外使用ziplist實現zset的時候，為什麼不用dict來加速查詢呢？因為ziplist支援的元素個數很少（個數多時就轉換成skiplist了），順序遍歷也很快，所以不用dict了。

這樣看來，上面的dict，dictType，dictHt，dictEntry，redis object都是很有考量的，它們配合實現了一個具有面向物件色彩的靈活、高效資料庫。不得不說，redis資料庫的設計還是很厲害的。

與memcached不同的是，redis的資料庫不止一個，預設就有16個，編號0-15。客戶可以選擇使用哪一個資料庫，預設使用0號資料庫。 不同的資料庫資料不共享，即在不同的資料庫中可以存在同樣的key，但是在同一個資料庫中，key必須是唯一的。

redis也支援expire time的設定，我們看上面的redis object，裡面沒有儲存expire的欄位，那redis怎麼記錄資料的expire time呢？ redis是為每個資料庫又增加了一個dict，這個dict叫expire dict，它裡面的dict entry裡面的key就是數對的key，而value全是資料為64位int的redis object，這個int就是expire time。這樣，判斷一個key是否過期的時候，去expire dict裡面找到它，取出expire time比對當前時間即可。為什麼這樣做呢？ 因為並不是所有的key都會設定過期時間，所以，對於不設定expire time的key來說，儲存一個expire time會浪費空間，而是用expire dict來單獨儲存的話，可以根據需要靈活使用記憶體（檢測到key過期時，會把它從expire dict中刪除）。

redis的expire 機制是怎樣的呢？ 與memcahed類似，redis也是惰性刪除，即要用到資料時，先檢查key是否過期，過期則刪除，然後返回錯誤。單純的靠惰性刪除，上面說過可能會導致記憶體浪費，所以redis也有補充方案，redis裡面有個定時執行的函式，叫servercron，它是維護伺服器的函式，在它裡面，會對過期資料進行刪除，注意不是全刪，而是在一定的時間內，對每個資料庫的expire dict裡面的資料隨機選取出來，如果過期，則刪除，否則再選，直到規定的時間到。即隨機選取過期的資料刪除，這個操作的時間分兩種，一種較長，一種較短，一般執行短時間的刪除，每隔一定的時間，執行一次長時間的刪除。這樣可以有效的緩解光采用惰性刪除而導致的記憶體浪費問題。

以上就是redis的資料的實現，與memcached不同，redis還支援資料持久化，這個下面介紹。

4.redis資料庫持久化

redis和memcached的最大不同，就是redis支援資料持久化，這也是很多人選擇使用redis而不是memcached的最大原因。 redis的持久化，分為兩種策略，使用者可以配置使用不同的策略。

4.1 RDB持久化 使用者執行save或者bgsave的時候，就會觸發RDB持久化操作。RDB持久化操作的核心思想就是把資料庫原封不動的儲存在檔案裡。

那如何儲存呢？如下圖， 首先儲存一個REDIS字串，起到驗證的作用，表示是RDB檔案，然後儲存redis的版本資訊，然後是具體的資料庫，然後儲存結束符EOF，最後用檢驗和。關鍵就是databases，看它的名字也知道，它儲存了多個數據庫，資料庫按照編號順序儲存，0號資料庫儲存完了，才輪到1，然後是2, 一直到最後一個數據庫。

每一個數據庫儲存方式如下，首先一個1位元組的常量SELECTDB，表示切換db了，然後下一個接上資料庫的編號，它的長度是可變的，然後接下來就是具體的key-value對的資料了。

int rdbSaveKeyValuePair(rio *rdb, robj *key, robj *val,
                        long long expiretime, long long now)
{
    /* Save the expire time */
    if (expiretime != -1) {
        /* If this key is already expired skip it */
        if (expiretime < now) return 0;
        if (rdbSaveType(rdb,REDIS_RDB_OPCODE_EXPIRETIME_MS) == -1) return -1;
        if (rdbSaveMillisecondTime(rdb,expiretime) == -1) return -1;
    }

    /* Save type, key, value */
    if (rdbSaveObjectType(rdb,val) == -1) return -1;
    if (rdbSaveStringObject(rdb,key) == -1) return -1;
    if (rdbSaveObject(rdb,val) == -1) return -1;
    return 1;
}

由上面的程式碼也可以看出，儲存的時候，先檢查expire time，如果已經過期，不存就行了，否則，則將expire time存下來，注意，及時是儲存expire time，也是先儲存它的型別為REDIS_RDB_OPCODE_EXPIRETIME_MS，然後再儲存具體過期時間。接下來儲存真正的key-value對，首先儲存value的型別，然後儲存key（它按照字串儲存），然後儲存value，如下圖。

在rdbsaveobject中，會根據val的不同型別，按照不同的方式儲存，不過從根本上來看，最終都是轉換成字串儲存，比如val是一個linklist，那麼先儲存整個list的位元組數，然後遍歷這個list，把資料取出來，依次按照string寫入檔案。對於hash table，也是先計算位元組數，然後依次取出hash table中的dictEntry，按照string的方式儲存它的key和value，然後儲存下一個dictEntry。 總之，RDB的儲存方式，對一個key-value對，會先儲存expire time（如果有的話），然後是value的型別，然後儲存key（字串方式），然後根據value的型別和底層實現方式，將value轉換成字串儲存。這裡面為了實現資料壓縮，以及能夠根據檔案恢復資料，redis使用了很多編碼的技巧，有些我也沒太看懂，不過關鍵還是要理解思想，不要在意這些細節。

儲存了RDB檔案，當redis再啟動的時候，就根據RDB檔案來恢復資料庫。由於以及在RDB檔案中儲存了資料庫的號碼，以及它包含的key-value對，以及每個key-value對中value的具體型別，實現方式，和資料，redis只要順序讀取檔案，然後恢復object即可。由於儲存了expire time，發現當前的時間已經比expire time大了，即資料已經超時了，則不恢復這個key-value對即可。

儲存RDB檔案是一個很巨大的工程，所以redis還提供後臺儲存的機制。即執行bgsave的時候，redis fork出一個子程序，讓子程序來執行儲存的工作，而父程序繼續提供redis正常的資料庫服務。由於子程序複製了父程序的地址空間，即子程序擁有父程序fork時的資料庫，子程序執行save的操作，把它從父程序那兒繼承來的資料庫寫入一個temp檔案即可。在子程序複製期間，redis會記錄資料庫的修改次數（dirty）。當子程序完成時，傳送給父程序SIGUSR1訊號，父程序捕捉到這個訊號，就知道子程序完成了複製，然後父程序將子程序儲存的temp檔案改名為真正的rdb檔案（即真正儲存成功了才改成目標檔案，這才是保險的做法）。然後記錄下這一次save的結束時間。

這裡有一個問題，在子程序儲存期間，父程序的資料庫已經被修改了，而父程序只是記錄了修改的次數（dirty），被沒有進行修正操作。似乎使得RDB儲存的不是實時的資料庫，有點不太高大上的樣子。 不過後面要介紹的AOF持久化，就解決了這個問題。

除了客戶執行sava或者bgsave命令，還可以配置RDB儲存條件。即在配置檔案中配置，在t時間內，資料庫被修改了dirty次，則進行後臺儲存。redis在serve cron的時候，會根據dirty數目和上次儲存的時間，來判斷是否符合條件，符合條件的話，就進行bg save，注意，任意時刻只能有一個子程序來進行後臺儲存，因為儲存是個很費io的操作，多個程序大量io效率不行，而且不好管理。

4.2 AOF持久化 首先想一個問題，儲存資料庫一定需要像RDB那樣把資料庫裡面的所有資料儲存下來麼？有沒有別的方法？

RDB儲存的只是最終的資料庫，它是一個結果。結果是怎麼來的？是通過使用者的各個命令建立起來的，所以可以不儲存結果，而只儲存建立這個結果的命令。 redis的AOF就是這個思想，它不同RDB儲存db的資料，它儲存的是一條一條建立資料庫的命令。

我們首先來看AOF檔案的格式，它裡面儲存的是一條一條的命令，首先儲存命令長度，然後儲存命令，具體的分隔符什麼的可以自己深入研究，這都不是重點，反正知道AOF檔案儲存的是redis客戶端執行的命令即可。

redis server中有一個sds aof_buf, 如果aof持久化開啟的話，每個修改資料庫的命令都會存入這個aof_buf（儲存的是aof檔案中命令格式的字串），然後event loop沒迴圈一次，在server cron中呼叫flushaofbuf，把aof_buf中的命令寫入aof檔案（其實是write，真正寫入的是核心緩衝區），再清空aof_buf，進入下一次loop。這樣所有的資料庫的變化，都可以通過aof檔案中的命令來還原，達到了儲存資料庫的效果。

需要注意的是，flushaofbuf中呼叫的write，它只是把資料寫入了核心緩衝區，真正寫入檔案時核心自己決定的，可能需要延後一段時間。 不過redis支援配置，可以配置每次寫入後sync，則在redis裡面呼叫sync，將核心中的資料寫入檔案，這不過這要耗費一次系統呼叫，耗費時間而已。還可以配置策略為1秒鐘sync一次，則redis會開啟一個後臺執行緒（所以說redis不是單執行緒，只是單eventloop而已），這個後臺執行緒會每一秒呼叫一次sync。這裡要問了，RDB的時候為什麼沒有考慮sync的事情呢？因為RDB是一次性儲存的，不像AOF這樣多次儲存，RDB的時候呼叫一次sync也沒什麼影響，而且使用bg save的時候，子程序會自己退出（exit），這時候exit函式內會沖刷緩衝區，自動就寫入了檔案中。

再來看，如果不想使用aof_buf儲存每次的修改命令，也可以使用aof持久化。redis提供aof_rewrite，即根據現有的資料庫生成命令，然後把命令寫入aof檔案中。很奇特吧？對，就是這麼厲害。進行aof_rewrite的時候，redis變數每個資料庫，然後根據key-value對中value的具體型別，生成不同的命令，比如是list，則它生成一個儲存list的命令，這個命令裡包含了儲存該list所需要的的資料，如果這個list資料過長，還會分成多條命令，先建立這個list，然後往list裡面新增元素，總之，就是根據資料反向生成儲存資料的命令。然後將這些命令儲存aof檔案，這樣不就和aof append達到同樣的效果了麼？

再來看，aof格式也支援後臺模式。執行aof_bgrewrite的時候，也是fork一個子程序，然後讓子程序進行aof_rewrite，把它複製的資料庫寫入一個臨時檔案，然後寫完後用新號通知父程序。父程序判斷子程序的退出資訊是否正確，然後將臨時檔案更名成最終的aof檔案。好了，問題來了。在子程序持久化期間，可能父程序的資料庫有更新，怎麼把這個更新通知子程序呢？難道要用程序間通訊麼？是不是有點麻煩呢？你猜redis怎麼做的？它根本不通知子程序。什麼，不通知？那更新怎麼辦？ 在子程序執行aof_bgrewrite期間，父程序會儲存所有對資料庫有更改的操作的命令（增，刪除，改等），把他們儲存在aof_rewrite_buf_blocks中，這是一個連結串列，每個block都可以儲存命令，存不下時，新申請block，然後放入連結串列後面即可，當子程序通知完成儲存後，父程序將aof_rewrite_buf_blocks的命令append 進aof檔案就可以了。多麼優美的設計，想一想自己當初還考慮用程序間通訊，別人直接用最簡單的方法就完美的解決了問題，有句話說得真對，越優秀的設計越趨於簡單，而複雜的東西往往都是靠不住的。

至於aof檔案的載入，也就是一條一條的執行aof檔案裡面的命令而已。不過考慮到這些命令就是客戶端傳送給redis的命令，所以redis乾脆生成了一個假的客戶端，它沒有和redis建立網路連線，而是直接執行命令即可。首先搞清楚，這裡的假的客戶端，並不是真正的客戶端，而是儲存在redis裡面的客戶端的資訊，裡面有寫和讀的緩衝區，它是存在於redis伺服器中的。所以，如下圖，直接讀入aof的命令，放入客戶端的讀緩衝區中，然後執行這個客戶端的命令即可。這樣就完成了aof檔案的載入。

// 建立偽客戶端
fakeClient = createFakeClient();

while(命令不為空) {
   // 獲取一條命令的引數資訊 argc， argv
   ...

    // 執行
    fakeClient->argc = argc;
    fakeClient->argv = argv;
    cmd->proc(fakeClient);
}

整個aof持久化的設計，個人認為相當精彩。其中有很多地方，值得膜拜。

5. redis的事務

redis另一個比memcached強大的地方，是它支援簡單的事務。事務簡單說就是把幾個命令合併，一次性執行全部命令。對於關係型資料庫來說，事務還有回滾機制，即事務命令要麼全部執行成功，只要有一條失敗就回滾，回到事務執行前的狀態。redis不支援回滾，它的事務只保證命令依次被執行，即使中間一條命令出錯也會繼續往下執行，所以說它只支援簡單的事務。

首先看redis事務的執行過程。首先執行multi命令，表示開始事務，然後輸入需要執行的命令，最後輸入exec執行事務。 redis伺服器收到multi命令後，會將對應的client的狀態設定為REDIS_MULTI，表示client處於事務階段，並在client的multiState結構體裡面保持事務的命令具體資訊（當然首先也會檢查命令是否能否識別，錯誤的命令不會儲存），即命令的個數和具體的各個命令，當收到exec命令後，redis會順序執行multiState裡面儲存的命令，然後儲存每個命令的返回值，當有命令發生錯誤的時候，redis不會停止事務，而是儲存錯誤資訊，然後繼續往下執行，當所有的命令都執行完後，將所有命令的返回值一起返回給客戶。redis為什麼不支援回滾呢？網上看到的解釋出現問題是由於客戶程式的問題，所以沒必要伺服器回滾，同時，不支援回滾，redis伺服器的執行高效很多。在我看來，redis的事務不是傳統關係型資料庫的事務，要求CIAD那麼非常嚴格，或者說redis的事務都不是事務，只是提供了一種方式，使得客戶端可以一次性執行多條命令而已，就把事務當做普通命令就行了，支援回滾也就沒必要了。

我們知道redis是單event loop的，在真正執行一個事物的時候（即redis收到exec命令後），事物的執行過程是不會被打斷的，所有命令都會在一個event loop中執行完。但是在使用者逐個輸入事務的命令的時候，這期間，可能已經有別的客戶修改了事務裡面用到的資料，這就可能產生問題。所以redis還提供了watch命令，使用者可以在輸入multi之前，執行watch命令，指定需要觀察的資料，這樣如果在exec之前，有其他的客戶端修改了這些被watch的資料，則exec的時候，執行到處理被修改的資料的命令的時候，會執行失敗，提示資料已經dirty。 這是如何是實現的呢？ 原來在每一個redisDb中還有一個dict watched_keys，watched_kesy中dictentry的key是被watch的資料庫的key，而value則是一個list，裡面儲存的是watch它的client。同時，每個client也有一個watched_keys，裡面儲存的是這個client當前watch的key。在執行watch的時候，redis在對應的資料庫的watched_keys中找到這個key（如果沒有，則新建一個dictentry），然後在它的客戶列表中加入這個client，同時，往這個client的watched_keys中加入這個key。當有客戶執行一個命令修改資料的時候，redis首先在watched_keys中找這個key，如果發現有它，證明有client在watch它，則遍歷所有watch它的client，將這些client設定為REDIS_DIRTY_CAS，表面有watch的key被dirty了。當客戶執行的事務的時候，首先會檢查是否被設定了REDIS_DIRTY_CAS，如果是，則表明資料dirty了，事務無法執行，會立即返回錯誤，只有client沒有被設定REDIS_DIRTY_CAS的時候才能夠執行事務。 需要指出的是，執行exec後，該client的所有watch的key都會被清除，同時db中該key的client列表也會清除該client，即執行exec後，該client不再watch任何key（即使exec沒有執行成功也是一樣）。所以說redis的事務是簡單的事務，算不上真正的事務。

以上就是redis的事務，感覺實現很簡單，實際用處也不是太大。

6. redis的釋出訂閱頻道

redis支援頻道，即加入一個頻道的使用者相當於加入了一個群，客戶往頻道里面發的資訊，頻道里的所有client都能收到。

實現也很簡單，也watch_keys實現差不多，redis server中儲存了一個pubsub_channels的dict，裡面的key是頻道的名稱（顯然要唯一了），value則是一個連結串列，儲存加入了該頻道的client。同時，每個client都有一個pubsub_channels，儲存了自己關注的頻道。當用使用者往頻道發訊息的時候，首先在server中的pubsub_channels找到改頻道，然後遍歷client，給他們發訊息。而訂閱，取消訂閱頻道不夠都是操作pubsub_channels而已，很好理解。

同時，redis還支援模式頻道。即通過正則匹配頻道，如有模式頻道p, 1, 則向普通頻道p1傳送訊息時，會匹配p，1，除了往普通頻道發訊息外，還會往p，1模式頻道中的client發訊息。注意，這裡是用釋出命令裡面的普通頻道來匹配已有的模式頻道，而不是在釋出命令裡制定模式頻道，然後匹配redis裡面儲存的頻道。實現方式也很簡單，在redis server裡面有個pubsub_patterns的list（這裡為什麼不用dict？因為pubsub_patterns的個數一般較少，不需要使用dict，簡單的list就好了），它裡面儲存的是pubsubPattern結構體，裡面是模式和client資訊，如下所示，一個模式，一個client，所以如果有多個clint監聽一個pubsub_patterns的話，在list面會有多個pubsubPattern，儲存client和pubsub_patterns的對應關係。 同時，在client裡面，也有一個pubsub_patterns list，不過裡面儲存的就是它監聽的pubsub_patterns的列表（就是sds），而不是pubsubPattern結構體。

typedef struct pubsubPattern {
    redisClient *client;    // 監聽的client
    robj *pattern;            // 模式
} pubsubPattern;

當用戶往一個頻道傳送訊息的時候，首先會在redis server中的pubsub_channels裡面查詢該頻道，然後往它的客戶列表傳送訊息。然後在redis server裡面的pubsub_patterns裡面查詢匹配的模式，然後往client裡面傳送訊息。 這裡並沒有去除重複的客戶，在pubsub_channels可能已經給某一個client發過message了，然後在pubsub_patterns中可能還會給使用者再發一次（甚至更多次）。 估計redis認為這是客戶程式自己的問題，所以不處理。

/* Publish a message */
int pubsubPublishMessage(robj *channel, robj *message) {
    int receivers = 0;
    dictEntry *de;
    listNode *ln;
    listIter li;

/* Send to clients listening for that channel */
    de = dictFind(server.pubsub_channels,channel);
    if (de) {
        list *list = dictGetVal(de);
        listNode *ln;
        listIter li;

        listRewind(list,&li);
        while ((ln = listNext(&li)) != NULL) {
            redisClient *c = ln->value;

            addReply(c,shared.mbulkhdr[3]);
            addReply(c,shared.messagebulk);
            addReplyBulk(c,channel);
            addReplyBulk(c,message);
            receivers++;
        }
    }
 /* Send to clients listening to matching channels */
    if (listLength(server.pubsub_patterns)) {
        listRewind(server.pubsub_patterns,&li);
        channel = getDecodedObject(channel);
        while ((ln = listNext(&li)) != NULL) {
            pubsubPattern *pat = ln->value;

            if (stringmatchlen((char*)pat->pattern->ptr,
                                sdslen(pat->pattern->ptr),
                                (char*)channel->ptr,
                                sdslen(channel->ptr),0)) {
                addReply(pat->client,shared.mbulkhdr[4]);
                addReply(pat->client,shared.pmessagebulk);
                addReplyBulk(pat->client,pat->pattern);
                addReplyBulk(pat->client,channel);
                addReplyBulk(pat->client,message);
                receivers++;
            }
        }
        decrRefCount(channel);
    }
    return receivers;
}

六. 總結

總的來看，redis比memcached的功能多很多，實現也更復雜。 不過memcached更專注於儲存key-value資料（這已經能滿足大多數使用場景了），而redis提供更豐富的資料結構及其他的一些功能。不能說redis比memcached好，不過從原始碼閱讀的角度來看，redis的價值或許更大一點。 另外，redis3.0裡面支援了叢集功能，這部分的程式碼還沒有研究，後續再跟進。

此文已由作者授權騰訊雲+社群釋出，更多原文請點選

搜尋關注公眾號「雲加社群」，第一時間獲取技術乾貨，關注後回覆1024 送你一份技術課程大禮包！

海量技術實踐經驗，盡在雲加社群！