本文基本上是對redis官網上內存優化一文的翻譯，內存優化

集合類型的特殊編碼操作

redis 2.2開始會對一些小的數據集進行進行優化以占用更少的空間，如list,hash,元素為整數的set，有序集的元素個數和最大元素大小小于給定值時，會以一種非常高效的方式進行編碼，是占用的內存可以減少10倍（平均5倍）。

對于用戶和API來說，這些操作完全是透明的，這是由cpu/內存權衡的，以下是是redis.conf指令調整特殊編碼類型的最大元素數和最大元素大小。詳情可以在redis.conf配置文件上有說明。

hash-max-zipmap-entries 512 (hash-max-ziplist-entries for Redis >= 2.6) #hash類型的元素最大個數 hash-max-zipmap-value 64 (hash-max-ziplist-value for Redis >= 2.6) #hash類型的最大元素大小 list-max-ziplist-entries 512　　　　　　　　　　　　　　　　　　　　　　　　　　 #list類型的元素最大個數
list-max-ziplist-value 64 # list類型的最大元素大小 zset-max-ziplist-entries 128 #有序集的最大元素個數 zset-max-ziplist-value 64 #有序集的最大元素大小 set-max-intset-entries 512 #set集合的最大元素個數

　　如何元素的個數或大小超出配置，將轉換成自動編碼，如果自己修改配置的化，通常建議作下基準測試。

使用32位系統

使用位與字節操作

　　redis在2.2版本引入了字節和位操作GETRANGE，SETRANGE，GETBIT和SETBIT。這些命令可以將字符串類型視作字節數組。使用它們可以更加節約內存使用。如使用一個bit位來保存用戶性別信息：0為男，1為女。

盡可能使用hash類型

　　如上提到的，hash類型在小的集合下會被特殊編碼，可以增加內存使用效率。因此，應當使用hash來表示數據。例如，在一個web應用中，應當使用一個hash保存一個對象，而不是使用許多代表用戶屬性的key來表示用戶屬性。如user-100001{age:19, sex:1, adress: 杭州}，而不是user.age-100001:19這種鍵值對來保存用戶信息。

使用hash抽象一個節省內存的鍵值存儲

　　我們可以使用redis來對普通的鍵值存儲來進行建模，其中值可以是字符串，這不僅比普通的鍵值存儲有更高的內存效率，而且比memcached更加高效。

　　讓我們從一些事實開始，在少量的數據下，使用key-value表示的化比使用hash來表示占用了更多的內存。

　　很多情況下hash表比較小，只包含幾個字段。當hash比較小時，會被編碼為O(N)的數據結構，如具有長度前綴的鍵值對數組。由于我們只有在N很小的時候才這樣做，所以Hget和HSET的平均時間還是O(1)。

　　只從時間復雜度來說，這種解釋并不充分，但是常量時間方面來看確實如此，應為數組結構與cpu的緩存能在一起發揮的很好（數組結構比hash的局部緩存性能好）。

　　但是由于hash的key功能沒有redis的齊全，如不能有過期時間、并且只能時字符串。

?

轉載于:https://www.cnblogs.com/hhan/p/10950918.html

總結

以上是生活随笔為你收集整理的redis内存操作的全部內容，希望文章能夠幫你解決所遇到的問題。

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