怎么才能让Redis占用内存少点，性能又别掉链子，这事儿得好好琢磨下

想让Redis少吃点内存,同时性能还别拖后腿，这事儿确实得像打理自家小仓库一样，得精打细算，讲究方法，咱们一点一点来琢磨。

第一招：钥匙得管好，名字别瞎起 Redis里存的每个数据都有一把“钥匙”，也就是键（Key），很多人不注意，把键名取得老长，user_profile_1234567890_details，看着是清楚，但架不住数据多啊，几百万条数据下来，光存这些又长又重复的键名就得浪费不少内存，这就好比仓库里每个箱子都贴着一张写满详细信息的A4纸，纸比里头装的东西还占地方，解决办法很简单，用缩写或者简短的编码代替，比如把上面的长键名缩成 up:1234567890:d，甚至更短，省下的就是赚到的。（思路参考自Redis官方文档关于内存优化的建议）

第二招：箱子别太大，该分就得分 有时候一个大对象，比如包含几十个字段的用户信息，直接转换成一个巨大的JSON字符串存进去，每次读取哪怕只想要其中一个字段，也得把整个大JSON拖出来，耗内存也耗网络，这时候可以用Redis的哈希（Hash）结构，把一个大对象拆成多个字段来存，Redis在底层对小的哈希结构有特殊的优化，能非常节省内存，就像仓库里别老用一个个巨大的集装箱，改用大小适中、分类清晰的储物柜，存取方便还省空间，但要注意，如果字段数量太多（比如几千上万），这个优化效果会打折扣，所以要根据实际情况来。（思想源于Redis哈希类型的ziplist编码优化）

第三招：过期时间不能少，做个“大扫除” 有些数据就像超市的促销品，只在一段时间内有用，比如短信验证码、临时会话数据，对这些数据，一定要设置过期时间（TTL），Redis会自动清理过期的数据，释放内存，如果不设，这些“垃圾数据”就会一直占着地方，内存再大也不够用，这就跟仓库管理一样，定期清理掉过期、没用的东西，才能保证有空间放新货，可以检查一下有没有本该过期但没成功删除的数据（比如因为长期没被访问），可以考虑定期扫描并清理。（此为Redis基础能力，常见于缓存设计原则）

第四招：挑对数据类型，别一把梭 Redis提供了多种数据结构，字符串（String）、列表（List）、集合（Set）、有序集合（Sorted Set）、哈希（Hash），选对了能省很多内存，比如要存一堆不重复的用户ID，用集合（Set）就比用列表（List）更合适，因为Set在去重的同时，底层实现也更高效，再比如，如果值都是整数，可以考虑使用更节省内存的集合类型（如Set或Sorted Set的特殊编码），就好像存东西，衣服该挂起来，小零件该放收纳盒，乱放一通肯定占地方。（基于Redis不同数据结构的特性）

第五招：终极武器——把数据挤挤水 如果上面的招数都用上了，内存还是紧张，可以考虑使用Redis的压缩功能，就是在数据存进Redis之前，先用自己的程序（比如用gzip、lz4这类算法）压缩一下，取出来的时候再解压，这相当于把衣服抽真空再放进柜子，能极大地节省空间，但代价是消耗更多的CPU资源，因为存取时多了压缩和解压的步骤，所以这招是典型的“空间换时间”，得看你的业务能不能接受这点性能延迟，如果网络带宽是瓶颈，压缩还能顺带减少网络传输量。（此为通用技术手段，非Redis特有）

第六招：升级硬件或拆分配置 如果单台Redis实例实在扛不住了，还有最后两条路，一是升级硬件，加内存，简单粗暴但有效，二是搭建Redis集群，把数据分片存储到多台机器上，这样每台机器只存一部分数据，内存压力自然就分散了，相当于一个小仓库装不下了，就租用几个小仓库来分摊，而不是非要去换一个超级大的仓库。（此为可扩展性架构常识）

性能别掉链子的关键：平衡之道 所有这些节省内存的方法，几乎都需要在“内存”和“性能/复杂度”之间做权衡：

• 压缩数据会消耗CPU。
• 使用复杂的数据结构可能增加代码的复杂性。
• 数据分片会增加系统的维护成本。

没有一刀切的最优解,最好的办法是：先用Redis自带的命令（INFO memory）分析内存都用在哪了，找出“大头”，然后针对性地尝试上述方法，并密切监控性能指标（比如命令的延迟），先试试优化键名和设置TTL，这些通常没什么副作用，如果还不行，再考虑使用哈希结构拆分大对象，压缩和分片则是最后的大招。

让Redis省内存又保持性能,就是一个不断观察、分析、试验和平衡的过程，核心思想是物尽其用，避免浪费，并根据自己业务的实际情况做出最合适的选择。