先说那次事故
上周三凌晨两点，我被电话吵醒。告警群里刷屏：支付接口P99延迟从80ms飙到12秒，数据库CPU直接100%。我第一反应是慢SQL，结果一查，Redis的连接数爆了，几千个线程卡在GET命令上。原因很蠢——有个同事把一个大key的value从字符串改成了一兆多的JSON，然后接口里做反序列化再改字段再写回去。每次请求都要传输1MB数据，Redis网络带宽被打满，然后连接池耗尽，所有请求开始直接打到数据库。这个事故让我突然意识到，我们信任Redis的方式，其实和信任一个无限容量的内存没有什么区别。
我们把Redis当成了什么
绝大多数文章都在教你Redis多快、多高效、数据结构多丰富，但没人告诉你它本质上是一个单线程的网络服务。单线程意味着它处理命令是有序的，任何一个慢命令（比如KEYS、大key的批量操作）都会阻塞后面所有命令。而且它所谓的高性能是建立在数据完全fit在内存里的前提下的，一旦超过内存，淘汰策略开始工作，你的缓存就变成了一个不确定的LRU模拟器。你永远不知道哪些key会被淘汰，当流量峰值来临，那些冷门但关键的配置被逐出，系统就会以一种极其诡异的方式崩溃——不是整体挂掉，而是局部功能间歇性失效。
我不太喜欢现阶段的所谓“分布式缓存最佳实践”的论调。每个人都在说用缓存提高读性能，却很少有人强调缓存是系统里最脆弱的弹簧——它能在平时保持优雅，但当压力超过某个临界点，它会以非线性方式反弹，把所有流量原封不动地送回数据库。通常我们管这个叫缓存雪崩，但雪崩这个词太浪漫了，实际上更像是弹簧断裂，碎渣飞溅到数据库上，留下几十个磁盘IO和慢查询。
我为什么说持久化是陷阱
Redis的持久化是个很有意思的悖论。RDB和AOF都让你觉得数据是安全的，但只要你真的用它来存关键业务数据，你早晚会遇到数据丢失的尴尬。RDB是定时快照，宕机丢最后几分钟的数据；AOF是追加日志，即使everysec模式，也可能丢一秒。你可能觉得一秒无所谓，但如果是扣库存，一秒能扣掉你一个月利润。我见过一个团队为了追求极致性能，把Redis当数据库用，存用户余额和订单状态，然后开了AOF everysec。结果服务器宕机重启后，十几笔订单凭空消失，客户投诉如潮，最后只能手动对账补偿。他们没搞懂一个道理：Redis的持久化设计的是为了重启恢复，不是为了做持久存储的保险箱。它那套appendonly机制，在你真正需要它的时候，反而会因为磁盘IO拖慢主线程。
更讽刺的是，Redis官方的分布式方案Redis Cluster，它的主从切换和failover是异步复制的。主节点写成功了返回，但同步给从节点的过程有延迟。如果主节点瞬间宕机，那些没有复制到从节点的写操作就永远丢了。这不是极端场景，而是集群模式下的固有缺陷。所以这就逼着你必须在性能和一致性之间做一个极其痛苦的选择：要么接受丢失，要么在业务层加补偿机制。我不是说Redis不能用，而是想让你别被它那些炫酷的模块掩盖了底层设计的脆弱性。
一种更清醒的用法
现在我设计系统，会把Redis当做一个有脾气的状态机，一个可以被随意清空的临时仓库，而不是什么“缓存中间件”的抽象名词。所有写入Redis的数据，我都假设它下一秒会消失，所以必须有重建路径。比如用户会话，丢了就让用户重新登录；热点新闻，丢了就从数据库重新生成；库存数字，我可以接受短暂的不准确，但数据库里一定要有原子操作兜底。我甚至会在代码里不依赖Redis的返回值——当Redis超时或者连接错误，直接降级到数据库，绝不让缓存异常影响了主流程。
还有一点，我坚决不用那些花哨的分布式锁和RedLock。RedLock的作者已经自己承认它在某些情况下是不安全的，我更倾向于用数据库的唯一索引或者ZooKeeper来保证强一致。Redis的锁看起来方便，但一旦主从切换，锁可能丢失，然后两个客户端就同时持有锁，整个保护逻辑就变成了废话。我宁愿多写几行代码，也不愿在凌晨三点被叫起来看脑裂日志。
说这么多，我不是劝你放弃Redis。它确实是我用过的最强大的单机数据结构服务器，但你要明白它的边界。它适合做那些可以容忍丢失的加速层，适合做计数器、限流器、排行榜，但绝不应该是你系统的唯一防线。你得给你的数据库留一条后路，给Redis一个备份计划。说到底，架构就是一个不断被打破的预期集合，而Redis往往是你第一个应该打破预期的地方。