当前位置：首页 > 问答 > 正文

Redis里怎么快速拿到最新数据，实践中那些小技巧和坑分享

关于在Redis里快速拿到最新数据，以及实践中遇到的一些小技巧和坑，我结合一些网络上的经验分享和自身实践来聊聊，核心思想就是，Redis再快，如果用得不对，也可能会慢,或者拿到旧数据。

怎么快速拿到“最新”数据？关键是理解“最新”的含义

“最新”通常有两种情况：

针对这两种情况,有不同的做法。

保证“绝对最新”的技巧与双写策略的坑

如果你想确保读到的绝对是刚写入的最新数据，最直接的办法就是避免使用分布式缓存，直接从数据库读，但这显然违背了使用Redis的初衷，在分布式环境下,我们得用一些策略。

技巧：采用“先更新数据库，再删除缓存”的策略 这是目前业界比较推崇的一种方式,操作顺序是：
- 第一步：先更新数据库。
- 第二步：立刻删除Redis中对应的缓存数据。这样做的优点是，即使第二步删除缓存失败了，也顶多是下次读取时多一次数据库查询，然后重新构建缓存，不会导致数据库和缓存的数据长期不一致，下次有请求来读这个数据时，发现缓存没了，就会去数据库查最新值，并重新塞回Redis,后续的读请求就又快了。
坑：经典的“双写”陷阱 很多人会直觉性地用“先更新缓存，再更新数据库”或者“先更新数据库，再更新缓存”,这两种方式都有大坑。
- 并发写导致脏数据，比如线程A和线程B同时更新同一条数据，A先更新了数据库，但网络延迟了；B紧接着更新了数据库，并且先更新了缓存；然后A才去更新缓存，这时候缓存里的就是A的旧数据,脏了。
- 缓存浪费，有些数据可能写入很频繁，但读取次数很少，如果你每次写都去更新缓存，可能这个缓存还没被读过一次，就被下一次写操作覆盖了，这白白浪费了Redis的性能和网络带宽。“删除”通常比“更新”更划算、更安全。

保证“相对最新”的技巧与过期时间的学问

对于绝大多数读多写少的场景，我们并不需要绝对实时，只要缓存能很快（比如1秒内）跟上数据库的变化就行，这时候，给缓存设置一个合理的过期时间（TTL） 是最简单有效的方法。

技巧：设置一个简短的过期时间 比如设置缓存5秒或10秒过期，这样即使出现不一致，最多也只持续几秒钟，业务上通常可以接受,这是一种用一点点延迟换取极大性能提升的权衡。
坑：缓存“击穿”与雪崩 但设了过期时间，如果没处理好,会引来两个著名的坑：
- 缓存击穿：指的是某个热点key在失效的瞬间，突然有大量请求进来，这些请求发现缓存没了，全都冲到数据库去查，相当于一把剑刺穿了缓存，直接打在数据库上，可能导致数据库压力激增。
  - 应对小技巧：使用互斥锁（比如Redis的SETNX命令），当第一个发现缓存失效的线程，先去抢一个锁，抢到了就去数据库加载数据并重建缓存，其他没抢到锁的线程就稍等一下，循环检查缓存是否已被重建好，或者直接返回默认值,避免都去查数据库。
- 缓存雪崩：指的是在同一时间，有大量的key同时过期，这会导致瞬间所有对这些数据的请求都落到数据库上，压力像雪崩一样，可能直接把数据库压垮。
  - 应对小技巧：给缓存的过期时间加上一个随机值，比如基础过期时间是10分钟，然后给每个key的过期时间再加上一个0到60秒的随机数，这样就能让大量key的过期时间尽量分散开,避免同时失效。

其他提升“获取”速度的小技巧和坑

别用Keys命令，用Scan 有一个著名的坑就是，有人想查找符合某个模式的所有key，比如user_*，会直接用KEYS命令，这个命令在生产环境是绝对禁止的，因为它会一次性遍历整个Redis的key集合，如果key很多，会导致Redis服务卡顿很久，正确的做法是使用SCAN命令，它虽然慢，但是分批进行的,不会阻塞Redis。
使用批量操作 如果你需要一次性获取多个key的值，不要用for循环一个个地GET，而应该使用MGET命令，网络通信次数是影响Redis性能的主要因素之一，批量操作能极大减少网络往返时间，速度会快很多，写入时也一样，多用MSET、Pipeline（管道）。
注意Value的大小 Redis官方建议单个value的大小不要超过1MB，虽然它能存更大的，但一个大value的序列化、反序列化、网络传输都会很耗时，而且操作大value会阻塞Redis的单线程，如果value很大，可以考虑压缩后再存，或者思考一下数据结构设计是否合理,能不能拆成多个小key。
谨慎使用那些时间复杂度为O(N)的命令 比如HGETALL、LRANGE 0 -1、SMEMBERS，如果Hash、List、Set里的元素非常多（比如上万），这些命令会一次性把所有数据都捞出来，非常慢，也可能阻塞服务，应该考虑使用HSCAN、SSCAN等增量遍历的命令，或者只获取一部分数据（如LRANGE 0 99）。