snappy压缩redis方案可行性验证

[原创]个人理解，请批判接受，有误请指正。转载请注明出处: https://heyfl.gitee.io/design/snappy-compress-redis.html

Snappy压缩方案

研发环境(redis单节点，两个哨兵)

1. 压缩率

压缩前的redis内存：

String类型保存1万份不同key，相同value的运单内存为119.61-1.02=118MB：

Byte[]类型保存1万份不同key，相同value的运单内存为31.74-1.02=30MB：

结论：改造后的压缩率提升(118-30)/118=74%

2. cpu对比

1. 单线程1万次写入redis

String类型，基本维持在5%以下：

Byte[]类型，基本维持在5%以下：

结论：cpu对比无明显变化

2. 单线程一万次读取对比：

String类型：

Byte[]类型：

结论：cpu对比无明显变化

3. 耗时对比

	单线程1万次写入redis耗时	单线程1万次读取redi耗时
String类型	135677ms	130027ms
byte[]类型	128804ms（提升5%）	124215ms(提升4.5%)

结论：读写均有略微提升

二、测试环境

redis2主2备(4G内存/分片)

1、压缩率

压缩前的redis内存：

String类型保存1万次，两个master共新增118MB

Byte[]类型保存一万次，两个master共新增30MB

结论：改造后的压缩率提升(118-30)/118=74%，与研发环境结论一致

2、CPU对比

写优化前84%：

写优化后41%：

读优化前23%：

读优化后18%：

三、压缩改造

改造前：

将操作运单对象转换成String类型的Json，保存redis

改造后：

风险点：

1、所有查询的地方都需改造和兼容(包括web应用)，否则读取错误
2、只能用自己的web应用查看redis
回退方案：将功能开关关闭