0002. 引入 Redis 热读缓存

Context

订单详情页与商品页的读流量在促销期间放大了约 8 倍,全部落在 PostgreSQL 主库上,峰值 P99 延迟从 40ms 涨到 600ms。读写分离只能缓解部分压力,热点商品行仍然集中打到一个副本。团队对 PostgreSQL 运维很熟,但缺少专门的缓存层;同时业务能接受商品/订单快照类数据存在秒级的短暂不一致,但下单路径的价格必须始终读权威数据源。

Decision

引入 Redis 作为热读缓存,只缓存"可容忍短暂不一致"的读模型(商品详情、订单快照),采用 Cache-Aside 模式:TTL 60 秒 + 写路径主动失效。下单、支付、改价等强一致路径一律直查 PostgreSQL,不经过缓存。

Consequences

热点读压力从数据库转移到 Redis,P99 预期回落到 100ms 以内;强一致路径语义不变,不需要双写或分布式锁。代价是新增一个有状态组件:需要管理 Redis 的内存淘汰策略、缓存击穿下的单飞(single-flight)保护,以及"写库成功但失效失败"的脏读窗口(靠 TTL 兜底,最长 60 秒)。