Redis設計與實現 - chapter7 壓縮列表

標籤：

Chapter7 壓縮列表

列表鍵和雜湊鍵的底層實現之一（列表鍵只包含少量元素，且元素為小整數或較短字串；而雜湊鍵之包含少量索引值對，且每個索引值對的key和value都是小整數或較短字串）。

為了節約記憶體。

壓縮列表的組成

一系列特殊編碼的連續記憶體塊組成的順序型（sequential）資料結構，包含多個節點entry，每個entry儲存一個位元組數組或一個整數。

記憶體組織：

具體含義：

壓縮列表節點的組成

每個節點儲存一個位元組數組或者一個整數值，由 previous_entry_length 、 encoding 、 content 三個部分組成。

儲存的位元組數組可以是以下三種長度的其中一種：

1. 長度小於等於 63 （2^{6}-1）位元組的位元組數組；

2. 長度小於等於 16383 （2^{14}-1） 位元組的位元組數組；

3. 長度小於等於 4294967295 （2^{32}-1）位元組的位元組數組；

而整數值則可以是以下六種長度的其中一種：

1. 4 位長，介於 0 至 12 之間的不帶正負號的整數；

2. 1 位元組長的有符號整數；

3. 3 位元組長的有符號整數；

4. int16_t 類型整數；

5. int32_t 類型整數；

6. int64_t 類型整數。

節點記憶體組織：

具體含義：

• previous_entry_length：前一個節點entry的長度位元組數，相當於向前指標；

• 長度：1或5位元組

• 前一節點長度<254：1位元組；

• 前一節點長度>=254：5位元組，且第一位元組設為0xFE（即254），後4個位元組儲存真正的長度資料；

• encoding：節點content屬性所儲存資料的類型和長度，根據位元組資料和整數兩種資料類型可做如下解析

• content：儲存節點真正的資料，由encoding屬性決定如何解釋；
  

連鎖更新問題

特殊情況：

• 插入：多個連續的、長度介於250~253位元組直接的節點e1至eN（previous_entry_length屬性都為1個位元組）；此時在e1前插入一個長度>=254位元組的節點，則需更新e1的previous_entry_length屬性（由1位元組長度變為5位元組），導致e1長度>=254，於是連鎖更新e2、e3...eN。

• 刪除：在兩個節點big（長度>=254）和small（長度<254）之後緊跟著多個連續的、長度介於250~253位元組直接的節點e1至eN（previous_entry_length屬性都為1個位元組）；此時刪除small，則需更新e1的previous_entry_length屬性（由1位元組長度變為5位元組），導致e1長度>=254，於是連鎖更新e2、e3...eN。

連鎖更新最壞情況下需要對壓縮列表做N次空間重分配操作，而每次分配的最壞複雜度為O(N)，所以連鎖更新最壞情況為O(N^2)。但是可預見的是對效能影響不大：

1. 出現上述兩種情況的機率很小；

2. 即使出現，只要更新的節點不多，效能也不會有影響；

Redis設計與實現 - chapter7 壓縮列表