Redis那些复杂问题怎么破？深入聊聊高级用法和实战难点

Redis这个东西,用起来感觉很简单，就是set、get、del几个命令，好像没啥难度，但真要用到生产环境里，尤其是业务量大了以后，各种稀奇古怪的问题就冒出来了，今天咱们就抛开那些基础操作，直接聊聊那些让人头疼的“高级”问题和实战中踩过的坑，内容主要参考了业界常见的实践总结，Redis设计与实现》这本书里提到的底层原理，以及像阿里云、腾讯云这些大厂技术博客里分享的实战案例。

第一个大难题：缓存和数据库的数据一致性怎么保证？

这可能是最经典的问题了,你的应用既要读Redis，又要写数据库，怎么保证两边数据一样？用户下单买了最后一件商品，数据库里库存扣成了0，但Redis里的库存缓存还是1，这时候另一个用户来查询，看到还有货，也下单了，这不就超卖了吗？

常见的做法有几种,但每种都有毛病，先更新数据库，再删除缓存”，这是用得比较多的，但你想，万一在更新完数据库后、删除缓存前，服务器宕机了，缓存没删掉，数据就不一致了，还有一种“先删除缓存，再更新数据库”，问题更明显：在删除缓存后、数据库更新前，另一个请求发现缓存没了，就去数据库把旧数据读出来又塞回缓存了，导致缓存里一直是旧数据。

没有银弹,实践中往往需要结合业务场景来权衡，对于一致性要求极高的场景（如资金），可能要通过订阅数据库的binlog（数据库的变更日志）来异步更新或删除缓存，这样可以保证最终一致性，或者干脆对关键数据加分布式锁，更新的时候不让读，但这样性能损耗大，这个问题的核心在于，你愿意用多大的性能代价来换取多强的一致性。

第二个头疼点：缓存穿透、击穿和雪崩，这三个“兄弟”问题

这三个词听起来很像,但区别很大。

• 缓存穿透：指的是查询一个根本不存在的数据，比如恶意攻击者故意请求数据库里没有的商品ID，这样请求会直接打到数据库上，如果量很大，数据库可能就扛不住了，解决办法通常是用布隆过滤器（Bloom Filter）这种数据结构，在查缓存前先过一遍布隆过滤器，如果它说数据不存在，那就不用去查了，或者，对于这些不存在的key，也在缓存里存个空值（比如null），并设置一个很短的过期时间，下次再来就直接返回空了。
• 缓存击穿：指的是一个非常热点的key，在它过期的瞬间，大量请求同时涌来，全都去数据库查询，就像在缓存上打穿了一个洞，解决办法是加锁，第一个请求发现缓存失效后，先去获取锁，然后查数据库重建缓存，其他请求等着，缓存重建好后再来读，Redis的SETNX命令常被用来实现这种简单的分布式锁。
• 缓存雪崩：指的是大量缓存key在同一时间点失效，或者Redis服务本身宕机了，导致所有请求都涌向数据库，造成数据库压力激增甚至崩溃，解决同一时间失效的问题，可以给不同的key设置一个随机的过期时间偏移量，别让它们一起死，而解决Redis服务宕机的问题，就需要做高可用架构，比如Redis主从复制（一个主节点，多个从节点备份）和哨兵模式（Sentinel，自动监控和故障转移），或者直接上Redis集群（Cluster），把数据分片存储在不同的节点上。

第三个高级用法：分布式锁的实现与坑

上面提到了用SETNX做锁,但一个可靠的分布式锁远没那么简单，你要考虑：

1. 死锁：加锁的客户端挂了，锁没法释放怎么办？所以锁必须设置过期时间。
2. 误删：客户端A加的锁，可能因为某些操作慢，锁过期了，然后被客户端B拿到，这时A操作完成，又把B的锁给删了，所以锁的值最好是一个唯一标识（比如UUID），删除的时候要检查是不是自己的锁，Redis从2.6.12版本后，可以用一行Lua脚本来实现原子性的“获取锁-比较-删除”操作，避免非原子操作带来的问题。
3. 锁续期：如果业务操作时间很长，超过了锁的过期时间怎么办？这就需要有一个机制，在锁快要过期但业务还没做完时，给锁“续命”，这就是所谓的“看门狗”机制，像Redisson这样的Redis客户端库就内置了这个功能。

第四个实战难点：持久化策略的选择，RDB和AOF的权衡

Redis为了数据不丢,提供了两种持久化方式，RDB是定时拍一个内存快照，文件小，恢复快，但缺点是可能会丢失最后一次快照到宕机之间的数据，AOF是记录每一次写操作命令，数据安全性高，最多丢一秒的数据（如果配置为每秒同步一次），但AOF文件会越来越大，恢复起来也慢。

生产环境常常是两者混用,用AOF来保证数据安全，同时定期用RDB做一次冷备，因为RDB文件更适合做灾难恢复和历史归档，当AOF文件过大时，Redis会进行重写（rewrite），压缩命令，这个过程本身也是触发一个RDB快照，然后再追加增量AOF命令。

第五个复杂场景：应对海量数据——集群与分片

当你的数据量单机Redis根本装不下,或者读写压力一台机器扛不住时，就必须上集群了，Redis Cluster是官方方案，它采用无中心节点的模式，把数据自动分到16384个槽（slot）上，每个节点负责一部分槽，这对客户端有要求，客户端需要知道哪个key在哪个节点上，好的客户端库会帮你处理这些路由。

但集群也带来了新的复杂度：不支持跨多个key的操作（除非这些key在同一个节点上）；扩容缩容时数据迁移是个精细活，搞不好会影响服务；网络分区（脑裂）下的可用性策略也需要仔细配置。

Redis入门容易,但想真正用好，尤其是在复杂、高并发的生产环境中稳定运行，需要深入理解其原理，并针对具体的业务场景选择合适的策略和架构，每一个高级用法背后，都是为了解决一个实实在在的痛点，同时也引入了新的需要注意的地方，这需要我们在实践中不断学习和总结。