我留国产福利99视频只看一件事,分类栏乱不乱,避坑先看 免费观看-PPTV

去年秋天我手上两个项目，同一个客户（镇江一家三十来人的工业耗材贸易商），同一套业务逻辑——查库存。一个用缓存，一个不用。用缓存的那个，接口平均响应时间是 47ms；不用缓存的，2.1 秒。但是，用缓存的月初对账差了 12 万块钱的账面，客户那边的会计差点要报警。

这事儿让我明白一件事：B2B 软件的缓存，不是在 Web 应用里放个 Redis 就完了。坑全藏在数据一致性里。

从九江到镇江，同一个毛病

先说说这客户的背景。老板姓刘，做工业耗材十几年了，库存 SKU 不到两千个，但每个 SKU 对应四五个供应商的价格、账期、到货周期。他们之前用的进销存是个单机版 Access 库，实在扛不住了，让我们把整个系统搬到 Web 上。

项目分两期。第一期在九江的分仓试跑，我负责后端。那时候还没上缓存，裸查 MySQL，库存接口平均在 1.6 秒到 2.4 秒之间。刘总嫌慢，说“你们这东西比老周那家还慢两倍”。老周是本地另一家软件商，报价比我们便宜一半。为了拿下镇江总部的二期，我决定上缓存。

第一版：全量缓存 + 定时过期

当时想得很简单。库存数据变动频率不高，一天也就三四百次出入库操作。我建了一张 Redis，把“SKU + 仓库”的库存明细按 JSON 字符串整个存进去，过期时间设了 15 分钟。第一次跑，速度直接降到了 200ms 以内。客户很高兴，我也很高兴。

问题出在“其他操作”

第三周，财务对账时发现一笔采购入库被双倍计算了。查了日志才知道：有个采购员在系统里做了入库操作，缓存没清掉，另一个业务员同时查询库存，看到的是旧数据，以为库存够用，就直接开了销售出库单。结果发货时发现实际库存不够，货发了但账面还是平的，月底怎么都对不上。

我一开始以为是缓存过期时间设太长了，改成 5 分钟。但问题照旧。仔细一查，根本不是时间长短的问题——是用户操作顺序。入库操作写 MySQL 成功了，但缓存里的那份数据还保留着上一分钟的版本。如果此时有查询过来，读到的就是脏数据。更麻烦的是，工业耗材的库存变动经常是批量操作，一次导入几百条，缓存还没来得及更新就被别的查询读走了。

换方案：写穿透 + 单条失效

九江那套全量缓存的方案被我否掉了。坦白讲，B2B 的查询模式跟 C 端差别很大。C 端用户查商品详情，同一款 T 恤被几万人查，缓存命中率高，过期几秒钟没什么后果。但工业耗材的库存查询，每笔都直接影响发货和开票，错一个数字就是钱。

具体做法

我把缓存粒度从“全量 JSON”拆成“单条 KV”。每个 SKU 在每个仓库的库存片段独立缓存。写操作（入库、出库、退货）执行时，同时把对应 SKU 的缓存键删掉。查询时如果缓存 Miss，直接读 MySQL 并回填缓存。这样至少能保证：任何一次写之后，下一次查询读到的一定是新的。

代价是查询的 P99 从 47ms 直接涨到了 230ms，但不能跟以前比。以前是可能拿错数据，现在是确定拿到了新数据。客户那边技术负责人姓陈，他说：“慢 200 毫秒我屏幕上看不出来，账错了我要写检查。”

又踩了一个坑：批量操作

写了大概三周，突然某天的库存对账又差了 3 万多。这次排查很痛苦，因为问题不在缓存过期逻辑，而在并发写。采购员导入一个 Excel，里面 600 行入库，事务循环提交。每提交一行就删一次 Redis 缓存键。删除本身很快，但问题是第 500 行提交时，第 533 行的查询已经在读 MySQL 了——MySQL 里刚写了一半的数据，事务还没提交，InnoDB 的 MVCC 让这个查询读到了旧版本。结果就是缓存删了，但回填的仍然是旧数据。

这个场景我承认，我事先没想到。B2B 的批量操作经常是几百上千行，而且常常配单和入库同时进行。我后来把批量写改成了先统一提交 MySQL，等事务结束后一次性批量删除缓存键。但这个操作又引入了新问题：事务期间如果有查询，依旧读旧缓存。好在库存查询对实时性容忍度还算高，事务通常一两秒就结束，用户能接受。如果换成秒杀系统，这条路走不通。

另一种取舍：缓存击穿 vs 脏读，你选哪一边？

写到这儿，我想聊聊选择。很多文章讲缓存的时候喜欢用“银弹”的口气，好像用了 Redis 就万事大吉。我的经验恰恰相反——B2B 软件里的缓存，本质是在性能和数据准确性之间做选择题。你不可能既要 10ms 的响应，又要零脏读。全表扫描慢但准确，缓存快但可能出错。这个矛盾在工业耗材、医药、化工这类有库存成本的行业里尤其尖锐。

我的个人倾向

我现在更愿意往业务层塞逻辑，而不是往缓存层里塞数据。比如库存余量的计算，我宁愿让 MySQL 扛住 2 秒的查询，然后用 SQL 自身的事务隔离级别来保证准确性，而不是在应用层加一层缓存然后花大量精力去维护一致性。当然前提是流量不大。如果一天几十万次查询，那没办法，还是得上缓存。但那就得接受数据短暂的不一致，并且要在业务流程中设计兜底——比如出货前强制刷新一次库存、或者允许人工锁定库存。

说一个我不喜欢的做法

我不喜欢把缓存数据放在 Elasticsearch 里再套一层。之前在另一个项目（西宁有个做轴承分销的客户）碰过，他们用了 ES 做库存搜索引擎，再加 Redis 做热缓存。结果三个数据源之间互相打架：MySQL 显示 200 件，ES 显示 185 件，Redis 显示 210 件。出库单因为库存数据不一致被系统拦截，仓库那边打爆了客服电话。后来我花了一周时间把三套同步逻辑重写，其实业务上根本不需要 ES，MySQL 的全文索引用好了完全够用。那个客户现在还在用，没出过问题。

清零与重建

最后聊点业务上的。镇江那个客户的项目，二期上线后稳定跑了四个月。我留了个定时任务：每天凌晨三点，把全量缓存重建一次。重建期间有 30 秒左右的服务暂停，我借口“维护窗口”写进了合同。说实话这个方案很粗糙，但客户接受了，因为他们那个时段的订单很少。

这不是最优解。如果是高可用场景，30 秒都不行。但既然是给同行做外包，我的原则是：方案可以丑，但要能落地，要能解释得清边界。你告诉客户“缓存能让你快 10 倍”，但没告诉客户“偶尔会读到旧数据”，后面麻烦都是你的。

有一次跟一个在广元做同行的朋友喝酒，他说他干过更绝的：把缓存全关了，直接用 MySQL 的查询缓存（Query Cache）。我说那玩意儿 8.0 之后不是废弃了吗？他说对啊，项目跑在 5.7 上，他们怕换成应用层缓存出问题，干脆不升级。听起来很离谱，但人家也稳稳当当跑了两年。有时候，不折腾就是对的。