分布式缓存一致性保障 一线踩坑攒下的实在经验

上周跟个做电商的后端朋友在路边撸串，他攥着烤串的手都在抖，说刚因为缓存问题赔了大半个月绩效。

啥问题？大促当天流量冲上来，商品价格缓存没及时删干净，用户点进去看到的都是三个月前的历史低价，短短二十分钟，超卖了快两千单，客服的消息把后台都刷崩了。

最先踩的坑，是把“强一致”当默认需求

很多人一提到缓存一致性，第一反应就是要做到跟数据库百分百同步，差一毫秒都不行。

麻烦在于，缓存本来就是挡在数据库前面的“快进通道”。你非要让它跟数据库每一步都严丝合缝，那要它干嘛？

说白了，绝大多数业务场景下，你根本不需要缓存和数据库的毫秒级强一致。比如商品详情页改个价格，晚个几百毫秒生效，用户根本感知不到。反倒是你为了那几百毫秒的一致性，搞一堆同步逻辑，把缓存的性能优势全霍霍光了，才是真的蠢。

我见过最离谱的一个团队，给内部的OA系统加缓存，要求缓存里的组织架构数据跟数据库完全实时同步，最后为了这个需求，搞了一整套跨服务的通知机制，每次改个部门名称，要给十几个缓存节点发同步请求，一旦某个节点网络抖一下，就会出现数据不一致，最后折腾了三个月，干脆把缓存全撤了，回到直接查数据库的老路上。

常用的方案，每一个都藏着代价

现在圈子里流传最广的一致性方案，无非就是那几个：先更新数据库再删缓存，延迟双删，监听binlog异步同步。

没有哪个是银弹。

就说最常用的“先更库再删缓存”，逻辑看起来完美：数据库是数据源，更新完了把旧的缓存删掉，下次请求进来自然会回源拿到新数据。但问题在哪？只要删缓存的请求失败了——不管是网络超时，还是缓存集群当时流量打满丢了请求——那旧的脏数据就会一直留在缓存里，直到过期时间到了才会被清掉。我那个撸串的朋友踩的就是这个坑，大促当天删除请求的成功率只有80%，剩下20%的脏数据，直接酿成了事故。

很多教程说那加个重试队列不就完了？是能解决。但你得额外搭MQ集群，得维护重试的死信队列，得处理重复消费的幂等问题，这些都是实打实的运维成本。

再说说被吹成神的延迟双删。教程里的逻辑特别顺：先删缓存，更数据库，隔几百毫秒再删一次，把主从同步期间刷回来的旧数据冲掉。但这个方案最大的问题，就是那个“几百毫秒”的延迟时间，你根本算不准。要是遇到数据库主从同步延迟飙到1秒，你设的500毫秒延迟删，根本赶不上，旧数据还是会留在缓存里。我见过太多团队为了凑这个合适的延迟时间，压测压到后半夜，最后还是时不时蹦出来几个脏数据。

没有完美的一致性方案，只有跟业务匹配的取舍。比如涉及资金的交易场景，宁可接口慢一点，也不能出脏数据，那你就别搞异步删缓存，甚至关键路径干脆就不走公共缓存，用本地缓存加主动广播失效的模式都行。但要是普通的内容页、商品列表页，你为了追求那零点几秒的一致性，堆一堆复杂的同步逻辑，纯粹是给自己找事。

别被“最终一致”的话术忽悠瘸了

很多人说我们不追求强一致，搞最终一致就行。但从来没人仔细算过，这个“最终”到底是多久。

是100毫秒？还是10秒？还是10分钟？

不同的容忍度，对应的方案成本差了十倍都不止。你要是能容忍1分钟的不一致，那干脆给缓存设个1分钟的过期时间，啥主动更新逻辑都不用写，到期了自动回源拿最新数据，成本最低，稳定性还最好。

说实话，很多中小团队的场景，真的没必要搞那么复杂的主动更新机制。我之前接触过一个做本地生活的团队，为了所谓的分布式缓存一致性保障，搭了一整套基于Canal监听数据库binlog的同步框架，光开发就花了三个多月，结果上线之后才发现，他们80%的业务，比如店铺介绍、用户评价这些，本来就不需要实时更新，给个5分钟的过期时间完全够用。最后这套框架的运维成本，每个季度要花两个人天排查同步延迟、消息丢失的问题，算下来还不如直接把所有缓存的过期时间调到5分钟划算。

别贪全。

别过度设计。

很多人遇到缓存一致性问题，第一反应是找个更牛的中间件，搞个更复杂的协议。但实际上，80%的问题，根源都不在技术方案本身，而在你一开始就没跟产品对齐，这个场景到底能接受多大的不一致窗口。你要是连这个数都没搞清楚，上来就硬上强一致方案，最后要么性能垮了，要么成本高到离谱，两边不讨好。

上次那个撸串的朋友，后来把大促期间核心商品的缓存过期时间调到了30秒，删缓存的请求全部走本地重试逻辑，没加额外的MQ组件，连着扛了三次大促，再也没出过价格不一致的问题。