Redis 作為記憶體資料函式庫，其效能與記憶體使用息息相關。本文將介紹幾種降低 Redis 記憶體佔用的策略，包含利用 ziplist 和 intset 等緊湊資料結構、Sharding 技術，以及針對固定長度資料的封裝技巧。這些方法能有效減少記憶體開銷，提升 Redis 執行效率。同時，文章也將分析大型 ziplist 和 intset 對效能的影響，並提供相關組態建議，讓開發者能根據應用需求進行調校。
import redis
import time
def long_ziplist_performance(conn, key, length, passes, psize):
conn.delete(key)
conn.rpush(key, *range(length))
pipeline = conn.pipeline(False)
t = time.time()
for p in range(passes):
for pi in range(psize):
pipeline.rpoplpush(key, key)
pipeline.execute()
return (passes * psize) / (time.time() - t or 0.001)
# 連線到 Redis
conn = redis.Redis(host='localhost', port=6379, db=0)
# 測試不同長度的 ziplist 效能
lengths = [1, 100, 1000, 5000, 50000, 100000]
for length in lengths:
performance = long_ziplist_performance(conn, 'ziplist_test', length, 10, 1000)
print(f"Ziplist 長度: {length}, 效能: {performance:.2f} ops/sec")
減少Redis的記憶體使用
在這一章中，我們將介紹三種重要的最佳化方法來幫助降低Redis的記憶體使用率。透過減少Redis使用的記憶體，可以減少建立或載入快照、重寫或載入僅追加檔案的時間，降低從伺服器的同步時間，並在不增加硬體的情況下在Redis中儲存更多的資料。
簡短的資料結構
第一種最佳化Redis記憶體使用的方法很簡單：使用簡短的資料結構。對於LIST、SET、HASH和ZSET，Redis提供了一組組態選項，允許Redis以更節省空間的方式儲存簡短的資料結構。在本文中，我們將討論這些組態選項，展示如何驗證是否獲得了這些最佳化，並討論使用簡短資料結構的一些缺點。
Ziplist表示法
要了解為什麼Ziplist可能更有效率，我們只需要看看我們最簡單的資料結構——LIST。在典型的雙向連結串列中，我們有稱為節點的結構，它們代表列表中的每個值。這些節點中的每一個都有指向列表中前一個和下一個節點的指標，以及指向節點中的字串的指標。每個字串值實際上儲存為三個部分：表示長度的整數、表示剩餘空閒位元組的整數，以及字串本身後面跟著一個空字元。
# 檢查一個狀態訊息是否在特定的經緯度範圍內
def check_location(box, lat, lon):
if (box[1] <= lat <= box[3] and
box[0] <= lon <= box[2]):
return True
return False
內容解密：
這段程式碼定義了一個名為check_location的函式，用於檢查一個給定的經緯度位置是否在一個指定的矩形區域內。該函式接受三個引數：box（一個包含四個元素的列表或元組，代表最小經度、最小緯度、最大經度和最大緯度）、lat（緯度）和lon（經度）。函式內部首先檢查給定的緯度是否在box指定的最小和最大緯度之間，以及經度是否在最小和最大經度之間。如果兩者都滿足，函式傳回True，否則傳回False。
圖9.1 LIST在Redis中的儲存方式
在32位元平台上，每個字串的儲存都需要三個指標、兩個整數（長度和剩餘位元組數），以及字串本身和一個額外的位元組。這意味著儲存三個字元的字串實際上需要21位元的開銷。
最佳化Redis記憶體使用的三種方法
- 簡短的資料結構：使用Redis的組態選項來最佳化簡短的LIST、SET、HASH和ZSET的儲存。
- 分片結構：透過將大結構分成小塊來減少記憶體使用。
- 封裝固定長度的資料：將多個固定長度的資料封裝到一個STRING中以節省記憶體。
Sharding技術
Sharding是一種透過將資料分散到多個Redis例項中來提高可擴充套件性和減少單個例項記憶體使用的方法。在本章中，我們主要關注如何使用Sharding來減少單機上的記憶體使用。在第10章中，我們將進一步討論如何使用類別似的技術來提高跨多個Redis伺服器的讀取吞吐量、寫入吞吐量和記憶體分割槽。
封裝位元和位元組
對於某些型別的資料，將多個固定長度的資料封裝到一個STRING中可以進一步減少記憶體使用。這種方法需要仔細設計資料的儲存和檢索邏輯，以確保資料的正確性和存取效率。
未來方向
在接下來的章節（第10章和第11章）中，我們將進一步探討如何提高Redis的讀寫效能、如何使用Lua指令碼簡化應用程式並提高可擴充套件性。這些技術將幫助我們構建更高效、更可擴充套件的Redis應用程式。
graph LR;
A[開始] --> B{檢查經緯度};
B -->|是| C[傳回True];
B -->|否| D[傳回False];
C --> E[結束];
D --> E;
圖表翻譯：
此圖表示了一個簡單的流程圖，展示了檢查一個給定的經緯度位置是否在指定區域內的邏輯流程。首先，流程開始於檢查經緯度是否在給定的box範圍內。如果是，則傳回True；如果不是，則傳回False。最終，無論結果如何，流程都會結束。
Redis 記憶體使用最佳化：緊湊資料結構的應用
Redis 是一種高效能的鍵值資料函式庫，其效能優勢主要來自於資料儲存在記憶體中。然而，隨著資料量的增長，記憶體使用量也會相應增加。因此，最佳化 Redis 的記憶體使用是至關重要的。本篇文章將探討 Redis 中的兩種緊湊資料結構：ziplist 和 intset，以及如何利用它們來減少記憶體使用。
9.1.1 ziplist 編碼：減少 LIST、HASH 和 ZSET 的記憶體使用
在 Redis 中，LIST、HASH 和 ZSET 是三種常用的資料結構。然而，這些資料結構在預設情況下會使用較多的記憶體來儲存資料。為了減少記憶體使用，Redis 引入了 ziplist 這種緊湊的資料結構。
ziplist 的結構
ziplist 是一種連續記憶體區塊，用於儲存多個元素。它的結構如下：
- 每個元素由三個部分組成：前一個元素的長度、當前元素的長度以及元素資料本身。
- 前一個元素的長度用於支援雙向遍歷。
- 當前元素的長度和元素資料本身則用於儲存實際的資料。
透過這種結構，ziplist 可以顯著減少記憶體使用。以儲存四個字串元素（‘a’、‘b’、‘c’、’d’）為例，ziplist 只需要 2 位元組的額外開銷，而傳統的連結串列結構則需要 21 位元組的額外開銷。
使用 ziplist 編碼
要使用 ziplist 編碼，需要組態相關的引數。Redis 提供了六個組態選項來控制何時使用 ziplist 編碼：
list-max-ziplist-entries 512
list-max-ziplist-value 64
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
這些組態選項控制著 LIST、HASH 和 ZSET 何時會被編碼為 ziplist。當資料專案的數量或單個元素的大小超過組態的限制時，Redis 會將資料結構轉換為非 ziplist 結構，從而增加記憶體使用。
驗證 ziplist 編碼
可以使用 DEBUG OBJECT 命令來檢查一個鍵是否使用了 ziplist 編碼。例如：
>>> conn.rpush('test', 'a', 'b', 'c', 'd')
4
>>> conn.debug_object('test')
{'encoding': 'ziplist', 'refcount': 1, 'lru_seconds_idle': 20,
'lru': 274841, 'at': '0xb6c9f120', 'serializedlength': 24,
'type': 'Value'}
程式碼範例與解析
以下是一個使用 Python 與 Redis 互動的範例，展示如何檢查一個 LIST 是否使用了 ziplist 編碼：
import redis
# 連線到 Redis
conn = redis.Redis(host='localhost', port=6379, db=0)
# 推播元素到 LIST
conn.rpush('test', 'a', 'b', 'c', 'd')
# 檢查物件的編碼方式
debug_info = conn.debug_object('test')
print(debug_info)
# 輸出結果應該包含 'encoding': 'ziplist'
#### 內容解密：
此範例程式碼展示瞭如何使用 Python 的 Redis 客戶端函式庫與 Redis 伺服器互動。首先，我們連線到本地的 Redis 伺服器，然後使用 rpush 命令將四個元素推播到名為 ’test’ 的 LIST 中。接著，我們使用 debug_object 命令來檢查 ’test’ 鍵的屬性，包括其編碼方式。輸出結果中的 ’encoding’ 欄位如果為 ‘ziplist’，則表示該 LIST 使用了 ziplist 編碼。
9.1.2 intset 編碼：減少 SET 的記憶體使用
除了 ziplist 之外，Redis 還提供了一種名為 intset 的緊湊資料結構，用於儲存 SET。intset 是一種排序好的整數陣列，可以快速執行 SET 操作。
intset 的使用條件
要使用 intset 編碼，SET 中的所有元素必須是整數，並且數量不能超過組態的限制：
set-max-intset-entries 512
intset 的優點
- 低記憶體開銷：intset 使用連續的記憶體區塊來儲存整數陣列。
- 高效的 SET 操作：由於 intset 是排序好的，因此可以快速執行 SET 操作，如新增、刪除和檢查元素是否存在。
程式碼範例與解析
以下是一個使用 Python 檢查 SET 是否使用 intset 編碼的範例：
import redis
# 連線到 Redis
conn = redis.Redis(host='localhost', port=6379, db=0)
# 新增整數元素到 SET
conn.sadd('test_set', 1, 2, 3, 4)
# 檢查 SET 的編碼方式
debug_info = conn.debug_object('test_set')
print(debug_info)
# 如果 SET 使用了 intset 編碼，則 'encoding' 欄位應該為 'intset'
#### 內容解密：
此範例展示瞭如何使用 Python 的 Redis 客戶端函式庫來檢查一個 SET 是否使用了 intset 編碼。首先，我們連線到 Redis 伺服器，然後使用 sadd 命令將四個整數元素新增到名為 ’test_set’ 的 SET 中。接著，我們使用 debug_object 命令來檢查 ’test_set’ 鍵的屬性。如果 ’encoding’ 欄位為 ‘intset’，則表示該 SET 使用了 intset 編碼。
隨著 Redis 版本的不斷更新，未來可能會出現更多最佳化的資料結構和組態選項。開發者應該持續關注 Redis 的最新發展，並根據實際需求調整組態和資料結構，以保持最佳的效能和記憶體使用效率。
graph LR
A[開始] --> B{是否使用 ziplist 編碼？}
B -->|是| C[使用 ziplist 編碼]
B -->|否| D[使用傳統資料結構]
C --> E[檢查組態引數]
E --> F[list-max-ziplist-entries]
E --> G[list-max-ziplist-value]
F --> H[根據引數調整]
G --> H
圖表翻譯：
此圖表展示了 Redis 在儲存資料時，根據組態引數決定是否使用 ziplist 編碼的流程。首先，Redis 會檢查是否滿足使用 ziplist 編碼的條件。如果滿足，則使用 ziplist 編碼；否則，使用傳統的資料結構。接著，Redis 會根據組態引數（如 list-max-ziplist-entries 和 list-max-ziplist-value）來調整 ziplist 的使用。最終，根據這些引數的設定，Redis 會決定是否使用 ziplist 編碼或傳統資料結構來儲存資料。
透過上述分析和範例，我們可以看到 Redis 在記憶體使用最佳化方面的強大能力。透過合理使用 ziplist 和 intset 等緊湊資料結構，可以顯著降低 Redis 的記憶體消耗，提高系統的整體效能。未來，隨著 Redis 的不斷發展，我們可以期待更多最佳化的資料結構和組態選項的出現。
Redis 長度壓縮列表與整數集合的效能問題分析
在 Redis 中，為了節省記憶體空間，某些資料結構（如 LIST 和 SET）在特定條件下會被編碼為緊湊的 ziplist 或 intset。然而，當這些結構增長到超出特定限制時，它們會被轉換為更通用的結構型別（如 linked list 或 hash table）。本章節將探討使用長 ziplist 和 intset 時可能出現的效能問題。
長度壓縮列表（ziplist）與效能問題
ziplist 是 Redis 用於儲存小型 LIST 和 HASH 等資料結構的緊湊編碼方式。當 LIST 中的元素數量超過 list-max-ziplist-entries 組態的限制時，Redis 會將 ziplist 轉換為 linked list。雖然 ziplist 可以節省記憶體，但在處理大型資料時可能會導致效能下降。
效能測試與分析
為了測試長 ziplist 的效能問題，我們編寫了一個測試函式 long_ziplist_performance，該函式建立一個指定長度的 LIST，並重複執行 RPOPLPUSH 命令將元素從 LIST 的右端移動到左端。透過計算每秒執行的操作次數，我們可以評估不同大小的 ziplist 編碼 LIST 的效能表現。
def long_ziplist_performance(conn, key, length, passes, psize):
conn.delete(key)
conn.rpush(key, *range(length))
pipeline = conn.pipeline(False)
t = time.time()
for p in range(passes):
for pi in range(psize):
pipeline.rpoplpush(key, key)
pipeline.execute()
return (passes * psize) / (time.time() - t or 0.001)
測試結果
透過執行 long_ziplist_performance 函式，我們得到了以下測試結果：
- 當 LIST 長度為 1、100、1000 時，Redis 仍能保持每秒超過 49,000 次的操作。
- 當 LIST 長度增長到 5,000 時，效能開始下降，每秒約 43,424 次操作。
- 當 LIST 長度達到 50,000 時，效能顯著下降，每秒約 16,695 次操作。
- 當 LIST 長度達到 100,000 時，ziplist 編碼的 LIST 幾乎無法使用，每秒僅約 553 次操作。
#### 內容解密：
上述測試結果表明，隨著 ziplist 編碼的 LIST 增長，其效能會逐漸下降。這主要是因為在執行 RPOPLPUSH 命令時，Redis 需要對 ziplist 中的元素進行重新排列，這涉及到記憶體資料的移動，進而導致效能下降。
整數集合（intset）與效能問題
intset 是 Redis 用於儲存小型 SET 的緊湊編碼方式。當 SET 中的元素數量超過 set-max-intset-entries 組態的限制時，Redis 會將 intset 轉換為 hash table。與 ziplist 類別似，intset 在處理大型資料時也可能出現效能問題。
轉換過程
當我們向一個 intset 編碼的 SET 中新增元素時，Redis 會檢查 SET 的大小是否超過組態的限制。如果超過，Redis 會將 intset 轉換為 hash table 編碼。
>>> conn.sadd('set-object', *range(500))
500
>>> conn.debug_object('set-object')
{'encoding': 'intset', ...}
>>> conn.sadd('set-object', *range(500, 1000))
500
>>> conn.debug_object('set-object')
{'encoding': 'hashtable', ...}
#### 內容解密：
上述範例展示了當 SET 中的元素數量從 500 增長到 1000 時，Redis 將 intset 編碼轉換為 hash table 編碼的過程。這是因為預設的 set-max-intset-entries 組態限制了 intset 中元素的最大數量。
Redis效能最佳化建議
- 適當組態 ziplist 和 intset 限制：根據實際應用場景，合理組態
list-max-ziplist-entries和set-max-intset-entries，避免不必要的效能下降。 - 監控資料結構大小：定期檢查 Redis 中 LIST 和 SET 的大小，確保它們不會過度增長而影響效能。
- 使用適當的資料結構：根據資料特性和操作需求，選擇合適的 Redis 資料結構，以最大化效能。
Redis 資料結構轉換流程
graph LR
A[開始] --> B{是否超過 ziplist/intset 限制?}
B -->|是| C[轉換為 linked list/hash table]
B -->|否| D[保持 ziplist/intset 編碼]
C --> E[結束]
D --> E
圖表翻譯：
此圖表展示了 Redis 中 ziplist 和 intset 資料結構的轉換流程。當資料量超過組態的限制時，Redis 會將這些緊湊編碼的資料結構轉換為更通用的結構，以保持效能。
