Redis 存储压缩实战

背景简述

xx的模型分计算,由于客户对响应要求比较高,要求在20ms内就需要返回, 同时QPS要求为60W .

所以存储这一块的选则就是使用的Redis的集群(无主从,更多资源用来存储,同时高可用要求不高)

一开始使用最直接使用了String的Key-Value入库 ; 结果,才入了八亿的数据,内存就去到了140g .对单点分析之后得出对象数量3000w, 数据内存消耗:2.72g,大约一条记录数据大小是97字节,但实际节点占用内存:5.13g . 运维给出来的答复是 :

Image.png

数据格式

数据量: 50亿+
数据格式: MD5(imei) :Score1(double),Score2(double)
单条纯数据量: 32字节

相关知识点

Redis 的ZipList

首先ZipList是作为Redis的一种底层数据结构, 在一定条件下可作用于HashTable,List,Set的底层实现,
由于其设定是使用一整块的连续内存 (可看似数组结构) ,减少了内存碎片的产生,同时在提供了较高的效率 .

结构

Redis ZipList结构.png

zlbytes: 4字节，表示ziplist占用的字节总数（也包括本身占用的4个字节）。
zltail: 4字节，表示ziplist表中最后一项（entry）在ziplist中的偏移字节数。
zllen: 2个字节，表示ziplist中数据项（entry）的个数。zllen字段因为只有16bit，
entry: 表示真正存放数据的数据项，长度不定。一个数据项（entry）也有它自己的内部结构，这个稍后再解释。
zlend : ziplist最后1个字节，是一个结束标记，值固定等于255。

注意事项

由于ZipList的初始是申请一个连续的长度为zlbytes的内存 , 所以正常情况下对ZipList的修改都会触发内存的重分配, 同时有可能发生数据的复制开销比较大.
这也是ZipList不适合用于存放过大量数据.

以下是HashTable底层使用ZipList的相关配置:

hash-max-ziplist-entries 512   //当entry数量小于这个数量就会使用ZipList作为存储,大于他则会转化为dict存储
hash-max-ziplist-value 64   //ziplist entry的大小阈值

实践

要使用ZipList作为存储结构,所以使用HashTable的时候要将entry的数量控制在ZipList的hash-max-ziplist-entries阈值内 (极光这里配置的是256 先不做修改,按这个条件来)

计算Redis Key数量

预估Key数量范围

根据上面的需要将entry数量控制再256以内 , 所以按照50亿的总数量计算的话那么, Redis Key 的KeyNum应该是:

image.png

这里的KeyNum根据实际情况可以预估大一点以备数据量增加

确定Redis Key的数量

通过上一步我们确定了KeyNum的范围 ,那么这一步就要考虑如何将要做的就是找到一个确定的数量使得我们50亿的数据可以均匀的分布再这 KeyNum 个HashTable里

如下图所示,我们的Key是32位的MD5(imei), 为了达到更好的内存合理使用,所以这里考虑将这32位的十六进制拆分成两部分, 一部分作为Redis的Key,一部分作为HashTable的field.

MD5的初始画图.png

如果使用六位的十六进制作为Redis Key那么他的KeyNum为:
2^24 = 16,777,216
同理七位 :
2^28 = 268,435,456
同理八位 :
2^32 = 4,294,967,296

与上面计算出来的 19,531,250比较, 使用七位的十六进制作为Key 的话,那么理论上他的每个HashTable的Entries数量就是大概20个左右. 所以直接选择了7位的十六进制

这里六位的十六进制也可以选择的,只需要将上述的hash-max-ziplist-entries 配置的稍微大一点,但是带来的就是hget的时候会比七位十六进制的慢. 由于没有做过hget差异实验 ,所以就保险的先选择7位.

确定Redis Key

如下图所示,进行拆分,由于七位的十六进制只有3.5个字节,所以这里需要补一个十六进制的 '0' 凑整4个字节.

MD5的初始画图 (1).png

代码实现如下:

        m1_score = struct.pack('d', round(float(_['m1_score']),8))
        m2_score = struct.pack('d', round(float(_['m2_score']),8))
        
        pip.hset(bytes((_['imei'][25:32] + '0').decode('hex')), bytes((_['imei'][:25] + 
'0').decode('hex')),bytes(m1_score + m2_score))

为了使切分七位十六进制后的数据更均匀分布,应该对选择的目标七位十六进制进行groupBy,然后看看,数据分布的是不是足够的均匀. 假设,如果有大量MD5(imei) 的前七位都是零,那么就会造成 key为00000000的这个HashTable 过于庞大,而没法使用ZipList . 经过对玖富的数据进行分析,最终选取后七位

思考

1.可以通过减少RedisKey的数量, 达到增加每个HashTable的Entry的数量,达到内存缩减