Redis的記憶體和實現機制

JonPan發表於2020-06-12
Redis記憶體

1. Reids記憶體的劃分

  1. 資料 記憶體統計在used_memory中
  2. 程式本身執行需要記憶體 Redis主程式本身執行需要的記憶體佔用，程式碼、常量池等
  3. 緩衝記憶體，客戶端緩衝區、複製積壓緩衝區、AOF緩衝區。有jemalloc分配記憶體，會統計在used_memory中
  4. 記憶體碎片 Redis在分配、回收實體記憶體過程中產生的。記憶體碎片不會統計在used_memory中。如果Redis伺服器中的記憶體碎片已經很大，可以通過安全重啟的方式減小記憶體碎片：因為重啟之後，Redis重新從備份檔案中讀取資料，在記憶體中進行重排，為每個資料重新選擇合適的記憶體單元，減小記憶體碎片。

2. Redis的資料儲存的細節

涉及到記憶體分配器jemalloc， 簡單動態字串（SDS），5種值型別物件的內部編碼，redisObject,

img

  1. DictEntry: Redis 是key-value資料庫，因此對每個鍵值對都會有一個dictEntry，裡面儲存了指向Key和Value的指標；next指向下一個dictEntry，與本Key-Value無關
  2. Key: 並不是以字串儲存，而是儲存在SDS結構中
  3. RedisObject: 5種值物件不是直接以對應的型別儲存的，而是被封裝為redisObject來儲存
  4. jemalloc: 無論是DictEntry物件，還是redisObject, SDS物件，都需要記憶體分配器

2.1 Jemalloc

redis 在編譯時便會指定記憶體分配器， 記憶體分配器可以是libc、jemalloc、tcmalloc

jemalloc作為Redis的預設記憶體分配器，在減小記憶體碎片方面做的相對比較好。jemalloc在64位系統中，將記憶體空間劃分為小、大、巨大三個範圍；每個範圍內又劃分了許多小的記憶體塊單位；當Redis儲存資料時，會選擇大小最合適的記憶體塊進行儲存。

img

2.2 RedisObject

redis物件的型別，內部編碼，記憶體回收，共享物件等功能都需要RedisObject的支援

typedef struct redisObject{
    unsigned type: 4;
    unsigned encoding: 4;
    unsigned lru: REDIS_LRU_BITS; /*lru time*/
    int refcount;
    void *ptr;
} robj;

  • type 欄位 佔4bit 目前有5中型別， REDIS_STRING, REDIS_LIST, REDIS_HASH, REDIS_SET, REDIS_ZSET。 當執行type命令時，便是通過讀取redisObject物件的type欄位獲取物件型別

  • encoding 佔4bit （表示物件的內部編碼），對於redis支援的每種型別，都有至少兩種內部編碼。通過object encoding命令，可以檢視物件採用的編碼方式

    • 對於字串，有int, embstr, raw 三種編碼。
    • 對於列表， 有壓縮列表和雙端列表兩種編碼方式，如果列表中元素較少，redis傾向於使用壓縮列表進行儲存，因為壓縮列表記憶體佔用少，而且比雙端連結串列可以更快載入；當列表物件元素較多時，壓縮列表就會轉化為更適合儲存大量元素的雙端連結串列。

  • lru 不同版本佔用記憶體大小不一樣，4.0版本佔用24bit,2.6版本佔用22bit

    • 記錄的是物件最後一次被命令程式訪問的時間，通過對比lru時間和當前時間，可以計算某個物件的空轉時間，object idletime命令可以顯示該空轉時間 秒級別，改命令並不會改變物件的lru值，lru值除了通過object idletime命令列印之外，還與Redis的記憶體回收有關係：如果Redis開啟了maxmemory選項，且記憶體回收演算法選擇的是volatile-lru或allkeys—lru，那麼當Redis記憶體佔用超過maxmemory指定的值時，Redis會優先選擇空轉時間最長的物件進行釋放。

  • refcount 共享物件 記錄物件的引用計數，協助記憶體回收，引用計數可以通過 object refcount命令檢視

    • ​ 共享物件的具體實現
    • Redis共享物件目前只支援整數值的物件。實際上是對記憶體和CPU時間的衡量。共享物件雖然會降低記憶體消耗，但是判斷兩個物件是否相等時需要消耗時間的。，對於整數值，判斷操作複雜度為O(1)；對於普通字串，判斷複雜度為O(n)；而對於雜湊、列表、集合和有序集合，判斷的複雜度為O(n^2)。
    • 雖然共享物件只能是整數值的字串物件，但是5種型別都可能使用共享物件（如雜湊、列表等的元素可以使用）。reids伺服器在初始化時，會建立10000個字串物件，值分別是0-9999的整數值。10000這個數字可以通過調整引數REDIS_SHARED_INTEGERS（4.0中是OBJ_SHARED_INTEGERS）的值進行改變

  • ptr 指標指向具體的資料 如 set hello world ptr指向包含字串world的SDS

  • RedisObject物件大小16位元組 4bit+4bit+24bit+4Byte+8Byte=16Byte

3. Redis內部資料結

3.1 SDS 簡單動態字串

結構

img
img

struct sdshdr {
	int len;  // 記錄buf陣列中已使用位元組的數量 等於SDS所儲存字串的長度
    int free;  // 記錄buf陣列中未使用的位元組數量
    char buf[];
};

  1. SDS結構 佔據的空間：free+len+buf(表示字串結尾的空字串)， 其中buf=free+len+1. 則總長度為4+4+free+len+1=free+len+9

  2. 與C字串的比較

    在C字串的基礎上加入了free和len欄位，優勢

    • 獲取字串長度： SDS O(1), C字串是O(n)
    • 緩衝區溢位：使用C字串的API時，如果字串長度增加（如strcat操作）而忘記重新分配記憶體，很容易造成緩衝區的溢位；而SDS由於記錄了長度，相應的API在可能造成緩衝區溢位時會自動重新分配記憶體，杜絕了緩衝區溢位。
    • 修改字串記憶體的重分配：對於C字串，如果要修改字串，必須要重新分配記憶體（先釋放再申請），因為如果沒有重新分配，字串長度增大時會造成記憶體溢位，字串長度減小時會造成記憶體洩漏。對於SDS, 由於記錄了len和free，因此解除了字串長度和空間陣列長度之間的關聯，可以在此基礎上進行優化：空間預分配(分配記憶體時比實際需要的多)使得字串長度增大時重新分配記憶體的概率減小。惰性空間釋放策略 惰性空間釋放用於優化 SDS 的字串縮短操作： 當 SDS 的 API 需要縮短 SDS 儲存的字串時， 程式並不立即使用記憶體重分配來回收縮短後多出來的位元組， 而是使用 free 屬性將這些位元組的數量記錄起來， 並等待將來使用。
    • 二進位制安全 C 字串中的字元必須符合某種編碼（比如 ASCII）， 並且除了字串的末尾之外， 字串裡面不能包含空字元， 否則最先被程式讀入的空字元將被誤認為是字串結尾 —— 這些限制使得 C 字串只能儲存文字資料， 而不能儲存像圖片、音訊、視訊、壓縮檔案這樣的二進位制資料。
      SDS 的 API 都是二進位制安全的（binary-safe）： 所有 SDS API 都會以處理二進位制的方式來處理 SDS 存放在 buf 陣列裡的資料， 程式不會對其中的資料做任何限制、過濾、或者假設 —— 資料在寫入時是什麼樣的， 它被讀取時就是什麼樣。

    總結：

    • Redis 的字串表示為 sds ，而不是 C 字串（以 \0 結尾的 char*）。

    • 對比 C 字串，sds 有以下特性：
      – 可以高效地執行長度計算（strlen）；
      – 可以高效地執行追加操作（append）；
      – 二進位制安全；

    • sds 會為追加 操作進行優化：加快追加操作的速度，並降低記憶體分配的次數，代價是多佔用了一些記憶體，而且這些記憶體不會被主動釋放。

3.3 字典

在Redis中的應用：

  1. 實現資料庫鍵空間(key space) Redis 是一個鍵值對資料庫，資料庫中的鍵值對就由典儲存：每個資料庫都有一個與之相對應的字典，這個字典被稱之為鍵空間（key space。
  2. 用作Hash型別鍵的其中一種底層實現

Redis 的 Hash 型別鍵使用以下兩種資料結構作為底層實現：

  1. 字典；
  2. 壓縮列表

3.3.1 字典的底層實現

實現字典的方法有很多種:

  • 最簡單的就是使用連結串列和陣列，方式只適用於元素個數不多的情況
  • 兼顧高效和簡單性，使用雜湊表
  • 追求更穩定的效能特徵，並且希望高效的實現排序操作，可以是用更為複雜的平衡樹

Reids選擇了高效且實現簡單的雜湊表作為字典的底層實現。

/* dict.h/dict
* 字典
*
* 每個字典使用兩個雜湊表，用於實現漸進式 rehash
*/

typedef struct dict {
    dictType *type;  // 特定於型別的處理函式
    void *privdata;  // 型別處理函式的私有資料
    dictht ht[2];   // 2個雜湊表
    
    int rehashidx;  // 記錄rehash 進度的標誌, 值為-1  表示rehash未進行
    
    int iterators;   // 當前正在運作的安全迭代器數量
} dict;

注： dict型別使用了兩個指標分別指向兩個雜湊表

其中，0號雜湊表（ht[0]）是字典主要使用的雜湊表，而 1號雜湊表（ht[1]）則只有對0號雜湊表進行rehash時才使用。

3.3.2 雜湊表的實現

/*雜湊表*/
typedef struct dictht {
    dictEntry **table;   // 雜湊表節點指標陣列（俗稱桶， bucket）
    unsigned long size;  //指標陣列的大小
    unsigned long sizemask;   //指標陣列的長度掩碼
    unsigned long used;   // 雜湊表現有的節點數量
}dictht;

/*雜湊表節點*/
typedef struct dictEntry {
    void *key;
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
    } v;
    
    // 連結後繼系節點
    struct dictEntry *next;
} dictEntry;

next 屬性指向另一個dictEntry結構, 多個dictEntry 可以通過next指標串連成連結串列dictht使用鏈地址法來處理鍵碰撞；當多個不同鍵擁有相同的雜湊值時，雜湊表用一個連結串列將這些鍵連線起來。

3.3.3 雜湊碰撞

在雜湊表實現中，當兩個不同的鍵擁有相同的雜湊值時，我們稱這兩個鍵發生碰撞（collision），而雜湊表實現必須想辦法對碰撞進行處理。字典雜湊表所使用的碰撞解決方法被稱之為鏈地址法：這種方法使用連結串列將多個雜湊值相同的節點串連在一起，從而解決衝突問題。

假設現在有一個帶有三個節點的雜湊表：

snipaste20200530_135250.png

對於一個新的鍵值對 key4 和 value4 ，如果 key4 的雜湊值和 key1 的雜湊值相同，那麼它們將在雜湊表的 0 號索引上發生碰撞。

3.2.4 新增新鍵值對時觸發rehash操作？

對於使用鏈地址法來解決碰撞問題的雜湊表 dictht 來說，雜湊表的效能依賴於它的大小（size屬性）和它所儲存的節點的數量（used 屬性）之間的比率：比率最好在1：1。

4. 跳躍表

跳躍表是一種隨機化資料結果，查詢、新增、刪除操作都可以在對數期望時間下完成

跳躍表目前在Redis的唯一作用就是作為有序集型別的底層資料結構之一

Redis對跳躍表進行了修改包括：

  • score值可重複
  • 對比一個元素需要同時檢查它的score和member
  • 每個節點帶有高度為1層的後退指標，用於從表尾方向向表頭方向迭代

Redis 為什麼用跳錶而不用平衡樹？

4.1 skiplist與平衡樹、雜湊表的比較

  • skiplist和各種平衡樹（如AVL、紅黑樹等）的元素是有序排列的，而雜湊表不是有序的。因此，在雜湊表上只能做單個key的查詢，不適宜做範圍查詢。所謂範圍查詢，指的是查詢那些大小在指定的兩個值之間的所有節點。
  • 在做範圍查詢的時候，平衡樹比skiplist操作要複雜。在平衡樹上，我們找到指定範圍的小值之後，還需要以中序遍歷的順序繼續尋找其它不超過大值的節點。如果不對平衡樹進行一定的改造，這裡的中序遍歷並不容易實現。而在skiplist上進行範圍查詢就非常簡單，只需要在找到小值之後，對第1層連結串列進行若干步的遍歷就可以實現。
  • 平衡樹的插入和刪除操作可能引發子樹的調整，邏輯複雜，而skiplist的插入和刪除只需要修改相鄰節點的指標，操作簡單又快速。
  • 從記憶體佔用上來說，skiplist比平衡樹更靈活一些。一般來說，平衡樹每個節點包含2個指標（分別指向左右子樹），而skiplist每個節點包含的指標數目平均為1/(1-p)，具體取決於引數p的大小。如果像Redis裡的實現一樣，取p=1/4，那麼平均每個節點包含1.33個指標，比平衡樹更有優勢。
  • 查詢單個key，skiplist和平衡樹的時間複雜度都為O(log n)，大體相當；而雜湊表在保持較低的雜湊值衝突概率的前提下，查詢時間複雜度接近O(1)，效能更高一些。所以我們平常使用的各種Map或dictionary結構，大都是基於雜湊表實現的。
  • 從演算法實現難度上來比較，skiplist比平衡樹要簡單得多。

Redis的物件型別和內部編碼

1. 字串

1.1 內部編碼

  • int 8個位元組的長整型。字串值是整型時，這個值使用long整型表示
  • embstr <=39位元組的字串。embstr與raw都使用redisObject和sds儲存資料，區別在於，embstr的使用只分配一次記憶體空間（因此redisObject和sds是連續的），而raw需要分配兩次記憶體空間（分別為redisObject和sds分配空間）。因此與raw相比，embstr的好處在於建立時少分配一次空間，刪除時少釋放一次空間，以及物件的所有資料連在一起，尋找方便。而embstr的壞處也很明顯，如果字串的長度增加需要重新分配記憶體時，整個redisObject和sds都需要重新分配空間，因此redis中的embstr實現為只讀。
  • raw: 大於39個位元組的字串

1.2 編碼轉換

新建立的字串預設使用 REDIS_ENCODING_RAW 編碼，在將字串作為鍵或者值儲存進資料庫時，程式會嘗試將字串轉為 REDIS_ENCODING_INT 編碼, 字串的長度不超過512MB

2. 列表

建立新列表時Redis預設使用REDIS_ENCODING_ZIPLIST編碼，當一下任意一個條件滿足時，列表會被轉換成REDIS_ENCODING_LINKEDLIST編碼：

  • 試圖往列表新新增一個字串值，且這個字串的長度超過sever.list_max_ziplist_value(預設值是64)
  • ziplist 包含的節點超過server.list_max_ziplist_entries(預設的值為512)

且編碼只可能由壓縮列表轉化為雙端連結串列，一個列表可以儲存2^32-1個元素

2.1 壓縮列表

壓縮列表是Redis為了節約記憶體而開發的，由一系列特殊編碼的連續記憶體塊(而不是像雙端連結串列每個節點都是指標) 順序型資料結構；與雙端連結串列相比，壓縮列表可以節省記憶體空間，但是進行修改或增刪操作時，複雜度較高；因此當節點數量較少時，可以使用壓縮列表；但是節點數量多時，還是使用雙端連結串列划算。因為 ziplist 節約記憶體的性質，它被雜湊鍵、列表鍵和有序集合鍵作為初始化的底層實現來使
用

2.2 雙端連結串列

typedef struct listNode {
    struct listNode *prev;  //前驅節點
    struct listNode *next;  // 後繼節點
    void *value;
} listNode;

typedef struct list {
    //表頭指標
    listNode *head;
    //表尾指標
    listNode *tail;
    unsigned long len; // 節點長度
    void *(*dup) (void *ptr);
    void (*freee)(void *ptr);
    int (*match) (void *ptr, void *key);
}list;

小結：

作為Reids列表的底層實現之一； 作為通用資料結構，被其他功能模組使用。

  • 節點帶有前驅和後繼指標，訪問前驅節點和後繼節點的複雜度為 O(1) ，並且對連結串列
    的迭代可以在從表頭到表尾和從表尾到表頭兩個方向進行；
  • 連結串列帶有指向表頭和表尾的指標，因此對錶頭和表尾進行處理的複雜度為 O(1) ；
  • 連結串列帶有記錄節點數量的屬性，所以可以在 O(1) 複雜度內返回連結串列的節點數量（長
    度）；

3. 雜湊表

  • 當雜湊表使用字典編碼時，程式將雜湊表的鍵（key）儲存為字典的鍵，將雜湊表的值（value）儲存為字典的值, 字典的鍵和值都是字串物件

  • 壓縮列表編碼的雜湊表

  • 編碼轉換

    預設使用ziplist編碼，當滿足以下條件時，自動切換為字典編碼

    • 雜湊表中某個鍵或某個值的長度大於sever.hash_max_ziplist_value(預設值是64)
    • ziplist 包含的節點超過server.list_max_ziplist_entries(預設的值為512)

4. 集合

第一個新增到集合的元素，決定了建立集合時所使用的編碼：

  • 如果第一個元素可以表示為 long long 型別值（也即是，它是一個整數），那麼集合的初始編碼為 REDIS_ENCODING_INTSET 。
  • 否則，集合的初始編碼為 REDIS_ENCODING_HT 。

4.1 內部編碼

當使用 REDIS_ENCODING_HT 編碼時，集合將元素儲存到字典的鍵裡面，而字典的值則統一設為 NULL

如果一個集合使用 REDIS_ENCODING_INTSET 編碼， 當滿足以下條件的時候會轉成字典編碼

  • intset儲存的整數值個數超過server.set_max_intset_entries 預設值為512
  • 試圖往集合中新增一個新的元素，這個元素不能被表示為long, long型別，型別不一樣的時候使用字典

整數集合適用於集合所有元素都是整數且集合元素數量較小的時候，與雜湊表相比，整數集合的優勢在於集中儲存，節省空間；同時，雖然對於元素的操作複雜度也由O(1)變為了O(n)，但由於集合數量較少，因此操作的時間並沒有明顯劣勢。

5 .有序集合

有序集合與集合一樣，元素都不能重複；但與集合不同的是，有序集合中的元素是有順序的。與列表使用索引下標作為排序依據不同，有序集合為每個元素設定一個分數（score）作為排序依據

5.1 內部編碼

  • 壓縮列表

  • 跳躍表（skiplist）

    跳躍表是一種有序資料結構，通過在每個節點中維持多個指向其他節點的指標，從而達到快速訪問節點的目的。除了跳躍表，實現有序資料結構的另一種典型實現是平衡樹；大多數情況下，跳躍表的效率可以和平衡樹媲美，且跳躍表實現比平衡樹簡單很多，因此redis中選用跳躍表代替平衡樹。跳躍表支援平均O(logN)、最壞O(N)的複雜點進行節點查詢，並支援順序操作。Redis的跳躍表實現由zskiplist和zskiplistNode兩個結構組成：前者用於儲存跳躍表資訊（如頭結點、尾節點、長度等），後者用於表示跳躍表節點

typedef struct zset {
    dict *dict;
    zskiplist *zsl;
} zset;

5.2 編碼轉換

對於一個 REDIS_ENCODING_ZIPLIST 編碼的有序集，只要滿足以下任一條件，就將它轉換為REDIS_ENCODING_SKIPLIST 編碼

  • ziplist所儲存的元素數量超過伺服器屬性server.zset_max_ziplist_entries值 預設值是128
  • 新新增元素的member的長度大於伺服器屬性server.zset_max_ziplist_value 預設值是64

優化Redis 記憶體佔用

  1. 利用共享物件，可以減少物件的建立（同時減少了redisObject的建立），節省記憶體空間。目前redis中的共享物件只包括10000個整數（0-9999）；可以通過調整REDIS_SHARED_INTEGERS引數提高共享物件的個數；例如將REDIS_SHARED_INTEGERS調整到20000，則0-19999之間的物件都可以共享。

    考慮這樣一種場景：論壇網站在redis中儲存了每個帖子的瀏覽數，而這些瀏覽數絕大多數分佈在0-20000之間，這時候通過適當增大REDIS_SHARED_INTEGERS引數，便可以利用共享物件節省記憶體空間

記憶體碎片率

mem_fragmentation_ratio=used_memory_rss (Redis程式佔據作業系統的記憶體（單位是位元組）)/ used_memory(Redis分配器分配的記憶體總量（單位是位元組）).

如果記憶體碎片率過高（jemalloc在1.03左右比較正常），說明記憶體碎片多，記憶體浪費嚴重；這時便可以考慮重啟redis服務，在記憶體中對資料進行重排，減少記憶體碎片。

參考博文與書籍：

  1. 《redis設計與實現》
  2. Redis記憶體模型

相關文章