## 1. Reids記憶體的劃分 1. 資料 記憶體統計在used_memory中 2. 程序本身執行需要記憶體 Redis主程序本身執行需要的記憶體佔用，程式碼、常量池等 3. 緩衝記憶體，客戶端緩衝區、複製積壓緩衝區、AOF緩衝區。有jemalloc分配記憶體，會統計在used_memory中 4. 記憶體碎片 Redis在分配、回收物理記憶體過程中產生的。記憶體碎片不會統計在used_memory中。如果Redis伺服器中的記憶體碎片已經很大，可以通過安全重啟的方式減小記憶體碎片：因為重啟之後，Redis重新從備份檔案中讀取資料，在記憶體中進行重排，為每個資料重新選擇合適的記憶體單元，減小記憶體碎片。 ## 2. Redis的資料儲存的細節 涉及到記憶體分配器jemalloc， 簡單動態字串（SDS），5種值型別物件的內部編碼，redisObject,  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儲存資料時，會選擇大小最合適的記憶體塊進行儲存。  ### 2.2 RedisObject redis物件的型別，內部編碼，記憶體回收，共享物件等功能都需要RedisObject的支援 ```c++ 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 簡單動態字串 結構   ```c++ 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選擇了高效且實現簡單的雜湊表作為字典的底層實現。** ```c++ /* 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 雜湊表的實現 ```c++ /*雜湊表*/ typedef struct dictht { dictEntry **table; // 雜湊表節點指標陣列（俗稱桶， bucket） unsigned long size; //指標陣列的大小 unsigned long sizemask; //指標陣列的長度掩碼 unsigned long used; // 雜湊表現有的節點數量 }dictht; ``` ```c++ /*雜湊表節點*/ 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），而雜湊表實現必須想辦法對碰撞進行處理。字典雜湊表所使用的碰撞解決方法被稱之為鏈地址法：這種方法使用連結串列將多個雜湊值相同的節點串連在一起，從而解決衝突問題。 假設現在有一個帶有三個節點的雜湊表：  對於一個新的鍵值對 key4 和 value4 ，如果 key4 的雜湊值和 key1 的雜湊值相同，那麼它們將在雜湊表的 0 號索引上發生碰撞。  #### 3.2.4 新增新鍵值對時觸發rehash操作？ 對於使用鏈地址法來解決碰撞問題的雜湊表 dictht 來說，雜湊表的效能依賴於它的大小（size屬性）和它所儲存的節點的數量（used 屬性）之間的比率：比率最好在1：1。 ## 4. 跳躍表 跳躍表是一種隨機化資料結果，查詢、新增、刪除操作都可以在對數期望時間下完成 跳躍表目前在Redis的唯一作用就是作為有序集型別的底層資料結構之一 Redis對跳躍表進行了修改包括： - score值可重複 - 對比一個元素需要同時檢查它的score和member - 每個節點帶有高度為1層的後退指標，用於從表尾方向向表頭方向迭代 [Redis 為什麼用跳錶而不用平衡樹？](https://juejin.im/post/57fa935b0e3dd90057c50fbc#heading-8) ### 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 雙端連結串列  ```c++ 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兩個結構組成：前者用於儲存跳躍表資訊（如頭結點、尾節點、長度等），後者用於表示跳躍表節點 ```c++ 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記憶體模型](https://www.cnblogs.com/kismetv/p/86549