-
我把一个下单操作拆成了先调库存服务扣库存、再调订单服务建订单,本地测试一路绿灯,可上线后偶尔出现库存扣了、订单却没建成,钱货两空、数据对不上,排查半天才明白跨服务的操作根本没有我以为的那种原子性的深度复盘
我做了个下单流程涉及两个独立微服务:库存服务和订单服务,代码很直白——第一步调库存服务扣库存,第二步调订单服务建订单。本地测试两步都顺利,我便觉得天衣无缝。可上线后客服陆续收到投诉:有用户下单失败可库存却被扣了;对账也发现库存扣减记录和实际订单数对不上,有批库存凭空少了却找不到对应订单。翻日志真相浮现:这些异常都是第一步扣库存成功了、第二步建订单失败了(订单服务超时/宕机/网络抖),第一步已实实在…- 4
- 0
-
用户明明改了资料、刷新却还是旧的,排查发现是我更新数据库后顺手更新缓存在高并发下把旧值写回了缓存:一次缓存与数据库双写一致性、Cache-Aside 该删缓存而非更新缓存的深度复盘
我们的用户资料服务为扛读量加了 Redis 缓存,读走缓存未命中查库回填,写用我自以为周到的先更新数据库再顺手更新缓存。功能测着没问题,线上却偶发:用户改了资料、缓存却长期是旧值,刷不新直到过期才好。在并发场景下推演才看明白:更新库和更新缓存两步非原子,两个并发写请求 A、B 都先更库再更缓存,DB 最终是 B 的新值(对),但更新缓存时因线程调度 B 先写、A 后写,缓存被覆盖回 A 的旧值——…- 0
- 0
数据一致性
-
￥优惠劵使用时效：无法使用使用时效：
之前
使用时效：永久有效优惠劵ID：×