1. Redis 底層數據結構

Redis數據庫就像是一個哈希表，首先對key進行哈希運算得到哈希值再取模得到一個下標，每個元素是一個節點，節點之間形成鏈表。這感覺有點像Java中的HashMap。

不同的數據類型的實現方式是不一樣的，可以通過object encoding命令查看底層真正的數據存儲結構

同一種類型在不同的條件下所采用的數據結構也不一樣，例如：

Redis是鍵值對形式的數據庫，key可以是任意值（PS：最終都會轉成string），value有多種數據類型

詳見：https://redis.io/docs/manual/data-types/data-types-tutorial/

至此，已經很清楚，hash底層的結構是 ziplist 和 hashtable

那么，什么時候會從ziplist轉成hashtable呢？這個在redis.conf中有相關的配置，如下：

默認情況下：

當ziplist中entry的數量超過512的時候，會轉成hashtable 單個元素的值超過64字節的時候，會轉成hashtable

2. hashtable

在Redis中hashtable就是字典dict

通過源碼，可以看到dict是這樣定義的：

3. redisDb 與 redisObject

通過源碼得知，redisDb代表redis數據庫，redisObject代表存到數據庫中的數據

字典dict的結構前面已經看過了，于是整個數據庫的結構大概就是下面這個樣子：

?

4. ziplist

ziplist是一種特殊編碼的雙鏈表，被設計成非常節省內存。它存儲字符串和整型值，其中整數被編碼為實際整數，而不是一系列字符。它允許在O(1)時間內在列表的任意一邊進行push和pop操作。但是，由于每個操作都需要重新分配ziplist所使用的內存，因此實際的復雜性與ziplist所使用的內存量有關。

ziplist的大體布局如下：

<zlbytes> <zltail> <zllen> <entry> <entry> ... <entry> <zlend>

<uint32_t zlbytes>： 一個無符號整數，用于保存ziplist占用的字節數，包括zlbytes字段本身的四個字節。需要存儲這個值，以便能夠調整整個結構的大小，而不需要首先遍歷它。
<uint32_t zltail> ： 列表中最后一個條目的偏移量。
<uint16_t zllen> ?： 條目的數量。當有超過2^16-2個條目時，這個值被設置為2^16-1，我們需要遍歷整個列表來知道它包含多少項。
<uint8_t zlend> ： 一個特殊的條目，表示 ziplist 的結尾

?

5. linkedlist

linkedlist是一個雙向鏈表

?

6. quicklist

quicklistNode是一個32字節的結構體，描述快表的ziplist。

quicklist = linkedlist + ziplist