选择合适Redis数据结构，减小80%的内存占用

转载自：《redis探秘：选择合适的数据结构，减小80%的内存占用》- 武伟峰 京东零售
实战技巧，深刻浅出还手把手教学，值得参考

前言

redis做为目前最流行的nosql缓存数据库，凭借其优异的性能、丰富的数据结构已成为大部分场景下首选的缓存工具。

因为redis是一个纯内存的数据库，在存放大量数据时，内存的占用将会很是可观。那么在一些场景下，经过选用合适数据结构来存储，能够大幅减小内存的占用，甚至于能够减小80%-99%的内存占用。

利用zipList来替代大量的Key-Value

先来看一下场景，在Dsp广告系统、海量用户系统常常会碰到这样的需求，要求根据用户的某个惟一标识迅速查到该用户id。譬如根据mac地址或uuid或手机号的md5，去查询到该用户的id。

特色是数据量很大、千万或亿级别，key是比较长的字符串，如32位的md5或者uuid这种。

若是不加以处理，直接以key-value形式进行存储，咱们能够简单测试一下，往redis里插入1千万条数据，1550000000 - 1559999999，形式就是key（md5（1550000000））→ value(1550000000)这种。

而后在Redis内用命令info memory看一下内存占用。

能够看到，这1千万条数据，占用了redis共计1.17G的内存。当数据量变成1个亿时，实测大约占用8个G。

一样的一批数据，咱们换一种存储方式，先来看结果：

在咱们利用zipList后，内存占用为123M，大约减小了85%的空间占用，这是怎么作到的呢？

redis的底层存储来剖析。

redis数据结构和编码方式

redis如何存储字符串

string是redis里最经常使用的数据结构，redis的默认字符串和C语言的字符串不一样，它是本身构建了一种名为“简单动态字符串SDS”的抽象类型。

具体到string的底层存储，redis共用了三种方式，分别是int、embstr和raw。

譬如set k1 abc和set k2 123就会分别用embstr、int。当value的长度大于44（或39，不一样版本不同）个字节时，会采用raw。

int是一种定长的结构，占8个字节（注意，至关于java里的long），只能用来存储长整形。

embstr是动态扩容的，每次扩容1倍，超过1M时，每次只扩容1M。

raw用来存储大于44个字节的字符串。

具体到咱们的案例中，key是32个字节的字符串（embstr），value是一个长整形（int），因此若是能将32位的md5变成int，那么在key的存储上就能够直接减小3/4的内存占用。

这是第一个优化点。

redis如何存储Hash

从1.1的图上咱们能够看到Hash数据结构，在编码方式上有两种，1是hashTable，2是zipList。

hashTable你们很熟悉，和java里的hashMap很像，都是数组+链表的方式。java里hashmap为了减小hash冲突，设置了负载因子为0.75。一样，redis的hash也有相似的扩容负载因子。细节不提，只须要留个印象，用hashTable编码的话，则会花费至少大于存储的数据25%的空间才能存下这些数据。它大概长这样：

zipList，压缩链表，它大概长这样：

能够看到，zipList最大的特色就是，它根本不是hash结构，而是一个比较长的字符串，将key-value都按顺序依次摆放到一个长长的字符串里来存储。若是要找某个key的话，就直接遍历整个长字符串就行了。

因此很明显，zipList要比hashTable占用少的多的空间。可是会耗费更多的cpu来进行查询。

那么什么时候用hashTable、zipList呢？在redis.conf文件中能够找到：

就是当这个hash结构的内层field-value数量不超过512，而且value的字节数不超过64时，就使用zipList。

经过实测，value数量在512时，性能和单纯的hashTable几乎无差异，在value数量不超过1024时，性能仅有极小的下降，不少时候能够忽略掉。

而内存占用，zipList可比hashTable下降了极多。

这是第二个优化点。

用zipList来代替key-value

经过上面的知识，咱们得出了两个结论。用int做为key，会比string省不少空间。用hash中的zipList，会比key-value省巨大的空间。

那么咱们就来改造一下当初的1千万个key-value。

第一步：

咱们要将1千万个键值对，放到N个bucket中，每一个bucket是一个redis的hash数据结构，而且要让每一个bucket内不超过默认的512个元素（若是改了配置文件，如1024，则不能超过修改后的值），以免hash将编码方式从zipList变成hashTable。

1千万 / 512 = 19531。因为未来要将全部的key进行哈希算法，来尽可能均摊到全部bucket里，但因为哈希函数的不肯定性，未必能彻底平均分配。因此咱们要预留一些空间，譬如我分配25000个bucket，或30000个bucket。

第二步：

选用哈希算法，决定将key放到哪一个bucket。这里咱们采用高效并且均衡的知名算法crc32，该哈希算法能够将一个字符串变成一个long型的数字，经过获取这个md5型的key的crc32后，再对bucket的数量进行取余，就能够肯定该key要被放到哪一个bucket中。

第三步：

经过第二步，咱们肯定了key即将存放在的redis里hash结构的外层key，对于内层field，咱们就选用另外一个hash算法，以免两个彻底不一样的值，经过crc32（key） % COUNT后，发生field再次相同，产生hash冲突致使值被覆盖的状况。内层field咱们选用bkdr哈希算法（或直接选用Java的hashCode），该算法也会获得一个long整形的数字。value的存储保持不变。

第四步：

装入数据。原来的数据结构是key-value，0eac261f1c2d21e0bfdbd567bb270a68 →  1550000000。

如今的数据结构是hash，key为14523，field是1927144074，value是1550000000。

经过实测，将1千万数据存入25000个bucket后，总体hash比较均衡，每一个bucket下大概有300多个field-value键值对。理论上只要不发生两次hash算法后，均产生相同的值，那么就能够彻底依靠key-field来找到原始的value。这一点能够经过计算总量进行确认。实际上，在bucket数量较多时，且每一个bucket下，value数量不是不少，发生连续碰撞几率极低，实测在存储50亿个手机号状况下，未发生明显碰撞。

测试查询速度：

在存储完这1千万个数据后，咱们进行了查询测试，采用key-value型和hash型，分别查询100万条数据，看一下对查询速度的影响。

key-value耗时：1065三、10790、1131八、9900、11270、11029毫秒

hash-field耗时：1204二、1134九、1112六、1135五、11168毫秒。

能够看到，总体上采用hash存储后，查询100万条耗时，也仅仅增长了500毫秒不到。对性能的影响极其微小。但内存占用从1.1G变成了120M，带来了接近90%的内存节省。

总结

大量的key-value，占用过多的key，redis里为了处理hash碰撞，须要占用更多的空间来存储这些key-value数据。

若是key的长短不一，譬若有些40位，有些10位，由于对齐问题，那么将产生巨大的内存碎片，占用空间状况更为严重。因此，保持key的长度统一（譬如统一采用int型，定长8个字节），也会对内存占用有帮助。

string型的md5，占用了32个字节。而经过hash算法后，将32降到了8个字节的长整形，这显著下降了key的空间占用。

zipList比hashTable明显减小了内存占用，它的存储很是紧凑，对查询效率影响也很小。因此应善于利用zipList，避免在hash结构里，存放超过512个field-value元素。

若是value是字符串、对象等，应尽可能采用byte[]来存储，一样能够大幅下降内存占用。譬如能够选用google的Snappy压缩算法，将字符串转为byte[]，很是高效，压缩率也很高。

为减小redis对字符串的预分配和扩容（每次翻倍），形成内存碎片，不该该使用append，setrange等。而是直接用set，替换原来的。

方案缺点：

hash结构不支持对单个field的超时设置。但能够经过代码来控制删除，对于那些不须要超时的长期存放的数据，则没有这种顾虑。

存在较小的hash冲突几率，对于对数据要求极其精确的场合，不适合用这种压缩方式。

基于上述方案，我改写了springboot源码的redisTemplate，提供了一个CompressRedisTemplate类，能够直接当成redisTemplate使用，它会自动将key-value转为hash进行存储，以达到上述目的。

后续，咱们会基于更极端一些的场景，如统计独立访客等，来看一下redis的不常见的数据结构，是如何将内存占用由20G下降到5M。

如需代码案例，请联系做者:wuweifeng10@jd.com