用Redis存对象这事儿，聊聊怎么优化存储和访问效率

用Redis存对象这事儿，现在几乎成了标配，因为它快，但要是随便乱存，不仅快不起来，还可能把内存撑爆,咱们就聊聊怎么把它弄得既省地方又跑得快。

核心问题：别把Redis当数据库用

首先得明白，Redis是内存数据库，内存多贵啊，所以头号原则就是，别把Redis当成MySQL那样的关系型数据库来用，在MySQL里，你可能会把一个用户的所有信息，比如用户ID、姓名、头像、简介、注册时间、最后登录时间等几十个字段都存一张表里，查询时用SQL去联表、去过滤，但在Redis里要尽量避免这种“大而全”的存法，你存进去一个巨大的JSON对象，每次访问哪怕只改一个字段，也得把整个对象读出来，改完再整个塞回去，网络传输和序列化的开销都很大,非常浪费。

优化存储：化整为零，按需索取

那怎么办呢？一个很有效的思路是“化整为零”。

1. 拆分对象：别总想着把整个对象序列化成一个大JSON或二进制块，对于复杂的对象，可以考虑用Redis的Hash结构来存储，比如一个用户对象，你可以用一个Hash，Key是 user:123，里面的Field和Value对应着用户的各个属性：name设置为“张三”，avatar设置为“http://...”，last_login设置为“20240601”，这样做的好处是，你可以按需存取，比如只想更新用户的头像，直接用 HSET user:123 avatar "新地址" 就行了，只传输这一个字段的数据，效率极高，想取用户基本信息时，用 HGETALL user:123；如果只想看名字，用 HGET user:123 name 即可。

2. 选择合适的数据结构：除了Hash,其他数据结构也各有妙用。

   • List：适合存有序的、需要顺序访问的数据，比如用户的动态消息列表、任务队列。
   • Set：适合需要快速判断成员是否存在、或者求交集并集的场景，比如用户的标签、共同好友。
   • ZSet（有序集合）：这是Redis的王牌数据结构之一，适合排行榜、带分数的消息队列，比如你要做文章阅读榜，文章ID作为成员，阅读量作为分数，排序、取Top N的操作非常高效。

根据你的访问模式来选择最匹配的数据结构,本身就是一种巨大的优化。

优化访问：减少网络来回是关键

访问效率的瓶颈往往不在Redis本身的计算速度,而在于网络通信。

1. 管道（Pipeline）：这是必须要会的技巧，如果你需要连续执行好几个Redis命令，比如先查一个Key，再根据结果查另一个Key，别一个个地发命令、等回复，应该用管道，把多个命令打包一次性发给Redis服务器，然后一次性接收所有回复，这能极大地减少网络往返次数，提升效果非常明显，这就像搬东西，一次搬一箱跑十趟,不如用推车一次运十箱。

2. 批量操作：像上面提到的 HGETALL、HMGET（Hash的多字段获取）、MGET（获取多个Key）都属于批量操作，尽量一次多拿点数据,避免在循环里频繁调用单个获取命令。

3. 小心使用Keys命令：在生产环境，*绝对不要用 `KEYS 这种模糊匹配命令**，因为Redis是单线程的，KEYS命令会阻塞所有其他请求，导致服务瞬间不可用，非常危险，如果确实需要遍历Key，可以使用SCAN` 命令，它是渐进式的，不会阻塞服务，虽然慢一点,但安全。

   

数据压缩与过期策略

1. 压缩：如果存储的对象确实很大，而且主要是文本（比如大段的文章内容），可以考虑在存入前先做压缩（比如用GZIP），取出后再解压，这是一种用CPU时间来换内存空间的策略，需要根据你的实际情况权衡，如果CPU已经很忙了,就别这么干了。

2. 设置过期时间（TTL）：给Key设置一个合理的过期时间，是防止内存无限增长的终极法宝，用 EXPIRE 命令，对于缓存性质的数据，比如会话（Session）、验证码、热点数据，一定要设TTL，这能保证无用数据被自动清理,避免内存泄漏。

一些进阶考量

• 序列化方式：把对象转换成Redis能存的数据，这个过程叫序列化，JSON最通用，但体积相对大，解析也慢点，Protocol Buffers（Protobuf）、MessagePack等二进制协议更紧凑，序列化/反序列化速度也更快，如果对性能要求极高,可以考虑它们。
• 内存淘汰策略：在Redis配置里，有个 maxmemory-policy 参数，当内存用满时，Redis的行为由它决定，常见的有 allkeys-lru（淘汰最久未使用的Key）或 volatile-lru（只淘汰设了过期时间的Key中最久未使用的），根据你数据的重要性来配置,避免内存满了之后写入失败。

总结一下，优化Redis存对象，核心思想就几点：别存大块数据，用合适的数据结构拆分开；访问时尽量批量操作，多用管道减少网络开销；别忘了给数据设个“保质期”；并根据业务特点调整序列化方式和内存策略，没有银弹,最好的方案永远是贴合你具体业务场景的那个。