单机环境下Redis内存怎么省空间，存储优化那些事儿

说到怎么给Redis省内存，这事儿其实挺实际的，尤其当你的数据量越来越大，服务器内存又有限的时候，咱们不扯那些高大上的理论,就直接说一些能上手操作的办法。

最基础也最重要的一点，就是别把Redis当垃圾桶，什么都往里扔，在用Redis之前，先想清楚，这些数据是不是真的需要放在Redis里？是不是所有的字段都是必须的？你存一个用户信息，可能有一二十个字段，但也许当前业务场景下只需要用到来昵称、头像和最后登录时间这三项，那你就只存这三项，别把用户的生日、地址、个人签名这些暂时用不上的全存进去，从数据源头就做好精简，这是最有效的省钱办法。（这个思路在很多技术文章里都有强调,是优化的首要原则）

你得给Redis的键（Key）“瘦身”，Key是会被反复存储的，如果Key很长，那浪费的内存就很可观，你要存用户123的姓名，别用这种Key：user:123456789:profile:base_info:name，试着把它缩短，比如变成u:123:nm，缩短的前提是你们团队的开发人员都能明白这些缩写的含义，最好有个统一的命名规范，用短Key能省下非常多的内存空间。（在Redis官方文档以及众多性能优化指南中,缩短Key长度是被反复提及的基础优化点）

咱们得聊聊Value的优化，Redis提供了好几种数据结构,选对了能省一大笔钱。

1. 善用哈希（Hash）表：如果你要存一个对象的多个字段，比如上面说的用户信息，别用多个独立的Key（如user:123:name, user:123:avatar），而是应该用一个Hash来存，Key是user:123，字段是name，avatar等，Redis在存储小Hash（指字段数不多，Value长度不大）时，会采用一种非常紧凑的编码方式（ziplist，之后会变成listpack），这比存多个独立的String类型的Key要节省很多内存，这招对于存储对象属性特别有效。（Redis作者Salvatore Sanfilippo本人就多次推荐使用Hash来聚合存储小对象）

2. 列表（List）、集合（Set）、有序集合（ZSet）也有类似的“小对象优化”，当这些数据结构里面的元素数量少于一定值、且每个元素的大小小于一定阈值时，Redis也会使用紧凑的存储格式，你可以根据你的数据情况，在Redis的配置文件里调整这些阈值（比如hash-max-ziplist-entries, zset-max-ziplist-entries等），让更多的数据集合能享受到紧凑存储的红利，但要注意，调得太激进可能会稍微影响性能，因为编码解码需要消耗CPU,这是个权衡。

3. 别忘了HyperLogLog和Bitmap：这两种是Redis的秘密武器，用在特定的场景下能极大地节省空间，你要统计网站的独立访客数（UV），如果直接把每个用户的ID存到一个Set里，用户量上亿的时候，内存肯定爆炸，但用HyperLogLog，可能只需要12KB左右的内存，就能完成估算，虽然有点小小的误差，但在可接受范围内，再比如，要记录用户每天是否签到，用Bitmap（位图）是非常好的选择，一个用户一年的签到情况只需要365个比特位，也就是大概46个字节就能存下，极其节省空间。（在《Redis设计与实现》等书籍中,对这些特殊数据结构的适用场景和节省效果有详细说明）

   

4. 谨慎使用String类型：String是万金油，但有时候并不是最省油的灯，对于非文本类的数字，尽量存成整数而不是字符串，因为Redis会把整数直接存成二进制，比存成字符串"12345"要省空间，如果你有一堆需要单独设置过期时间的计数器，可以考虑用Hash结构配合hincrby命令,而不是一堆String的Key。

再来谈谈数据过期和清理，内存是有限的，所以一定要给数据设置过期时间（TTL），除非是核心的、需要永久保存的配置数据，否则都应该有个合理的TTL，让Redis自动帮你清理过期数据，避免内存被无用数据占满，要选择合适的内存淘汰策略（maxmemory-policy），比如allkeys-lru，当内存不足时，Redis会自动淘汰最近最少使用的Key,保证服务的可用性。

如果这些方法都用上了，内存还是紧张，可以考虑启用Redis的压缩功能（如果用的是Redis Enterprise版），或者更直接一点，升级Redis版本，新版本的Redis往往在内存优化上做得更好，比如用listpack替代ziplist,有更好的性能和压缩效率。

给Redis省内存，核心思路就是“精打细算”：从Key和Value的“体型”上做文章，选用最合适的数据结构，并及时清理垃圾，它是一个结合了业务理解、数据模型设计和Redis配置调优的综合性工作。