redis 是乙個非常耗費記憶體的資料庫，它所有的資料都放在記憶體裡。如果我們不注意節約使用記憶體，redis 就會因為我們的無節制使用出現記憶體不足而崩潰。
1、ziplist：是乙個緊湊的位元組陣列結構，每個元素直接都是緊挨著，資料結構如下圖：
1）object encoding +key :查詢key屬於哪種型別
2）若存放hash結構，key和value會作為倆個entry相鄰存在一起
2、intset；是乙個緊湊的整數陣列結構，它用於存放元素都是整數的並且元素個數較少的 set 集合
1）整數可以動態擴容大小，由uint16到uint32、uint64，儲存的資料不夠後自動往大擴容，如下圖所示：
3、儲存界限：當集合物件的元素不斷增加，或者某個 value 值過大，這種小物件儲存也會被公升級為標準結構：
1）hash-max-ziplist-entries 512 # hash 的元素個數超過 512 就必須用標準結構儲存
2）hash-max-ziplist-value 64 # hash 的任意元素的 key/value 的長度超過 64 就必須用標準結構儲存
3）list-max-ziplist-entries 512 # list 的元素個數超過 512 就必須用標準結構儲存
4） list-max-ziplist-value 64 # list 的任意元素的長度超過 64 就必須用標準結構儲存
5） zset-max-ziplist-entries 128 # zset 的元素個數超過 128 就必須用標準結構儲存
6）zset-max-ziplist-value 64 # zset 的任意元素的長度超過 64 就必須用標準結構儲存
7）set-max-intset-entries 512 # set 的整數元素個數超過 512 就必須用標準結構儲存
例如下圖所示：
4、記憶體**機制
1）redis並不總是可以將空閒的記憶體立即歸還給作業系統，因為作業系統**記憶體是以頁為單位，如果這個頁只要有乙個key還在使用，那麼就不能立刻被**
3）flushdb：執行該命令，會使所有的key都乾掉了，大部分之間使用的頁面都完全乾淨了
5、記憶體分配演算法
1）redis將記憶體分配的細節丟給了第三方記憶體分配庫去實現，目前redis使用jemalloc(facebook) 庫來管理記憶體，也可以切換到tcmalloc(google)，但是jemalloc 相比 tcmalloc的效能要稍好一些，例如下圖檢視記憶體管理：
Redis儲存優化 小物件壓縮
小物件壓縮 32bit vs 64bit 小物件壓縮 public class arraymap keys.add k values.add v return null public v get k k return null public v delete k k return null 新doc...
Redis小物件的壓縮儲存
redis hash是value內部為乙個hashmap，如果該map的成員數比較少，則會採用類似一維線性的緊湊格式來儲存該map，即省去了大量指標的記憶體開銷，這個引數控制對應在redis.conf配置檔案中下面2項 以上2個條件任意乙個條件超過設定值都會轉換成真正的hashmap，也就不會再節省...
小物件壓縮
鑑於redis是純記憶體資料庫，為了盡可能的節省記憶體開銷避免因為記憶體不足而崩潰，redis對一部分資料結構進行了優化。編譯 如果使用32位進行編譯，內部所有資料結構所使用的指標空間占用會少一半，如果使用記憶體不超過4g，可以考慮使用32位進行編譯，如果不足還可以通過增加例項的方式來解決。壓縮 這...