Redis(開發與運維):41---內存之（內存優化：redisObject對象、縮減鍵值對象、共享對象池、字符串優化、編碼優化、控制鍵的數量）

一、redisObject對象

• 關於redisObject的設計與實現還可以參閱：https://blog.csdn.net/qq_41453285/article/details/103224875
• Redis存儲的所有值對象在內部定義爲redisObject結構體，內部結構如下圖所示：

• Redis存儲的數據都使用redisObject來封裝，包括string、hash、list、 set、zset在內的所有數據類型
• 理解redisObject對內存優化非常有幫助，下 面針對每個字段做詳細說明：
  • type字段：表示當前對象使用的數據類型，Redis主要支持5種數據類型：string、hash、list、set、zset。可以使用type {key}命令查看對象所屬類型，type命令返回的是值對象類型，鍵都是string類型
  • encoding字段：表示Redis內部編碼類型，encoding在Redis內部使用， 代表當前對象內部採用哪種數據結構實現。理解Redis內部編碼方式對於優 化內存非常重要，同一個對象採用不同的編碼實現內存佔用存在明顯差異
  • lru字段：記錄對象最後一次被訪問的時間，當配置了maxmemory和maxmemory-policy=volatile-lru或者allkeys-lru時，用於輔助LRU算法刪除鍵數 據。可以使用object idletime {key}命令在不更新lru字段情況下查看當前鍵的 空閒時間
    • 開發提示：可以使用scan+object idletime命令批量查詢哪些鍵長時間未被訪問，找 出長時間不訪問的鍵進行清理，可降低內存佔用
  • refcount字段：記錄當前對象被引用的次數，用於通過引用次數回收內存，當refcount=0時，可以安全回收當前對象空間。使用object refcount{key} 獲取當前對象引用。當對象爲整數且範圍在[0-9999]時，Redis可以使用共享對象的方式來節省內存。具體細節見之後8.3.3節“共享對象池”部分
  • *ptr字段：與對象的數據內容相關，如果是整數，直接存儲數據；否則表示指向數據的指針。Redis在3.0之後對值對象是字符串且長度<=39字節的 數據，內部編碼爲embstr類型，字符串sds和redisObject一起分配，從而只要 一次內存操作即可
    • 開發提示：高併發寫入場景中，在條件允許的情況下，建議字符串長度控制在39字 節以內，減少創建redisObject內存分配次數，從而提高性能

二、縮減鍵值對象

• 降低Redis內存使用最直接的方式就是縮減鍵（key）和值（value）的長度

縮減key長度

• key長度：如在設計鍵時，在完整描述業務情況下，鍵值越短越好。如 user：{uid}：friends：notify：{fid}可以簡化爲u：{uid}：fs：nt：{fid}

縮減value長度

• 值對象縮減比較複雜，常見需求是把業務對象序列化成二進制數組放入Redis
• 首先應該在業務上精簡業務對象，去掉不必要的屬性避免存儲無效數據。其次在序列化工具選擇上，應該選擇更高效的序列化工具來降低字節數組大小。以Java爲例，內置的序列化方式無論從速度還是壓縮比都不盡如人意，這時可以選擇更高效的序列化工具，如：protostuff、 kryo等
• 下圖是Java常見序列化工具空間壓縮對比：

• 其中java-built-in-serializer表示Java內置序列化方式，更多數據見jvmserializers項目：https://github.com/eishay/jvm-serializers/wiki，其他語言也有各自對應的高效序列化工具
• 值對象除了存儲二進制數據之外，通常還會使用通用格式存儲數據比如：json、xml等作爲字符串存儲在Redis中。這種方式優點是方便調試和跨語言，但是同樣的數據相比字節數組所需的空間更大，在內存緊張的情況下，可以使用通用壓縮算法壓縮json、xml後再存入Redis，從而降低內存佔用，例如使用GZIP壓縮後的json可降低約60%的空間
• 開發提示：當頻繁壓縮解壓json等文本數據時，開發人員需要考慮壓縮速度和計算 開銷成本，這裏推薦使用Google的Snappy壓縮工具，在特定的壓縮率情況下 效率遠遠高於GZIP等傳統壓縮工具，且支持所有主流語言環境

三、共享對象池

• 關於對象的引用計數、共享與回收，還可以參閱：https://blog.csdn.net/qq_41453285/article/details/103236353
• 共享對象池是指Redis內部維護[0-9999]的整數對象池。創建大量的整數 類型redisObject存在內存開銷，每個redisObject內部結構至少佔16字節，甚 至超過了整數自身空間消耗。所以Redis內存維護一個[0-9999]的整數對象池，用於節約內存。除了整數值對象，其他類型如list、hash、set、zset內部 元素也可以使用整數對象池。因此開發中在滿足需求的前提下，儘量使用整數對象以節省內存

查看對象引用數

• 整數對象池在Redis中通過變量REDIS_SHARED_INTEGERS定義，不能通過配置修改
• 可以通過object refcount命令查看對象引用數驗證是否啓用整數對象池技術
• 演示案例如下：

• 設置鍵foo等於100時，直接使用共享池內整數對象，因此引用數是2， 再設置鍵bar等於100時，引用數又變爲3，如下圖所示

內存優化效果測試

• 使用整數對象池究竟能降低多少內存？讓我們通過測試來對比對象池的內存優化效果，如下圖所示：

• 使用共享對象池後，相同的數據內存使用降低30%以上。可見當數據大 量使用[0-9999]的整數時，共享對象池可以節約大量內存
• 備註：本文所有測試環境都保持一致，信息如下：
  • 服務器信息：cpu=Intel-Xeon [email protected] memory=32GB
  • Redis版本：Redis server v=3.0.7sha=00000000：0malloc=jemalloc3.6.0bits=64

maxmemory參數和LRU淘汰策略對共享對象池的影響

• 需要注意的是對象池並不是只要存儲[0-9999]的整數就可以工作。當設置maxmemory並啓用LRU相關淘汰策略如volatile-lru，allkeys-lru時，Redis禁止使用共享對象池
• 關於maxmemory和LRU淘汰策略見前一篇文章：https://blog.csdn.net/qq_41453285/article/details/106199033
• 測試命令如下：

set key:1 99

object refcount key:1    #引用計數爲2

config set maxmemory-policy volatile-lru #開啓LRU淘汰策略

set key:2 99

object refcount key:2    #使用了對象共享，引用計數爲3

config set maxmemory 1GB   #設置最大可用內存

set key:3 99

object refcount key:3    #未使用對象共享，引用數爲1

config set maxmemory-policy valatile-ttl #設置非LRU淘汰策略

set key:4 99

object refcount key:4    #又開始使用對象對象，引用計數爲4

• 爲什麼開啓maxmemory和LRU淘汰策略後對象池無效？
  • LRU算法需要獲取對象最後被訪問時間，以便淘汰最長未訪問數據，每個對象最後訪問時間存儲在redisObject對象的lru字段。對象共享意味着多個引用共享同一個redisObject，這時lru字段也會被共享，導致無法獲取每個對象的最後訪問時間
  • 如果沒有設置maxmemory，直到內存被用盡Redis也不會觸發內存回收，所以共享對象池可以正常工作
• 綜上所述，共享對象池與maxmemory+LRU策略衝突，使用時需要注意

• 對於ziplist編碼的值對象，即使內部數據爲整數也無法使用共享對象池。因爲ziplist使用壓縮且內存連續的結構，對象共享判斷成本過高，ziplist 編碼細節後面內容詳細說明

爲什麼只有整數對象池？

• 首先整數對象池複用的機率最大，其次對象共享的一個關鍵操作就是判斷相等性
• Redis之所以只有整數對象池，是因爲：
  • 整數比較算法時間複雜度爲O(1)，只保留一萬個整數爲了防止對象池浪費
  • 如果是字符串判斷相等性，時間複雜度變爲O(n)，特別是長字符串更消耗性能（浮點數在 Redis內部使用字符串存儲）
  • 對於更復雜的數據結構如hash、list等，相等性判斷需要O()。對於單線程的Redis來說，這樣的開銷顯然不合理，因 此Redis只保留整數共享對象池。

四、字符串優化

• 關於redis的動態字符串的設計與實現可以參閱：https://blog.csdn.net/qq_41453285/article/details/103219345
• 字符串對象是Redis內部最常用的數據類型。所有的鍵都是字符串類型，值對象數據除了整數之外都使用字符串存儲。比如執行命令：lpush cache:type "redis" "memcache" "tair" "levelDB"，Redis首先創建"cache:type"鍵字符串，然後創建鏈表對象，鏈表對象內再包含四個字符串對象，排除 Redis內部用到的字符串對象之外至少創建5個字符串對象。可見字符串對象 在Redis內部使用非常廣泛，因此深刻理解Redis字符串對於內存優化非常有 幫助

①字符串結構

• Redis沒有采用原生C語言的字符串類型而是自己實現了字符串結構，內部簡單動態字符串（simple dynamic string，SDS）。結構如下圖所示

• Redis自身實現的字符串結構有如下特點：
  • O(1)時間複雜度獲取：字符串長度、已用長度、未用長度
  • 可用於保存字節數組，支持安全的二進制數據存儲
  • 內部實現空間預分配機制，降低內存再分配次數
  • 惰性刪除機制，字符串縮減後的空間不釋放，作爲預分配空間保留

預分配機制（小心內存浪費）

• 因爲字符串（SDS）存在預分配機制，日常開發中要小心預分配帶來的內存浪費
• 例如下圖的測試用例：

• 從測試數據可以看出，同樣的數據追加後內存消耗非常嚴重，下面我們 結合圖來分析這一現象。階段1每個字符串對象空間佔用如下圖所示

• 階段1插入新的字符串後，free字段保留空間爲0，總佔用空間=實際佔 用空間+1字節，最後1字節保存‘\0’標示結尾，這裏忽略int類型len和free字段 消耗的8字節。在階段1原有字符串上追加60字節數據空間佔用如下圖所示

• 加操作後字符串對象預分配了一倍容量作爲預留空間，而且大量追加 操作需要內存重新分配，造成內存碎片率（mem_fragmentation_ratio）上 升。直接插入與階段2相同數據的空間佔用，如下圖所示

• 階段3直接插入同等數據後，相比階段2節省了每個字符串對象預分配的空間，同時降低了碎片率
• 字符串之所以採用預分配的方式是防止修改操作需要不斷重分配內存和字節數據拷貝。但同樣也會造成內存的浪費。字符串預分配每次並不都是翻倍擴容，空間預分配規則如下：
  • 1）第一次創建len屬性等於數據實際大小，free等於0，不做預分配
  • 2）修改後如果已有free空間不夠且數據小於1M，每次預分配一倍容 量。如原有len=60byte，free=0，再追加60byte，預分配120byte，總佔用空 間：60byte+60byte+120byte+1byte
  • 3）修改後如果已有free空間不夠且數據大於1MB，每次預分配1MB數 據。如原有len=30MB，free=0，當再追加100byte，預分配1MB，總佔用空 間：1MB+100byte+1MB+1byte
• 開發提示：儘量減少字符串頻繁修改操作如append、setrange，改爲直接使用set修改字符串，降低預分配帶來的內存浪費和內存碎片化

字符串重構

• 字符串重構：指不一定把每份數據作爲字符串整體存儲，像json這樣的數據可以使用hash結構，使用二級結構存儲也能幫我們節省內存。同時可以使用hmget、hmset命令支持字段的部分讀取修改，而不用每次整體存取
• 例如現在有下面的json數據：

{
    "vid": "413368768",
    "title": "搜狐屌絲男士",
    "videoAlbumPic":"http://photocdn.sohu.com/60160518/vrsa_ver8400079_ae433_pic26.jpg",
    "pid": "6494271",
    "type": "1024",
    "playlist": "6494271",
    "playTime": "468"
}

• 分別使用字符串和hash結構測試內存表現，如下圖所示：

• 根據測試結構，第一次默認配置下使用hash類型，內存消耗不但沒有降低反而比字符串存儲多出2倍，而調整hash-max-ziplist-value=66之後內存降 低爲535.60M。因爲json的videoAlbumPic屬性長度是65，而hash-max-ziplistvalue默認值是64，Redis採用hashtable編碼方式，反而消耗了大量內存。調整配置後hash類型內部編碼方式變爲ziplist，相比字符串更省內存且支持屬性的部分操作。下面將具體介紹ziplist編碼優化細節

五、編碼優化

什麼是編碼？

• Redis對外提供了string、list、hash、set、zet等類型，但是Redis內部針對不同類型存在編碼的概念，所謂編碼就是具體使用哪種底層數據結構來實現。編碼不同將直接影響數據的內存佔用和讀寫效率
• 使用下面的命令獲取編碼類型。如下所示：

object encoding {key};

• Redis針對每種數據類型（type）可以採用至少兩種編碼方式來實現，下圖表示type和encoding的對應關係

• Redis爲什麼對一種數據結構實現多種編碼方式？主要原因是：Redis作者想通過不同編碼實現效率和空間的平衡。比如當我們的存儲只有10個元素的列表，當使用雙向鏈表數據結構時，必然需要維護大量的內部字段如每個元素需要：前置指針，後置指針，數據指針等，造成空間浪費，如果採用連續內存結構的壓縮列表（ziplist），將會節省大量內存，而由於數據長度較小，存取操作時間複雜度即使爲O()性能也可 滿足需求

控制編碼類型

• 編碼類型轉換在Redis寫入數據時自動完成，這個轉換過程是不可逆的，轉換規則只能從小內存編碼向大內存編碼轉換
• 例如：

• 以上命令體現了list類型編碼的轉換過程，其中Redis之所以不支持編碼回退，主要是數據增刪頻繁時，數據向壓縮編碼轉換非常消耗CPU，得不償失
• 以上示例用到了list-max-ziplist-entries參數，這個參數用來決定列表長度在多少範圍內使用ziplist編碼。當然還有其他參數控制各種數據類型的編碼，如下圖所示

• 掌握編碼轉換機制，對我們通過編碼來優化內存使用非常有幫助。下面以hash類型爲例，介紹編碼轉換的運行流程，如下圖所示：

• 理解編碼轉換流程和相關配置之後，可以使用config set命令設置編碼相關參數來滿足使用壓縮編碼的條件。對於已經採用非壓縮編碼類型的數據如hashtable、linkedlist等，設置參數後即使數據滿足壓縮編碼條件，Redis也不會做轉換，需要重啓Redis重新加載數據才能完成轉換

ziplist編碼

• 關於ziplist的設計與實現，還可以參閱：https://blog.csdn.net/qq_41453285/article/details/103223994
• ziplist編碼主要目的是爲了節約內存，因此所有數據都是採用線性連續的內存結構
• ziplist編碼是應用範圍最廣的一種，可以分別作爲hash、list、 zset類型的底層數據結構實現
• 它的內部結構類似這樣：
  • <zlbytes><zltail><zllen><entry-1><entry-2><...><entry-n>
  • 一個ziplist可以包含多個entry（元素），每個entry保存具體的數據 （整數或者字節數組），內部結構如下圖所示

• ziplist結構字段含義：
  • zlbytes：記錄整個壓縮列表所佔字節長度，方便重新調整ziplist空間。類型是int-32，長度爲4字節
  • zltail：記錄距離尾節點的偏移量，方便尾節點彈出操作。類型是int32，長度爲4字節
  • zllen：記錄壓縮鏈表節點數量，當長度超過216-2時需要遍歷整個列 表獲取長度，一般很少見。類型是int-16，長度爲2字節。
  • entry：記錄具體的節點，長度根據實際存儲的數據而定
    • prev_entry_bytes_length：記錄前一個節點所佔空間，用於快速定位 上一個節點，可實現列表反向迭代。
    • encoding：標示當前節點編碼和長度，前兩位表示編碼類型：字符 串/整數，其餘位表示數據長度
    • contents：保存節點的值，針對實際數據長度做內存佔用優化。
  • zlend：記錄列表結尾，佔用一個字節
• 根據以上對ziplist字段說明，可以分析出該數據結構特點如下：
  • 內部表現爲數據緊湊排列的一塊連續內存數組
  • 可以模擬雙向鏈表結構，以O(1)時間複雜度入隊和出隊
  • 新增刪除操作涉及內存重新分配或釋放，加大了操作的複雜性
  • 讀寫操作涉及複雜的指針移動，最壞時間複雜度爲O（n2）
  • 適合存儲小對象和長度有限的數據。
• 下面通過測試展示ziplist編碼在不同類型中內存和速度的表現，如下圖所示：

• 測試數據採用100W個36字節數據，劃分爲1000個鍵，每個類型長度統 一爲1000。從測試結果可以看出：
  • 使用ziplist可以分別作爲hash、list、zset數據類型實現
  • 使用ziplist編碼類型可以大幅降低內存佔用
  • ziplist實現的數據類型相比原生結構，命令操作更加耗時，不同類型耗時排序：list < hash < zset
• ziplist壓縮編碼的性能表現跟值長度和元素個數密切相關，正因爲如此Redis提供了{type}-max-ziplist-value和{type}-max-ziplist-entries相關參數來做控制ziplist編碼轉換。最後再次強調使用ziplist壓縮編碼的原則：追求空間和時間的平衡
• 開發提示：
  • 針對性能要求較高的場景使用ziplist，建議長度不要超過1000，每個元 素大小控制在512字節以內
  • 命令平均耗時使用info Commandstats命令獲取，包含每個命令調用次 數、總耗時、平均耗時，單位爲微秒

intset編碼

• intset編碼的設計與實現還可以參閱：https://blog.csdn.net/qq_41453285/article/details/103223756
• intset編碼是集合（set）類型編碼的一種，內部表現爲存儲有序、不重複的整數集。當集合只包含整數且長度不超過set-max-intset-entries配置時被啓用
• 執行以下命令查看intset表現：

• 以上命令可以看出intset對寫入整數進行排序，通過O(logn)時間複雜度實現查找和去重操作
• intset編碼結構如下圖所示：

• intset的字段結構含義：
  • encoding：整數表示類型，根據集合內最長整數值確定類型，整數類型劃分爲三種：int-16、int-32、int-64
  • length：表示集合元素個數
  • contents：整數數組，按從小到大順序保存
• intset保存的整數類型根據長度劃分，當保存的整數超出當前類型時， 將會觸發自動升級操作且升級後不再做回退。升級操作將會導致重新申請內存空間，把原有數據按轉換類型後拷貝到新數組
• 開發提示：使用intset編碼的集合時，儘量保持整數範圍一致，如都在int-16範圍 內。防止個別大整數觸發集合升級操作，產生內存浪費
• 下面通過測試查看ziplist編碼的集合內存和速度表現，如下圖所示：

• 根據以上測試結果發現：
  • intset表現非常好，同樣的數據內存佔用只有不到hashtable編碼的十分之一
  • intset數據結構插入命令複雜度爲O(n)，查詢命令爲O(logn)，由於整數佔用空間非常小，所以在集合長度可控的基礎上，寫入命令執行速度也會非常快，因此當使用整數集合時儘量使用 intset編碼
  • 上圖測試第三行把ziplist-hash類型也放入其中，主要因爲intset 編碼必須存儲整數，當集合內保存非整數數據時，無法使用intset實現內存優化。這時可以使用ziplist-hash類型對象模擬集合類型，hash的field當作集 閤中的元素，value設置爲1字節佔位符即可。使用ziplist編碼的hash類型依然 比使用hashtable編碼的集合節省大量內存

六、控制鍵的數量

• 當使用Redis存儲大量數據時，通常會存在大量鍵，過多的鍵同樣會消耗大量內存。Redis本質是一個數據結構服務器，它爲我們提供多種數據結構，如hash、list、set、zset等。使用Redis時不要進入一個誤區，大量使用get/set這樣的API，把Redis當成Memcached使用。對於存儲相同的數據內容利用Redis的數據結構降低外層鍵的數量，也可以節省大量內存
• 如下圖所示，通過在客戶端預估鍵規模，把大量鍵分組映射到多個hash結構中降低鍵的數量：

• hash結構降低鍵數量分析：
  • 根據鍵規模在客戶端通過分組映射到一組hash對象中，如存在100萬個 鍵，可以映射到1000個hash中，每個hash保存1000個元素
  • hash的field可用於記錄原始key字符串，方便哈希查找
  • hash的value保存原始值對象，確保不要超過hash-max-ziplist-value限 制
• 下面測試這種優化技巧的內存表現，如下圖所示：

• 通過這個測試數據，可以說明：
  • 同樣的數據使用ziplist編碼的hash類型存儲比string類型節約內存
  • 節省內存量隨着value空間的減少越來越明顯
  • hash-ziplist類型比string類型寫入耗時，但隨着value空間的減少，耗時逐漸降低
• 使用hash重構後節省內存量效果非常明顯，特別對於存儲小對象的場景，內存只有不到原來的1/5。下面分析這種內存優化技巧的關鍵點：
  • hash類型節省內存的原理是使用ziplist編碼，如果使用hashtable編碼 方式反而會增加內存消耗
  • ziplist長度需要控制在1000以內，否則由於存取操作時間複雜度在 O(n)到O()之間，長列表會導致CPU消耗嚴重，得不償失。
  • ziplist適合存儲小對象，對於大對象不但內存優化效果不明顯還會增 加命令操作耗時。
  • 需要預估鍵的規模，從而確定每個hash結構需要存儲的元素數量。
  • 根據hash長度和元素大小，調整hash-max-ziplist-entries和hash-maxziplist-value參數，確保hash類型使用ziplist編碼。
• 關於hash鍵和field鍵的設計：
  • 當鍵離散度較高時，可以按字符串位截取，把後三位作爲哈希的 field，之前部分作爲哈希的鍵。如：key=1948480哈希key=group：hash： 1948，哈希field=480。 2）當鍵離散度較低時，可以使用哈希算法打散鍵，如：使用 crc32（key）&10000函數把所有的鍵映射到“0-9999”整數範圍內，哈希field 存儲鍵的原始值。 3）儘量減少hash鍵和field的長度，如使用部分鍵內容。
• 使用hash結構控制鍵的規模雖然可以大幅降低內存，但同樣會帶來問題，需要提前做好規避處理。如下所示：
  • 客戶端需要預估鍵的規模並設計hash分組規則，加重客戶端開發成本
  • hash重構後所有的鍵無法再使用超時（expire）和LRU淘汰機制自動刪 除，需要手動維護刪除
  • 對於大對象，如1KB以上的對象，使用hash-ziplist結構控制鍵數量反而得不償失
• 不過瑕不掩瑜，對於大量小對象的存儲場景，非常適合使用ziplist編碼的hash類型控制鍵的規模來降低內存
• 開發提示：使用ziplist+hash優化keys後，如果想使用超時刪除功能，開發人員可以 存儲每個對象寫入的時間，再通過定時任務使用hscan命令掃描數據，找出 hash內超時的數據項刪除即可

七、總結

• 本文主要講解Redis內存優化技巧，Redis的數據特性是“all in memory”， 優化內存將變得非常重要
• 對於內存優化建議讀者先要掌握Redis內存存儲的特性比如字符串、壓縮編碼、整數集合等，再根據數據規模和所用命令需求去調整，從而達到空間和效率的最佳平衡。建議使用Redis存儲大量數據時，把內存優化環節加入到前期設計階段，否則數據大幅增長後，開發人員需要面對重新優化內存所帶來開發和數據遷移的雙重成本
• 當Redis內存不足時，首先考慮的問題不是加機器做水平擴展，應該先嚐試做內存優化，當遇到瓶頸時，再去考慮水平擴展。即使對於集羣化方案，垂直層面優化也同樣重要，避免不必要的資源浪費和集羣化後的管理成本