设计一个高并发商品详情服务，缓存、数据库和变更消息之间的一致性怎么保证？
我的判断
商品详情以数据库为权威，缓存承担读性能；更新通过事务后失效和可靠事件收敛，结算等关键链路再次校验权威值。
读链路会做多级缓存：热点基础信息可放短 TTL 本地缓存，完整详情放 Redis，miss 后查询数据库并通过单飞加载限制同 key 回源并发。缓存 value 带商品版本，TTL 加抖动，避免批量同刻失效。
写链路采用 cache-aside：数据库事务提交后发布 outbox/binlog 事件，消费者删除或刷新 Redis，再通知本地缓存失效。删除失败会重试并告警，定期对账版本。不会在数据库事务里同步调用缓存，把缓存故障扩大成写事务失败。
并发读写仍可能把旧值回填，所以回填使用读取到的版本，发现缓存已有更高版本就拒绝覆盖；或者更新后做一次延迟失效收敛竞态。
降级边界按字段定：商品描述可以短暂旧，价格展示允许几秒窗口，但创建订单和结算必须向价格/库存权威服务再次确认。这样即使缓存短暂不一致，也不会造成实际错价成交。
思路拆解问题分析
设计一致性时先回答三个问题：谁是权威源、允许多长旧值窗口、哪一步必须强校验。 没有这三个边界，所谓“双删、延迟队列、订阅 binlog”只是方案清单。
容易答偏踩坑误区
- 数据库和缓存同步双写。 任一边失败都会留下不一致。
- 缓存故障时所有请求回源。 必须有限流、旧值或降级。
- 展示缓存直接作为结算价格。 关键交易动作要重新校验。