redis-09 选择合适redis数据结构，减少80%的内存占用
前言
redis是一个纯内存的数据库，在存放大量数据时，内存的占用将会非常可观。那么在一些场景下，通过选用合适数据结构来存储，可以大幅减少内存的占用，甚至于可以减少80%-99%的内存占用。
利用 zipList 来代替大量的 key-value
先来看一下场景，在 广告系统、海量用户系统 经常会碰到这样的需求，要求根据用户的某个唯一标识迅速查到该用户id。譬如根据 uuid 或 手机号的md5，去查询到该用户的id。
特点是数据量很大、千万或亿级别，key 是比较长的字符串，如32位的md5 或者 uuid这种。
如果不加以处理，直接以 key-value 形式进行存储，我们可以简单测试一下，往redis里插入1千万条数据，1550000000 - 1559999999，形式就是key（md5（1550000000））→ value(1550000000)这种。
通过 info memory 命令看了下内存消耗情况，发现这 1 千万条数据，占用 redis 内存 1.17GB。当数据量变成 1 亿时，实测大约占用 8GB。
同样的数据，利用 zipList 结构存储，内存只占用 123MB，大约减少了 85% 的内存空间。这个到底是为什么呢？redis 底层怎么帮我们做的优化呢？
redis 底层存储结构剖析
具体详情可以参考我的一篇博文：redis-02 五种类型底层数据结构
从上一篇博文我们可以知道，string 底层存储，redis 共用了三种方式：int、embstr 和 raw。
int是一种定长的结构，占8个字节（注意，相当于java里的long），只能用来存储长整形。
embstr是动态扩容的，每次扩容1倍，超过1M时，每次只扩容1M。
raw用来存储大于44个字节的字符串。
第一个优化点：
具体到我们的案例中，key是32个字节的字符串(embstr)，value是一个长整形(int)，所以如果能将32位的md5变成int，那么在key的存储上就可以直接减少3/4的内存占用。
redis如何存储Hash
直接使用上一篇博文的图来看一下：
而对应的 zipList 存储结果如下：
可以看到，zipList最大的特点就是，它根本不是hash结构，而是一个比较长的字符串，将key-value都按顺序依次摆放到一个长长的字符串里来存储。如果要找某个key的话，就直接遍历整个长字符串就好了。
所以很明显，zipList要比hashTable占用少的多的空间。但是会耗费更多的cpu来进行查询。而且从第一个图也可以得知，什么时候会使用 zipList 结构来存储数据。
那第二个优化点就来了
第二个优化点：
用zipList来代替key-value
通过上面的知识，我们得出了两个结论。用int作为key，会比string省很多空间。用hash中的zipList，会比key-value省巨大的空间。
那么我们就来改造一下当初的1千万个key-value。
第一步：
我们要将1千万个键值对，放到N个bucket中，每个bucket是一个redis的hash数据结构，并且要让每个bucket内不超过默认的512个元素，以避免hash将编码方式从zipList变成hash。
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耗时：10653、10790、11318、9900、11270ms
hash-field耗时：12042、11349、11126、11355、11168ms
可以看到，整体上采用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 比 hash 明显减少了内存占用，它的存储非常紧凑，对查询效率影响也很小。所以应善于利用zipList，避免在hash结构里，存放超过512个field-value元素。
如果value是字符串、对象等，应尽量采用 byte[] 来存储，同样可以大幅降低内存占用。譬如可以选用 google 的 Snappy压缩算法，将字符串转为 byte[]，非常高效，压缩率也很高。
为减少redis对字符串的预分配和扩容（每次翻倍），造成内存碎片，不应该使用append，setrange等。而是直接用set，替换原来的。
