前言
对于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备份文件.
