Redis缓存到底怎么存才靠谱，存的时候有哪些坑和技巧要注意呢？

Redis是个好东西，速度快得像闪电，但用不好也容易惹麻烦，它就像一把锋利的刀，能帮你快速解决性能问题，但握法不对也可能伤到自己，下面就来聊聊怎么存数据才靠谱，以及有哪些常见的“坑”和需要注意的技巧。

核心思想：别把Redis当数据库

这是最重要的一条原则，必须放在最前面说，Redis的定位是缓存，它的主要价值在于用内存的极致速度来减轻后方真实数据库（比如MySQL）的压力，它默认的数据持久化机制是为了尽可能保证数据不丢失，但不能像关系型数据库那样提供绝对可靠的数据安全保障（取决于持久化配置），心里要有一条红线：Redis里的数据是可以丢失的，任何你认为绝对不能丢的业务核心数据，都必须以数据库为准，缓存没了，最坏的情况就是去数据库重新查一遍,业务逻辑不应该因此出错。

存数据时的关键技巧与避坑点

1. 键名设计要规范

   • 技巧：使用统一的命名规范，比如用冒号分隔，形成一种类似文件夹路径的结构，用户模块的数据可以这样存：user:123:profile（用户123的资料）、user:123:orders（用户123的订单列表），这样做的好处是清晰易懂，而且方便用keys user:123:*这样的模式来批量查找或管理相关键。
   • 坑点：键名太随意，比如直接用uid、data这种，不同业务的数据容易混淆,后期维护和排查问题非常困难。

2. 设置合理的过期时间

   • 技巧：除非有特殊需求，否则永远记得给你存入Redis的键设置一个过期时间，这可以避免大量不再使用的数据长期占用内存，导致内存耗尽，过期时间的长短根据业务来定，比如验证码可以设5分钟，热门文章列表可以设1小时,用户会话可以设7天。
   • 坑点：不设置过期时间，导致内存被无用数据塞满，Redis性能下降甚至崩溃，这就是所谓的“内存泄漏”。

3. 警惕“大Key”

   • 技巧：“大Key”通常指一个键对应的值体积非常大，比如一个包含几万元素的List或Hash，或者一个巨大的字符串，大Key会带来一系列问题：网络传输耗时久、阻塞Redis主线程（导致其他命令变慢）、集群环境下数据迁移困难。
   • 避坑方法：
     • 对于集合类型（List, Hash, Set, ZSet），可以考虑拆分成多个小Key，比如一个存储了10万用户ID的Set，可以按ID范围拆成10个Key,每个存1万个。
     • 对于大的Hash，可以按字段进行拆分,或者考虑这个数据是否真的需要整个存到Redis里。
     • 定期扫描并清理大Key，Redis提供了redis-cli --bigkeys这样的工具来辅助查找。

4. 警惕“热Key”

   • 技巧：“热Key”指的是某个Key在瞬间被超高并发地访问，比如顶流明星突然发布微博，他个人信息的那个Key就会成为热Key，这可能会导致Redis单实例负载过高,甚至打满网络带宽。
   • 避坑方法：
     • 本地缓存：在应用层加一层本地缓存（如Guava Cache），先从本地读，没有再去Redis读，但这会带来数据一致性问题,需要权衡。
     • Key拆分：将热Key复制成多个副本，比如hotkey_01, hotkey_02，访问时随机选一个,这相当于做了读负载均衡。

5. 选择合适的数据结构

   • 技巧：Redis不是只有简单的set和get，它提供了丰富的数据结构，用对了能极大提升效率和简化代码。
     • 比如要存储用户信息（姓名、年龄、城市），用Hash结构就比用多个独立的String键要高效得多,因为可以一次性获取或修改多个字段。
     • 比如要实现一个排行榜，用ZSet（有序集合）是天作之合,天然支持按分数排序和范围查询。
     • 比如要限制一个手机号一天只能发送5条短信，可以用INCR命令对一个Key进行自增，并设置过期时间为1天,判断值是否大于5即可。

6. 保证数据一致性

   • 坑点：这是最复杂的问题之一，当你更新了数据库的数据后，需要同步更新或删除Redis中对应的缓存，这个操作如果不是原子的，就可能出现数据不一致，比如先更新数据库，再删除缓存的途中,另一个请求可能读到了旧的缓存数据。
   • 技巧：没有完美的银弹，但有一些常用模式。
     • Cache-Aside Pattern：最常见的模式，读请求：先读缓存，命中则返回；未命中则读数据库，写入缓存，写请求：先更新数据库，然后删除缓存，为什么是删除而不是更新？因为删除是幂等的，且可以避免并发写操作导致的缓存数据错乱，这个模式简单有效,但在极高并发下仍有小概率不一致。
     • 更复杂的方案有通过订阅数据库的binlog来异步更新缓存（如Canal）,但这套方案比较重。

7. 避免缓存穿透

   • 坑点：查询一个数据库中根本不存在的数据，自然在缓存中也不会有，导致每次请求都直接打到数据库上，失去了缓存的意义，如果被恶意攻击，用大量不存在的Key来请求,可能会压垮数据库。
   • 技巧：
     • 缓存空值：即使从数据库没查到，也在Redis里缓存一个空值（如null）并设置一个较短的过期时间（比如5分钟），这样后续请求在缓存层就返回了,保护了数据库。
     • 使用布隆过滤器：在缓存之前加一层布隆过滤器，它能以极小的空间代价快速判断一个Key是否可能存在于数据库中，如果布隆过滤器说“不存在”，那这个请求就直接返回,不用继续查询了。

8. 避免缓存雪崩

   • 坑点：指大量缓存数据在同一时间过期失效，导致所有请求瞬间都涌向数据库,造成数据库压力激增甚至宕机。
   • 技巧：很简单，给缓存数据的过期时间加上一个随机值，比如原本统一设置10分钟过期，可以改为在8到12分钟之间随机，这样就能保证数据不会在同一时间点大面积失效,将压力均匀摊开。

总结一下，靠谱地使用Redis缓存，关键在于理解它的定位（缓存非数据库）、预见并规避其潜在风险（大Key、热Key、穿透、雪崩、一致性），并善用其特性（数据结构、过期时间），没有一劳永逸的方案,需要根据具体的业务场景进行设计和调整。