redis 用hashmap省内存的误解

看过许多redis优化的案例，通过引入hashmap的方式将key散列到多个hashmap，
具体可以见：
Redis 利用Hash存储节约内存 - 刘本龙的专栏 - CSDN博客

我们得到如下公式：

key的数量=hashmap数量* 每个hashmap filed的数量

原来是:
key1,key2,key3,key4,key5
变成
hash1:
key1:value1
key2:value2
key3:value2
hash2:
key4:value4
key5:value5

虽然名义上5个key变成了2个hashmap，但是每个filed还是会保存原始的key，所以从key减少的层面是行不通的，这个时候就要从底层储存结构去看。

redis对hashmap有一个优化，当filed数量比较少的时候(因为ziplist是用顺序遍历的方式查找元素，所以数量多了复杂度是o(N)肯定不合适。
)，会用一个叫ziplist的结构保存，而不是传统的hash结构，ziplist有几个特点：

1 ziplist申请一个快连续的内存，所有元素是紧挨着存放,能够减少内存碎片
2 通过offset来标识前后元素的位置，不需要额外的指针，也可以减少对象

ziplist介绍
https://blog.csdn.net/weixin_30783913/article/details/98141347

所以hashmap能省内存是依赖ziplist的结构，而不是key的减少。
使用ziplist可以用以下参数控制

hash-max-zipmap-entries 512 #配置字段最多512个
hash-max-zipmap-value 64 #配置value最大为64字节。

必须满足以上两个条件，那么该key会被压缩。否则就是按照正常的hash结构来存储hash类型的key。