内存优化方式与参数

关闭 Redis 的虚拟内存[VM]功能，即 redis.conf 中 vm-enabled = no
设置 redis.conf 中 maxmemory ，用于告知 Redis 当使用了多少物理内存后拒绝继续写入的请求，可防止 Redis 性能降低甚至崩溃
可为指定的数据类型设置内存使用规则，从而提高对应数据类型的内存使用效率
Hash 在 redis.conf 中有以下两个属性，任意一个超出设定值，则会使用 HashMap 存值
hash-max-zipmap-entires 64 表示当 value 中的 map 数量在 64 个以下时，实际使用 zipmap 存储值
hash-max-zipmap-value 512 表示当 value 中的 map 每个成员值长度小于 512 字节时，实际使用 zipmap 存储值
List 在 redis.conf 中也有以下两个属性
list-max-ziplist-entires 64
list-max-ziplist-value 512
在 Redis 的源代码中有一行宏定义 REDIS-SHARED-INTEGERS = 10000 ，修改该值可以改变 Redis 存储数值类型的内存开销

------------转载------------------------------------

业务场景：Redis 作为目前主流的key-value 内存数据库，因为其高并发，存储查询速率快，我们很多的热点数据均会存储到Redis 中，如果数据量较大的话，昂贵的内存消耗也是一笔很大的支出，因此Redis 内存优化是很有必要的。

以下是笔者所在公司的Redis 服务的内存使用情况

上图可以看到：Redis内部的对象数高达：1,599,098,020（15亿），其内存使用高达 371G ,并且持续的增多，需要我们尽快优化，释放多余的空间。

目前存储的现状

• 目前Redis 存储使用的数据类型为：string
• key 的构成为： type:business_tag:user_id:item_id:item_detail_id
• value 的组成为：

{
    "expireTime": "253402271999000",
    "value": "test_test_test_test"
  }

主要优化手段如下

• 存储结构变更 由string 变更为 hash

主要内存优化依据是：
Redis 内部Hash 数据结构的编码方式主要有两种：

• OBJ_ENCODING_ZIPLIST（压缩列表）
• OBJ_ENCODING_HT（哈希表）

Redis 内部会根据数量的情况自适应的选择这两种编码方式中 最优 的一种，这种操作完全对用户透明，选择压缩列表存储的依据主要是：

• 数据条目较少（hash-max-ziplist-entries）即 Hash 的filed 较少 field 个数 默认小于 512
• 数据值较少（hash-max-ziplist-value）即Hash的value 值较少 value 值的长度小于64

即默认存储为压缩列表存储的条件为

field_num < hash-max-ziplist-entries && value.length < hash-max-ziplist-value

综上所述：根据前面看到的业务场景，完全满足此种场景，这是选择由string存储变为 Hash存储的一个原因

OBJ_ENCODING_ZIPLIST 编码的主要思想是：空间换时间，适应于字段个数比较少，字段值也比较小的场景。

• key的优化

为了全方位的对内存进行优化，那么key 以及 hash 的field 进行必要的压缩

• 如果是字符串的话可以进行分段优化，针对数据进行16进制转换
• 字符串使用简写方式

迁移后Redis 实例存储对比

为保证测试的准确性，私有服务器安装Redis 进行优化前与优化后内存空间测试
以下为整个测试过程：

• docker 安装 Redis

docker pull redis

docker ps # 查询当前容器

docker exec -it ****** /bin/bash # 进入容器内部
redis-cli -a 123456 #打开Redis-cli连接Redis 
info memory  # 查询安装完成后Redis 的内存使用情况

以上为Redis 服务搭建过程的简单记录

• 数据存储测试(未优化前)

优化前 存储 1000000 string 类型数据如下：

-- string key
0:1:201155:100:545953888100
-- string value
{
  "value": "3.6230093077568726-0.3630194103106919100",
  "expireTime": "2147483647"
}

由上图内存存储可知：未优化前 1000000 条 string 消耗内存：200.12M
执行完测试，将此前存入的数据删除

• (1)数据存储测试（优化key value）

  • 压缩key的长度：将最后的无业务标识的字符串转换为：16进制
  • 压缩value 的长度：压缩value的数据

优化后 存储1000000数据使用内存：139.10M 相比较优化前优化内存：30%
偷偷窃喜下，如果进行此次优化：节省内存：115G

• (2)数据存储测试（优化key value）

  • 压缩key的长度：将最后的无业务标识的字符串转换为：64 进制
  • 压缩value 的长度：压缩value的数据

此次优化变化不明显，仅仅降低了 不到1M ，疑惑脸。。。
于是乎对于key的长度不进行压缩，只对value值进行压缩进行测试结果如下：

由以上测试可得：1000000数据，内存使用率为 146.59M ,故此 16/64 进制对key的压缩影响并不明显。

• (3)数据存储测试（优化key value）

  • 压缩key的长度：将最后的无业务标识的字符串转换为：64 进制
  • 压缩value 的长度：压缩value的数据,不在存储json，只存储，attr1:value,attr2:value2

以上优化后，存储1000000数据使用内存：123.86M，优化达到：38%

• (4)数据存储测试（优化key value）

  • 压缩key的长度：将最后的无业务标识的字符串转换为：64 进制
  • 压缩value 的长度：压缩value的数据,不在存储json，只存储，attr1:value

经过第4次进行优化，内存的占用依旧与第三次相差很小，但是仍然在减少，此次内存占用为 123.71M，继续对value值做压缩

• (5)数据存储测试（优化key value）

  • 压缩key的长度：将最后的无业务标识的字符串转换为：64 进制
  • 压缩value 的长度：压缩value的数据,只存储，attr1:value, exp(过期时间戳)压缩为64进制

经过第5次进行优化，内存占用达到了 116.27M ，优化达到：42%

• 数据存储测试（优化key value的基础上进行 数据结构变更：变更为HASH）

见证奇迹的时刻到了，变更HASH 结构后，1000000数据内存占用 100.49M，优化50%

思考：

Redis 的内存优化，需要配合业务场景进行针对性的优化，并不是一味的已减少内存为主要的优化目标，我们也应该在空间和时间上找到一个平衡点进行恰当的优化，就那此次优化来说，虽然内存减少了 50% ，但是在实际应用中考虑到，该数据对于效率要求比较高，所以在进行编码解码过程中也存在时间的消耗，最终并不是采用内存优化度最大的那种方案。