從SDS到跳表，一篇34分鐘長文把Redis五種資料型別拆完了

2026年9月24日，掘金作者xyLJ發布了一篇約34分鐘閱讀時間的長文，題目是「Redis常見的資料型別及底層結構」。文章主線很清楚：Redis每種資料型別選什麼底層結構，答案都指向同一件事，在記憶體與效能之間找平衡。這篇技術長文近日在開發者社羣流傳，這裡用列點方式整理它的重點。

先把地基打好：Redis是什麼

文章開頭先交代Redis的三個基本特性：

• 鍵值型資料庫：所有資料都以key-value形式儲存。
• 純記憶體運行：資料放在記憶體裡，讀寫速度快，這是它效能強的關鍵。
• 單線程命令執行：單條命令天然具有原子性。作者特別提醒，Redis 6.0起網路I/O已支援多線程，只有命令執行仍是單線程。

另外Redis支援RDB快照與AOF追加日志兩種持久化機制，可把記憶體資料定期寫入硬碟。

五種型別，各自壓在不同的底層結構上

作者引用極客時間的架構圖指出，一種資料型別可能對應兩種資料結構。原因很直接：資料量不同時，換結構就是為了在時間與空間之間取得平衡。

String字串型別：底層是SDS。可以存字串、整數、浮點數，但作者提醒Redis字串是二進制安全的，底層統一按位元組序列儲存，整數與浮點數只是命令語意層面的概念。應用場景包括快取物件、常規計數（INCR是原子操作，適合高併發下的點讚數與閱讀數），以及用SET key value NX EX實作分散式鎖。

List列表型別：底層是quicklist，文章還列了quicklist的主要配置項。

Set集合型別：特色是「三態轉換」，依據資料狀態在不同結構間切換。

ZSet有序集合型別：跳表加雜湊表的組合。文章花了不少篇幅解釋什麼是跳表，也回答了兩個常見問題：為什麼Redis用跳表而不用B+樹，以及為什麼ZSet要同時使用skiplist和dict。

Hash雜湊型別：底層涉及漸進式rehash，作者同樣解釋了為什麼Hash要並用兩種資料結構。

值得留意的細節

文章在String段落有一段實務提醒：用SET NX做分散式鎖時，value必須是唯一標識（例如UUID加執行緒ID），釋放鎖時要先驗證再刪除，否則可能誤刪別人的鎖。原文在這段之後因篇幅截斷，完整內容可回原篇閱讀。

整體來說，這篇長文的價值在於把零散的背誦知識串成一條「為什麼這樣選」的線，對準備後端面試或想理解Redis設計取舍的讀者，是一份結構清楚的材料。