快捷導(dǎo)航

Redis中ziplist與quicklist解析與對比小結(jié)

更新時間：2026年01月07日 09:00:52 作者：程序員風(fēng)嶼

本文介紹了Redis中List數(shù)據(jù)類型的兩種編碼方式ziplist和quicklist,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧

一、背景 — 為什么要有多種“列表（List）”編碼

在內(nèi)存數(shù)據(jù)庫 Redis 中，列表（List）是常用數(shù)據(jù)類型之一，用于實現(xiàn)隊列、堆棧、消息隊列、任務(wù)隊列等場景。
不同場景對內(nèi)存使用與訪問效率有不同要求：少量元素 → 希望節(jié)省內(nèi)存；大量元素或頻繁插入/刪除 → 需要高性能操作。
因此Redis 設(shè)計者提供了不同的“編碼方式”（encoding）來存儲 List 對象，以兼顧 空間效率 與 操作效率。

在歷史發(fā)展中，Redis 對 List 的編碼方式經(jīng)歷了如下階段：

早期：使用 雙向鏈表（linkedlist） 或 壓縮列表（ziplist），兩種可選。
從 Redis 3.2 版本起，引入 quicklist，作為新的默認(rèn)結(jié)構(gòu)，取代了 ziplist + linkedlist 的混合策略。

下面分別介紹 ziplist 和 quicklist 的結(jié)構(gòu)與特性，然后比較優(yōu)缺點。

二、ziplist —— 壓縮列表（compact list）

2.1 ziplist 是什么

ziplist 是 Redis 提供的一種“緊湊型列表結(jié)構(gòu)（compact list）”。它將多個 list 元素連續(xù)地存放在一塊 連續(xù)內(nèi)存（contiguous memory block） 中。
每個 entry（元素）包含必要的 metadata（如前一個 entry 長度、當(dāng)前 entry 長度、數(shù)據(jù)內(nèi)容等），因此 ziplist 可以存放不同長度的數(shù)據(jù)項（字符串、整數(shù)等），而不需要為每個元素單獨分配內(nèi)存。
因為內(nèi)存連續(xù)、元素緊湊，ziplist 在內(nèi)存占用上非常高效 — 對于存儲少量、短字符串／整數(shù)列表時，能節(jié)省大量內(nèi)存。

ziplist結(jié)構(gòu)如圖所示，參考Redis面試題：

下邊的圖也可加深理解

ziplist的各字段含義如下。

zlbytes：壓縮列表的字節(jié)長度，占4B，因此壓縮列表最長 2³²?1B。
zltail：壓縮列表尾元素相對于壓縮列表起始地址的偏移量，占4B。
zllen：壓縮列表的元素數(shù)目，占2B；當(dāng)壓縮列表的元素數(shù)目超過65535（2¹??1）時，zllen 無法存儲，此時必須遍歷整個壓縮列表才能獲取元素數(shù)目。
entry1、entr2y：壓縮列表存儲的若干個元素，可以是字節(jié)數(shù)組或者整數(shù)，長度不限；
zlend：壓縮列表的結(jié)尾，占1B，固定為0xFF。

對于每一個entry元素來講

entry 結(jié)構(gòu)包含三個字段：

prelen
- 記錄前一個元素的長度，用于從后向前遍歷。
- 前一個元素長度 < 254B → 占 1B。
- 前一個元素長度 ≥ 254B → 占 5B（首字節(jié)為 0xFE，后 4B 為實際長度）。
encoding
- 表示 data 的數(shù)據(jù)類型（整數(shù)或字節(jié)數(shù)組）。
- 長度可變（1B、2B 或 5B），通過開頭的比特區(qū)分。
- 同時可包含字節(jié)數(shù)組的長度信息（如 6bit、14bit 或 32bit 表示長度）。

以下是encoding字段的元素編碼

編碼 (encoding) 標(biāo)識 / 類型	encoding長度	說明 / 含義 (簡要)
00pppppp	1B	表示一個 string，長度 ≤ 63 字節(jié)。
01pppppp + qqqqqqqq	2B	表示一個 string，長度 ≤ 2¹??1字節(jié)。
10000000 + 4 bytes length	5B	表示一個較長 string（長度 ≤ 2³²?1字節(jié)）。
11000000	1B	表示一個 int16_t（16-bit 整數(shù)）元素。
11010000	1B	表示一個 int32_t（32-bit 整數(shù)）元素。
11100000	1B	表示一個 24-bit 整數(shù)編碼（special 24-bit 整數(shù)）。
11111110	1B	表示一個 int8_t（8-bit 整數(shù)）元素。
1111xxxx	1B	xxxx表示范圍為 0–12 的整數(shù) 。

data
- 實際存儲的數(shù)據(jù)，可以是整數(shù)或字節(jié)數(shù)組，長度由 encoding 決定。

2.2 ziplist 的適用條件（默認(rèn)策略）

在 Redis 配置文件（或編譯時默認(rèn)）中，對于 LIST、HASH、ZSET 等類型，會設(shè)置參數(shù)來決定是否使用 ziplist，例如：

list-max-ziplist-entries：限制 ziplist 中元素（entry）個數(shù)
list-max-ziplist-value：限制每個 entry 的最大字節(jié)數(shù)（value 大?。?/li>

當(dāng)元素數(shù)量或元素大小超過這些限制時，Redis 會放棄 ziplist 編碼，轉(zhuǎn)為其他更適合的編碼方式（在老版本可能是 linkedlist，現(xiàn)在是 quicklist）。

2.3 ziplist 的優(yōu)點與缺點

優(yōu)點：

內(nèi)存利用率高 — 非常節(jié)省內(nèi)存空間，適合存儲少量、小數(shù)據(jù)。
內(nèi)存連續(xù)，有利于 CPU 緩存和遍歷效率。

缺點 / 缺陷：

對修改操作（插入 / 刪除 / 更新）不友好 — 因為要保持連續(xù)內(nèi)存，一旦中間插入或刪除，就可能觸發(fā)內(nèi)存重新分配和數(shù)據(jù)搬移（realloc + memcpy），代價高昂。這里會涉及連鎖更新問題。
當(dāng)元素較多或較大時，ziplist 會非常臃腫或重復(fù) realloc，性能和穩(wěn)定性都不理想。
因此，ziplist 更適合“短小、穩(wěn)定、不頻繁變更”的列表數(shù)據(jù)，不適合大數(shù)據(jù)量或高頻寫入場景。

三、quicklist —— 快速列表（QuickList）

3.1 quicklist 是什么

quicklist 是從 Redis 3.2 開始引入的 List 編碼方式，用于替代早期的 ziplist /adlist 編碼。
它本質(zhì)上是 雙向鏈表 + 壓縮子列表 的混合結(jié)構(gòu)：一個 quicklist 是一個雙向鏈表，而鏈表的每個節(jié)點（quicklistNode）內(nèi)部持有一個 ziplist來存儲一段連續(xù)的元素。
這樣的設(shè)計兼顧了鏈表和 ziplist 各自的優(yōu)點。

3.2 quicklist 的結(jié)構(gòu)與配置參數(shù)

quicklist 的主要結(jié)構(gòu)由 quicklist 和 quicklistNode 兩個 C 結(jié)構(gòu)體定義，在 Redis 源碼中（例如 quicklist.h / quicklist.c）可以查看。

結(jié)構(gòu)圖

在quicklist中，關(guān)鍵字段包括：

head / tail：指向鏈表頭尾節(jié)點。
count：List 中所有元素entry的總數(shù)。
len：quicklistNode 節(jié)點數(shù)量。
fill：用于控制每個 ziplist 容量上限entry 數(shù)量或字節(jié)大小，通過 list-max-ziplist-size 配置項設(shè)定。
compress：用于控制壓縮深度，即鏈表兩端多少個節(jié)點不壓縮，中間節(jié)點可被壓縮以節(jié)省內(nèi)存，通過 list-compress-depth 配置項控制。
每個 quicklistNode 包含指向內(nèi)部 ziplist（或 listpack）的指針 zl，大小 sz，元素計數(shù) count 等信息。

?? 注意：在 Redis 最新版本中（例如 7.x），listpack 已經(jīng)逐步取代 ziplist 作為內(nèi)部壓縮子列表結(jié)構(gòu)，但 quicklist 的設(shè)計思想不變 —— 分段 + 鏈表 + 壓縮子列表。

3.3 quicklist 的優(yōu)點

兼顧空間與效率：通過將列表拆成多個小段（ziplist），既避免了大型鏈表帶來的內(nèi)存碎片和高 overhead，也避免了大型 ziplist 帶來的頻繁 realloc 問題。
快速頭尾操作（push/pop）：因為 quicklist 是鏈表結(jié)構(gòu)，在頭尾插入刪除是 O(1) 操作，非常高效，適合隊列／棧等操作頻繁場景。
壓縮可選：中間節(jié)點可以壓縮（LZF 等算法／listpack 壓縮），節(jié)省內(nèi)存；而頭尾保留原始以保證訪問性能。
靈活適應(yīng)不同場景：既適合存儲小量短元素，也適合存儲大量元素或長列表。

3.4 quicklist 的限制與注意事項

如果配置不當(dāng)（ziplist 內(nèi)部過大、壓縮設(shè)置不合理），可能出現(xiàn)性能開銷過重，或內(nèi)存碎片／壓縮開銷問題。
quicklist 內(nèi)部實現(xiàn)比簡單鏈表或數(shù)組復(fù)雜，對于某些極端訪問模式（大量隨機(jī)訪問中間、頻繁跨節(jié)點訪問）可能不如純數(shù)組或其他結(jié)構(gòu)高效。

quicklist 的兩種極端情況如下：

1. 當(dāng) ziplist 節(jié)點過多時，quicklist 退化為雙向鏈表。最極端的情況是每個 ziplist 節(jié)點只包含一個 entry，即一個元素對應(yīng)一個節(jié)點。
2. 當(dāng) ziplist 節(jié)點過少時，quicklist 退化為 ziplist。最極端的情況是整個 quicklist 中只含有一個 ziplist 節(jié)點。

對于非常頻繁的隨機(jī)訪問或修改，可能需要謹(jǐn)慎評估是否適合使用列表結(jié)構(gòu)。

四、ziplist vs quicklist —— 對比總結(jié)

特性 / 維度	ziplist	quicklist
內(nèi)存布局	連續(xù)內(nèi)存 block（compact）	鏈表 + 多個 ziplist／listpack segments
內(nèi)存開銷	低，連續(xù)、緊湊	較高（鏈表＋子列表）但比純鏈表低
適合場景	元素少、數(shù)據(jù)小、讀不頻繁修改	元素多、隊列 / 棧 / 批量 push/pop / 變長頻繁
插入／刪除性能	中間插入刪除開銷大（可能 memcpy）	頭尾 O(1)，節(jié)點級調(diào)整，較穩(wěn)定
內(nèi)存碎片	幾乎無	較少（鏈表 + 子列表）
壓縮 / 節(jié)省空間	默認(rèn)緊湊	可配置壓縮，兼顧效率
Redis 中默認(rèn)支持	早期版本	Redis 3.2+ 默認(rèn)

Redis 之所以在內(nèi)存數(shù)據(jù)庫 / 緩存系統(tǒng)中表現(xiàn)出色，很大程度上是因為它為不同場景提供了優(yōu)化良好的底層數(shù)據(jù)結(jié)構(gòu)。ziplist 與 quicklist 是 Redis List 類型在歷史與現(xiàn)在對空間與時間折中的經(jīng)典設(shè)計。