问题缘由
测试反馈资料缓存100w用户，资料占据20G，和评估的差距比较大，需要分析一下原因很在。
加载前后内存对比
分析过程
1. 实例分析
利用ps -ef|grep redis查看启动了两个实例
两个实例
redis-cli -h 127.0.0.1 -p 7370 -c登陆客户端，使用info memory查询信息
Redis memory信息
每个实例大概7.17G。内存碎片率mem_fragmentation_ratio大概是1.05。基本正常。
2. 版本查看
info来查看实力整体信息以及版本。
info信息
3. 记录分析
redis-cli --bigkeys -h 127.0.0.1 -p 7370 -c分析最大key信息。
最大key分析
用debug object SUBS_339828来分析最大key的就大小。
key的占用大小
利用hgetall SUBS_339828来查看记录情况
hgetall获取记录信息
查看key类型和对应的hash的field数目
key分析
小结
1、这个环境有两个实例，每个实例实际数据7.17G。峰值10G，使用率还是比较高。
2、100w数据大概有400w keys。SUBS有42个记录。每个记录大概有3K，这个占比比设想的大，实际生产应该会比这个少。
3、存在一个字段hash。改造为string方式节省空间。
4、版本较老，改为新版本，会省下一些空间。
5、配置文件hash-max-ziplist-value 缺省为64，参数可以调整为128。对于SUBS相关记录会做压缩，减少空间。对应性能影响较少，并且Fields数目越少影响越少。
