小對象壓縮

• Redis是一種內存數據庫，內存是計算機中一種比較寶貴的資源，如果我們不注意節約，Redis很可能出現內存不足，最終導致崩潰。Redis為了優化數據結構的內存占用，增加了非常多的優化點，這些優化也是犧牲代碼的可讀性為代價，但是對于解決的內存問題來說是非常值得的，尤其是對于Redis這種內存數據庫

32bit VS 64bit

• Redis如果使用32bit版本，內部存儲所有數據結構使用的指針空間占用會少一半,如果Redis使用內存不會超過2^32 = 4GB，可以考慮32bit進行編譯，能節約大量內存。4GB容量對小站點來說戳戳由于。不足可以增加節點
  • 指針是尋址，存儲的是地址信息，32bit系統能表示的總大小是2^32 位，所以指針能表示的尋址最大值也就是 2 ^32，同理64bit 系統占用2 ^ 64

小對象壓縮

• 如果Redis內部管理的集合數據結構很小，他會使用緊湊型存儲形式壓縮存儲，只有當集合數據達到一定量級的時候，Redis才會將數據存儲稱為正常我們熟知的狀態。
• 例如HashMap本來是二維結構，如果內部元素少，使用數組+鏈表的形式反而浪費空間，因為指針占用空間比數據還要多，還不如使用一維數組進行存儲，查找時候元素少，遍歷也快，只不過代碼略復雜而已。以下案例用一維數組存儲HashMap的CUD

public class ArrayMap<K, V> {private List<K> keys = new ArrayList<>();private List<V> values = new ArrayList<>();public V put(K k, V v){for (int i = 0; i < keys.size(); i++) {if(keys.get(i).equals(k)){V oldv = values.get(i);values.set(i, v);return oldv;}}keys.add(k);values.add(v);return null;}public V get(K k){for (int i = 0; i < keys.size(); i++) {if(keys.get(i).equals(k)){return values.get(i);}}return null;}public V delete(K k){for (int i = 0; i < keys.size(); i++) {if(keys.get(i).equals(k)){keys.remove(k);return values.remove(i);}}return null;} }

• 同樣Redis的ziplist是一個緊湊型的字節數組結構，如下圖中所示，每個元素都是緊密相連，中間沒有指針用來尋址操作，通過三個全局指針來完成邏輯處理，zlbytes， zltail和zlend。如下：
  
• 如果如上結果存儲的是hash結構，那么key和value作為兩個entry，被相鄰的兩個entry存儲，通過如下方式驗證，輸出類型是ziplist：

新docker-redis:0>hset hello a 1 "1" 新docker-redis:0>hset hello b 2 "1" 新docker-redis:0>object encoding hello "ziplist"

• 如果存儲的類型是zset，那么value和score會作為兩個entry被相鄰存儲

新docker-redis:0>zadd world 1 a "1" 新docker-redis:0>zadd world 2 b "1" 新docker-redis:0>object encoding world "ziplist"

• 整數的存儲Redis有一個叫intset的整數數組結構，用于存放元素都是整數且元素個數較少的set集合。
• 如果整數可以用uint16標識，那么intset的元素就是16位的數組，如果新加入的整數超過uint16，那么久用uint32，還不夠則用uint64，Redis支持set集合動態從unit16升級到unit32,在到unit64

• 如下代碼，我們在set集合中存儲的數字，他的類型就是intset

新docker-redis:0>sadd hello 1 2 "2" 新docker-redis:0>object encoding hello "intset"

• 如果set存儲的字符串，那么sadd會升級為hashtable結構，

新docker-redis:0>sadd hello yes no "2" 新docker-redis:0>object encoding hello "hashtable"

總結

hash - max-z 工pl 工 st entries 512 結構存儲 # hash 的元素個數超過 512 就必須用標準 hash- max-ziplist-value 64 超過 64 就必須用標準結構存儲 # hash 的任意元素的 key/value 的長度超過64 就必須用標準結構存儲 list-max-ziplist-entries 512 結構存儲 # list 的元素個數超過 512 就必須用標準結構存儲 list-max-z 工plist - value 64 用標準結構存儲 # list 的任意元素的長度超過 64 就必須用標準結構存儲 zset-max-ziplist-entries 128 結構存儲 # zset 的元素個數超過 128 就必須用標準結構存儲 zset-max- ziplist-value 64 用標準結構存儲 # zset 的任意元素的長度超過 64 就必須用標準結構存儲 set-max-intset-entries 512 標準結構存儲 # set 的整數元素個數超過 512 就必須用標準結構存儲

• 如下測試代碼：

public static void main(String[] args) {Jedis jedis = JedisPoolTools.getJedis();jedis.del("books");for (int i = 0; i < 512; i++) {jedis.hset("books", String.valueOf(i), String.valueOf(i));}System.out.println(jedis.objectEncoding("books"));jedis.hset("books", "hello", "512");System.out.println(jedis.objectEncoding("books"));} //輸出如下： ziplist hashtable

• 當Hash結構元素超過512 ，存儲結構發生變化其他的也都同理，我們通過如上總結數據看出，當hash結構的任意entry的value超過64 ，存儲結構就升級成標準結構。

內存回收機制

• Redis并不總是將空閑內存理解歸還操作系統
• 例如Redis內存10GB，當刪除1GBkey后，觀察內存，并不會太大變化，因為操作系統是以頁為單位回收內存，這個頁內只要還有一個key，就不會被回收。Redis雖然刪除了1GBkey但是這些key是分散到各個page中，每個page都還有其他key，這就導致內不會被立刻回收。
• 我們執行flushdb，觀察內存，他就會重新使用那些尚未回收的空閑內存。就比如一個page中只有一個key，次數set另一個key，他會存儲在這個page的空閑內存中。

內存分配算法

• 內存分配是比較復雜的，需要是的劃分內存頁，考慮內存碎片，需要平衡性能與效率
• Redis為保證自身結構簡單，目前沒有自己做內存分配策略，由第三方庫完成此部分內容，
  • Redis可以用jemalloc，facebook的庫來管理內存
  • Redis也可以切換到tcmalloc，google的庫來管理
• jemalloc性能優于tcmalloc，Redis默認使用jemalloc

新docker-redis:0>info memory "# Memory used_memory:5110711968 ..... mem_fragmentation_ratio:1.33 mem_allocator:jemalloc-4.0.3 active_defrag_running:0 lazyfree_pending_objects:0

• 通過info memory指令可以看到Redis的 mem_allocator:jemalloc-4.0.3使用的jemalloc-4.0.3

上一篇：Redis–事務理解
下一篇：Redis高可用基石–主從同步

總結

以上是生活随笔為你收集整理的Redis存储优化--小对象压缩的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。