前言
對於Redis,內存優化是十分必要的.降低內存佔用空間有助於保存更多的數據,提升持久化的的效率,減少快照加載的時間等等。本節內容就瞭解一下內存優化的方法。
1.使用壓縮列表
(I)在通常的情況下:
1.哈希則是字典
2.有序集合則是哈希+散列。
(II)在哈希,有序集合長度較短或者體積較小下:
Redis都用壓縮列表來保存。
看到這裡,可能你有疑問,多短才算短呢?
一般是在配置文件中設置的,如下圖所示:
設置最大容量為2，在少於2個數據裡面是壓縮列表,在大於2個以後變成哈希表
壓縮列表的組成部分,顯然它比字典跳躍表等結構更節省空間
這裡順帶說說快速列表
在redis早期版本中,列表也是和上面的哈希和有序集合一樣的。在體積較小的情況下是ziplist,通常情況下是Linklist。在3.2的版本中用快速列表代替了,這樣就節省了每個節點前後指針的空間。
quicklist的每個節點都是一個ziplist。
在redis早期的版本中也可以一下配置來節省list的空間。
<code>list
-max-ziplist-entries128
list
-max-ziplist-value64
/<code>
注意:
長的壓縮列表會有一定的性能的問題，只有將壓縮列表的長度控制在500到2000之間,元素的體積不超過128字節,那麼性能會處於合理的範圍。
2.用哈希表進行存儲
我的理解就是用哈希表保存,儘量在保存的過程中不要保存到重複的數據用於節省內存。
例如下面的這條數據
Mike是英國籍男子,身高160cm,體重120Kg
相對於第一種的實現方式,第二種的Key:【Person:Mike】只需保存一次，而第一種則需要保存4次
如果上述數據有很多的話，節省的效果是顯然的。
3.存儲二進制位和字節
GetBit命令:獲取字符串某位置二進制的值
SetBit命令:設置字符串某位置二進制的值
上圖假設情景，用戶的ID是連續不斷的,book1這個字符串變量記錄的是每個用戶是否瀏覽book1這本書。如果瀏覽了則設置1,沒有瀏覽則是0。
當1001個人瀏覽了以後,程序則設置
<code>setbit
book1
1000
1
/<code>
當想知道第100個人是否瀏覽了book1,則
<code>getbit
book100
/<code>
GetRange命令:獲取字符串某一段位置的值
SetRange命令:設置字符串某某一段位置的值
如上圖,100-100-100-001-111-000-110展示的是7個用戶瀏覽三本書的情況，1表示瀏覽,0表示沒有。
如果需要獲取第一個人的瀏覽情況
<code>getrange
lookbooks
0
2
/<code>
設置第4個人的讀書情況是所有都瀏覽了
<code>setrange
lookbooks
12
111
--12代表偏移量，111是設置的值。
/<code>
最後Redis的字符串最大存儲的512MB,如果數據量太大,可以用哈希表分片的方式將數據保存到不同的字符串內。
4.編譯32位的Redis
使用32位的redis，對於每一個key,將使用更少的內存，因為32位程序，指針佔用的字節數更少。但是32的redis整個實例使用的內存將被限制在4G以下。使用make 32bit命令編譯生成32位的redis。RDB和AOF文件是不區分32位和64位的（包括字節順序）,所以你可以使用64位的reidis恢復32位的RDB備份文件.
