Redis 數據結構與內存管理策略（上）

Redis 數據結構與內存管理策略（上）

標籤： Redis Redis數據結構 Redis內存管理策略 Redis數據類型 Redis類型映射

---

• Redis 數據類型特點與使用場景
  • String、List、Hash、Set、Zset
  • 案例：滬江團購系統大促 hot-top 接口 cache 設計
• Redis 內存數據結構與編碼
  • OBJECT encoding key、DEBUG OBJECT key
  • 簡單動態字符串（simple dynamic string）
  • 鏈表（linked list）
  • 字典（dict）
  • 跳錶（skip list）
  • 整數集合（int set）
  • 壓縮表（zip list）
  • Redis Object 類型與映射
• Redis 內存管理策略
  • 鍵 過期時間、生存時間
  • 過期鍵刪除策略
  • AOF 、RDB 處理過期鍵策略
  • Redis LRU 算法
• Redis 持久化方式
  • AOF (Append-only file)
  • RDB (Redis DataBase)

Redis 數據類型特點與使用場景

redis 爲我們提供了 5 種數據類型，基本上我們使用頻率最高的就是 string ，而對其他四種數據類型使用的頻次稍弱於 string 。

一方面是由於 string 使用起來比較簡單，可以方便存儲複雜大對象，使用場景比較多。還有一個原因就是由於 redis expire time 只能設置在 key 上，像 list、hash、set、zset 屬於集合類型，會管理一組 item，我們無法在這些集合的 item 上設置過期時間，所以使用 expire time 來處理集合的 cache 失效會變得稍微複雜些。但是 string 使用 expire time 來管理過期策略會比較簡單，因爲它包含的項少。這裏說的集合是寬泛的類似集合。

導致我們習慣性的使用 string 而忽視其他四種數據類型的另一個深層次原因，大多是由於我們對另外四種數據類型的使用和原理不是太瞭解。這個時候往往會忽視在特定場景下使用某種數據類型可能會比 string 性能高出很多，比如使用 hash 結構來提高某個實體的某個項的修改等。

這裏我們不打算羅列這 5 種數據類型的使用方法，這些資料網上有很多。我們主要討論這 5 種數據類型的功能特點，這些特點分別適合用於處理哪些現實的業務場景，最重要的是我們如何組合性的使用這 5 種數據類型來解決複雜的 cache 問題。

String、List、Hash、Set、Zset

String

string 是 redis 提供的字符串類型。可以針對 string 類型獨立設置 expire time 。通常用來存儲長字符串數據，比如，某個對象的 json 字符串。

string 類型我們在使用上最巧妙的是可以動態拼接 key。通常我們可以將一組 id 放在 set 裏，然後動態查找 string 還是否存在，如果不存在說明已經過期或者由於數據修改主動 delete 了，需要再做一次 cache 數據 load 。

雖然 set 無法設置 item 的過期時間，但是我們可以將 set item 與 string key 關聯來達到相同的效果。

上圖中的左邊是一個 key 爲 set:order:ids 的 set 集合，它可能是一個全量集合，也可能是某個查詢條件獲取出來的一個集合。

有時候複雜點的場景需要多個 set 集合來支撐計算，在 redis 服務器 裏可能會有很多類似這樣的集合。

這些集合我們可以稱爲 功能數據，這些數據是用來輔助 cache 計算的，當進行各種集合運算之後會得出當前查詢需要返回的子集，最後我們纔會去獲取某個訂單真正的數據。

這些 string:order:{orderId} 字符串 key 並不一定是爲了服務一種場景，而是整個系統最底層的數據，各種場景最後都需要獲取這些數據。那些 set 集合可以認爲是查詢條件數據，用來輔助查詢條件的計算。

redis 爲我們提供了 TYPE 命令來查看某個 key 的數據類型，如：string 類型：

SET string:order:100 order-100
TYPE string:order:100

string

List

list 在提高 throughput 的場景中非常適用，因爲它特有的 LPUSH、RPUSH、LPOP、RPOP 功能可以無縫的支持生產者、消費者架構模式。

這非常適合實現類似 Java Concurrency Fork/Join 框架中的 work-stealing 算法 (工作竊取) 。

java fork/join 框架使用並行來提高性能，但是會帶來由於併發 take task 帶來的 race condition (競態條件) 問題，所以採用 work-stealing 算法 來解決由於競爭問題帶來的性能損耗。

上圖中模擬了一個典型的支付 callback 峯值場景。在峯值出現的地方一般我們都會使用加 buffer 的方式來加快請求處理速度，這樣才能提高併發處理能力，提高 throughput 。

支付 gateway 收到 callback 之後不做任何處理直接交給 分發器 。分發器 是一個無狀態的 cluster ，每個 node 通過向 註冊中心 pull handler queue list ，也就是獲取下游處理器註冊到註冊中心裏的消息通道。

每一個分發器 node 會維護一個本地 queue list ，然後順序推送消息到這些 queue list 即可。這裏會有點小問題，就是 支付 gateway 調用分發器的時候是如何做 load balance ，如果不是平均負載可能會有某個 queue list 高出其他 queue list 。

而分發器不需要做 soft load balance ，因爲哪怕某個 queue list 比其他 queue list 多也無所謂，因爲下游 message handler 會根據 work-stealing 算法來竊取其他消費慢的 queue list 。

redis list 的 LPUSH、RPUSH、LPOP、RPOP 特性確實可以在很多場景下提高這種橫向擴展計算能力。

Hash

hash 數據類型很明顯是基於 hash 算法的，對於項的查找時間複雜度是 O(1) 的，在極端情況下可能出現項 hash 衝突問題，redis 內部是使用鏈表加 key 判斷來解決的。具體 redis 內部的數據結構我們在後面有介紹，這裏就不展開了。

hash 數據類型的特點通常可以用來解決帶有映射關係，同時又需要對某些項進行更新或者刪除等操作。如果不是某個項需要維護，那麼一般可以通過使用 string 來解決。

如果有需要對某個字段進行修改，使用 string 很明顯是會多出很多開銷，需要讀取出來反序列化成對象然後操作，然後再序列化寫回 redis ，這中間可能還有併發問題。

那我們可以使用 redis hash 提供的實體屬性 hash 存儲特性，我們可以認爲 hash value 是一個 hash table ，實體的每一個屬性都是通過 hash 得到屬性的最終數據索引。

上圖使用 hash 數據類型來記錄頁面的 a/b metrics ，左邊的是首頁 index 的各個區域的統計，右邊是營銷 marketing 的各個區域統計。

在程序裏我們可以很方便的使用 redis 的 atomic 特性對 hash 某個項進行累加操作。

HMSET hash:mall:page:ab:metrics:index topbanner 10 leftbanner 5 rightbanner 8 bottombanner 20 productmore 10 topshopping 8
OK

HGETALL hash:mall:page:ab:metrics:index
 1) "topbanner"
 2) "10"
 3) "leftbanner"
 4) "5"
 5) "rightbanner"
 6) "8"
 7) "bottombanner"
 8) "20"
 9) "productmore"
10) "10"
11) "topshopping"
12) "8"

HINCRBY hash:mall:page:ab:metrics:index topbanner 1
(integer) 11

使用 redis hash increment 進行原子增加操作。HINCRBY 命令可以原子增加任何給定的整數，也可以通過 HINCRBYFLOAT 來原子增加浮點類型數據。

Set

set 集合數據類型可以支持集合運算，不能存儲重複數據。

set 最大的特點就是集合的計算能力，inter 交集、union 並集、diff 差集，這些特點可以用來做高性能的交叉計算或者剔除數據。

set 集合在使用場景上還是比較多和自由的。舉個簡單的例子，在應用系統中比較常見的就是商品、活動類場景。用一個 set 緩存有效商品集合，再用一個 set 緩存活動商品集合。如果商品出現上下架操作只需要維護有效商品 set ，每次獲取活動商品的時候需要過濾下是否有下架商品，如果有就需要從活動商品中剔除。

當然，下架的時候可以直接刪除緩存的活動商品，但是活動是從 marketing 系統中 load 出來的，就算我將 cache 裏的活動商品刪除，當下次再從 marketing 系統中 load 活動商品時候還是會有下架商品。當然這只是舉例，一個場景有不同的實現方法。

上圖中左右兩邊是兩個不同的集合，左邊是營銷域中的可用商品ids集合，右邊是營銷域中活動商品ids集合，中間計算出兩個集合的交集。

SADD set:marketing:product:available:ids 1000100 1000120 1000130 1000140 1000150 1000160

SMEMBERS set:marketing:product:available:ids
1) "1000100"
2) "1000120"
3) "1000130"
4) "1000140"
5) "1000150"
6) "1000160"

SADD set:marketing:activity:product:ids 1000100 1000120 1000130 1000140 1000200 1000300

SMEMBERS set:marketing:activity:product:ids
1) "1000100"
2) "1000120"
3) "1000130"
4) "1000140"
5) "1000200"
6) "1000300"

SINTER set:marketing:product:available:ids set:marketing:activity:product:ids
1) "1000100"
2) "1000120"
3) "1000130"
4) "1000140"

在一些複雜的場景中，也可以使用 SINTERSTORE 命令將交集計算後的結果存儲在一個目標集合中。 這在使用 pipeline 命令管道中特別有用，將 SINTERSTORE 命令包裹在 pipeline 命令串中可以重複使用計算出來的結果集。

由於 redis 是 Signle-Thread 單線程模型 ，基於這個特性我們就可以使用 redis 提供的 pipeline 管道 來提交一連串帶有邏輯的命令集合，這些命令在處理期間不會被其他客戶端的命令干擾。

Zset

zset 排序集合與 set 集合類似，但是 zset 提供了排序的功能。在介紹 set 集合的時候我們知道 set 集合中的成員是無序的，zset 填補了集合可以排序的空隙。

zset 最強大的功能就是可以根據某個 score 比分值 進行排序，這在很多業務場景中非常急需。比如，在促銷活動里根據商品的銷售數量來排序商品，在旅遊景區里根據流入人數來排序熱門景點等。

基本上人們在做任何事情都需要根據某些條件進行排序。

其實 zset 在我們應用系統中能用到地方到處都是，這裏我們舉一個簡單的例子，在團購系統中我們通常需要根據參團人數來排序成團列表，大家都希望參加那些即將成團的團。

上圖是一個根據團購code創建的zset，score 分值 就是參團人數累加和。

ZADD zset:marketing:groupon:group:codes 5 G_PXYJY9QQFA 8 G_4EXMT6NZJQ 20 G_W7BMF5QC2P 10 G_429DHBTGZX 8 G_KHZGH9U4PP

ZREVRANGEBYSCORE zset:marketing:groupon:group:codes 1000 0
1) "G_W7BMF5QC2P"
2) "G_ZMZ69HJUCB"
3) "G_429DHBTGZX"
4) "G_KHZGH9U4PP"
5) "G_4EXMT6NZJQ"
6) "G_PXYJY9QQFA"

ZREVRANGEBYSCORE zset:marketing:groupon:group:codes 1000 0 withscores
 1) "G_W7BMF5QC2P"
 2) "20"
 3) "G_ZMZ69HJUCB"
 4) "10"
 5) "G_429DHBTGZX"
 6) "10"
 7) "G_KHZGH9U4PP"
 8) "8"
 9) "G_4EXMT6NZJQ"
10) "8"
11) "G_PXYJY9QQFA"
12) "5"

zset 本身提供了很多方法用來進行集合的排序，如果需要 score 分值可以使用 withscore 字句帶出每一項的分值。

在一些比較特殊的場合可能需要組合排序，可能有多個 zset 分別用來對同一個實體在不同維度的排序，按時間排序、按人數排序等。這個時候就可以組合使用 zset 帶來的便捷性，利用 pipeline 再結合多個 zset 最終得出組合排序集合。

案例：滬江團購系統大促 hot-top 接口 cache 設計

我們總結了 redis 提供的 5 種數據類型的各自特點和一般的使用場景。但是我們不僅僅可以分開使用這些數據類型，我們完全可以綜合使用這些數據類型來完成複雜的 cache 場景。

下面我們分享一個使用多個 zset 、string 來優化 團購系統 前臺接口的例子。由於篇幅和時間限制，這裏只介紹跟本次案例相關的信息。

hot-top 接口是指熱點、排名接口的意思，表示它的瀏覽量、併發量比較高，一般大促的時候都會有幾個這種性能要求比較高的接口。

我們先來分析一個查詢接口所包含的常規信息。

首先一個查詢接口肯定是有 query condition 查詢條件 ，然後是 sort 排序信息 、最後是 page 分頁信息 。這是一般接口所承擔的基本職責，當然，特殊場景下還需要支持 master/slave replication 時關於數據 session 一致性 的要求，需要提供跟蹤標記來回 master 查詢數據，這裏就不展開了。

我們可以抽象出這幾個維度的信息：

query condition
查詢條件，companyid=100，sellerid=1010101 諸如此類。
sort
排序信息，一般是默認一個列排序，但是在複雜的場景下會有可能讓接口使用者定製排序字段，比如一些租戶信息列。
page
分頁信息，簡單理解就是數據記錄排完序之後的第幾行到第幾行。

由於這裏我們純粹用 redis 來提高 cache 能力，不涉及到有關於任何搜索的能力，所以這裏忽略其他複雜查詢的情況。其實我們在複雜的地方使用了 elastcsearch 來提高搜索能力。

上述我們分析總結出了一個查詢接口的基本信息，這裏還有一個有關於高併發接口的設計原則就是將 hot-top 接口和一般 search 接口分離開，因爲只有分而治之才能分別根據特點選用不同的技術。如果我們不分職責將所有的查詢場景封裝在一個接口裏，那麼在後面優化接口性能的時候基本就很麻煩了，有些場景是無法或者很難用 cache 來解決的，因爲接口裏耦合了各種場景邏輯，就算勉強能實現性能也不會高。

前面做這些鋪墊是爲了能在介紹案例的時候達成一個基本的共識。現在我們來看下這個團購系統的 hot-top 接口的具體邏輯。

在大促的時候需要展現團購列表，這個接口的訪問量是非常大的，團購活動需要根據參團人數倒序排序，並且分頁返回指定數量的團列表。

我們假設這個接口名爲 getTopGroups(getTopGroupsRequest request)

query condition 查詢條件問題

我們來仔細分析下，首先不同的查詢條件從 DB 裏查詢出來的數據是不一樣的，也就是說查詢出來的團列表是不一樣的，可能有 company 公司 、channel 渠道 等過濾條件。由於一個團購活動下不會有太多團，頂多上百個是極限了，所以一個查詢條件出來的團列表也頂多幾十個，而且根據場景分析熱點查詢條件不會超過十個，所以我們選擇將 查詢條件 hash 出一個 code 來緩存本次查詢條件的全量團列表集合，但是這些結果集是沒有任何排序的。

sort 排序問題

再看根據參團人數排序問題，我們立刻就可以想到使用 zset 來處理團排序問題，因爲只有一個排序維度，所以一個 zset 就夠了。我們使用一個 zset來緩存所有團的參團人數集合，它是一個全量的團排序集合。

那麼我們如何將用戶的查詢條件出來的團列表根據參團人數排序尼，剛好可以使用 zset 的交集運算直接計算出當前這個集合的 zset 子集。

page 分頁問題

通過對已經排序之後的團列表 zset 使用 zrange 來獲取出分頁集合。

我們來看下完整的流程，如何處理查詢、排序、分頁的。

上圖從 query condition 計算 hash code ，然後通過 DB 查詢出當前條件全量團列表。
zset:marketing:groupon:hottop:available:group key 表示全量團的參團人數，用一個 zset 來緩存。接着將這兩個 zset 計算交集，就可以得出當前查詢所需要的帶有參團人數的 zset ，最後在使用 zrevrange 獲取分頁區間。

ZADD zset:marketing:groupon:hottop:condition:2986080 0 G4ZD5732YZQ 0 G5VW3YF42UC 0 GF773FEJ7CC 0 GFW8DUEND8S 0 GKPKKW8XEY9 0 GL324DGWMZM
(integer) 6

ZADD zset:marketing:groupon:hottop:available:group 5 GN7KQH36ZWK 10 GS7VB22AWD4 15 GF773FEJ7CC 17 G5VW3YF42UC 18 G4ZD5732YZQ 32 GTYJKCEJBRR 40 GKPKKW8XEY9 45 GL324DGWMZM 50 GFW8DUEND8S 60 GYTKY4ACWLT
(integer) 10

ZINTERSTORE zset:marketing:groupon:hottop:condition:interstore 2 zset:marketing:groupon:hottop:condition:2986080 zset:marketing:groupon:hottop:available:group
(integer) 6

ZRANGE zset:marketing:groupon:hottop:condition:interstore 0 -1 withscores
 1) "GF773FEJ7CC"
 2) "15"
 3) "G5VW3YF42UC"
 4) "17"
 5) "G4ZD5732YZQ"
 6) "18"
 7) "GKPKKW8XEY9"
 8) "40"
 9) "GL324DGWMZM"
10) "45"
11) "GFW8DUEND8S"
12) "50"

ZREVRANGE zset:marketing:groupon:hottop:condition:interstore 2 4 withscores
1) "GKPKKW8XEY9"
2) "40"
3) "G4ZD5732YZQ"
4) "18"
5) "G5VW3YF42UC"
6) "17"

有了返回的團 code 集合之後就可以通過 mget 來批量獲取 string 類型的團詳情信息，這裏就不貼出代碼了。

由於篇幅和時間關係，這裏就不展開太多的業務場景介紹了。這其中還涉及到計算 cache 過期時間的問題，這也跟促銷活動的運營規則有關係，還涉及到有可能 query condition hash 衝突問題等，但是這些已經不與我們本節主題相關。

Redis 內存數據結構與編碼

我們已經瞭解了 redis 提供的 5 種數據類型，那麼 redis 內部到底是如何支持這 5 種數據類型的，也就是說 redis 到底是使用什麼樣的數據結構來存儲、查找我們設置在內存中的數據。

雖然我們使用 5 種數據類型來緩存數據，但是 redis 會根據我們存儲數據的不同而選用不同的數據結構和編碼。

我們日常使用的是 redis 提供的 5 種數據類型，但是這 5 種數據類型在內存中的數據結構和編碼有很多種。隨着我們存儲的數據類型的不同、數據量的大小不同都會引起內存數據結構的動態調整。

本節只是做數據結構和編碼的一般性介紹，不做過多細節討論，一方面是關於 redis 源碼分析的資料網上有很多，還有一個原因就是 redis 每一個版本的實現有很大差異，一旦展開細節討論每一個點每一個數據結構都會很複雜，所以我們這裏就不展開討論這些，只是起到拋磚引玉作用。

OBJECT encoding key、DEBUG OBJECT key

我們知道使用 type 命令可以查看某個 key 是否是 5 種數據類型之一，但是當我們想查看某個 key 底層是使用哪種數據結構和編碼來存儲的時候可以使用 OBJECT encoding 命令。

SET string:orderid:10101010 10101010
OK

OBJECT encoding string:orderid:10101010
"int"

SET string:orderid:10101010 "orderid:10101010"
OK

OBJECT encoding string:orderid:10101010
"embstr"

同樣一個 key ，但是由於我們設置的值不同而 redis 選用了不同的內存數據結構和編碼。雖然 redis 提供的 string 數據類型，但是 redis 會自動識別我們 cache 的數據類型是 int 還是 string 。

如果我們設置的是字符串，且這個字符串長度不大於 39 字節那麼將使用 embstr 來編碼，如果大於 39 字節將使用 raw 來編碼。redis 4.0 將這個閥值擴大了 45 個字節。

除了使用 OBJECT encoding 命令外，我們還可以使用 DEBUG OBJECT 命令來查看更多詳細信息。

DEBUG OBJECT string:orderid:10101010
Value at:0x7fd190500210 refcount:1 encoding:int serializedlength:5 lru:6468044 lru_seconds_idle:8

DEBUG OBJECT string:orderid:10101010
Value at:0x7fd19043be60 refcount:1 encoding:embstr serializedlength:17 lru:6465804 lru_seconds_idle:1942

DEBUG OBJECT 能看到這個對象的 refcount 引用計數 、serializedlength 長度 、_lru_secondsidle 時間 ，這些信息決定了這個 key 緩存清除策略。

簡單動態字符串（simple dynamic string）

簡單動態字符串簡稱 SDS ，在 redis 中所有涉及到字符串的地方都是使用 SDS 實現，當然這裏不包括字面量。 SDS 與傳統 C 字符串的區別就是 SDS 是結構化的，它可以高效的處理分配、回收、長度計算等問題。

struct sdshdr {
    unsigned int len;
    unsigned int free;
    char buf[];
};

這是 redis 3.0 版本的 sds.h 頭文件定義，3.0.0 之後變化比較大。len 表示字符串長度，free 表示空間長度，buf 數組表示字符串。

SDS 有很多優點，比如，獲取長度的時間複雜度 O(1) ，不需要遍歷所有 char buf[] 組數，直接返回 len 值。

static inline size_t sdslen(const sds s) {
    struct sdshdr *sh = (void*)(s-(sizeof(struct sdshdr)));
    return sh->len;
}

當然還有空間分配檢查、空間預分配、空間惰性釋放等，這些都是 SDS 結構化字符串帶來的強大的擴展能力。

鏈表（linked list）

鏈表數據結構我們是比較熟悉的，最大的特點就是節點的增、刪非常靈活。redis List 數據類型底層就是基於鏈表來實現。這是 redis 3.0 實現。

typedef struct list {
    listNode *head;
    listNode *tail;
    void *(*dup)(void *ptr);
    void (*free)(void *ptr);
    int (*match)(void *ptr, void *key);
    unsigned long len;
} list;

typedef struct listNode {
    struct listNode *prev;
    struct listNode *next;
    void *value;
} listNode;

在 redis 3.2.0 版本的時候引入了 quicklist 鏈表結構，結合了 linkedlist 和 ziplist 的優勢。

typedef struct quicklist {
    quicklistNode *head;
    quicklistNode *tail;
    unsigned long count;        /* total count of all entries in all ziplists */
    unsigned int len;           /* number of quicklistNodes */
    int fill : 16;              /* fill factor for individual nodes */
    unsigned int compress : 16; /* depth of end nodes not to compress;0=off */
} quicklist;

typedef struct quicklistNode {
    struct quicklistNode *prev;
    struct quicklistNode *next;
    unsigned char *zl;
    unsigned int sz;             /* ziplist size in bytes */
    unsigned int count : 16;     /* count of items in ziplist */
    unsigned int encoding : 2;   /* RAW==1 or LZF==2 */
    unsigned int container : 2;  /* NONE==1 or ZIPLIST==2 */
    unsigned int recompress : 1; /* was this node previous compressed? */
    unsigned int attempted_compress : 1; /* node can't compress; too small */
    unsigned int extra : 10; /* more bits to steal for future usage */
} quicklistNode;

quicklist 提供了靈活性同時也兼顧了 ziplist 的壓縮能力，quicklist->encoding 指定了兩種壓縮算法。 quicklist->compress 表示我們可以進行 quicklist node 的深度壓縮能力。redis 提供了兩個有關於壓縮的配置。

list-max-ziplist-size：ziplist長度控制
list-compress-depth：控制鏈表兩端節點的壓縮個數，越是靠近兩端的節點被訪問的機率越大，所以可以將訪問機率大的節點不壓縮，其他節點進行壓縮

對比 redis 3.2 的 quicklist 與 redis 3.0 ，很明顯 quicklist 提供了更加豐富的壓縮功能。redis 3.0 的版本是每個 listnode 直接緩存值，而 quicklistnode 還有強大的有關於壓縮能力。

LPUSH list:products:mall 100 200 300
(integer) 3

OBJECT encoding list:products:mall
"quicklist"