ARCHITECTURE WORKBENCH / 01

Redis 引入权衡台

Redis 不是默认答案。调整真实业务约束，观察“读得更快”会换来哪些一致性、容量与故障处理成本。

把业务事实摆上台面

重复读取比例相同数据被反复读取的请求占比 70%

5% 偶发读取95% 明显热点

接口 P95 延迟目标业务真正承诺的目标，不是 Redis 单次耗时 80 ms

20 ms 严苛500 ms 宽松

可接受陈旧时间更新后仍读到旧值，业务最多能忍多久 30 秒

0 秒强一致5 分钟

可用内存预算先给上限，再用压测估算能装下多少热数据 512 MB

64 MB 紧张4 GB 充足

Redis 故障时能否回源绕过 Redis 后，数据库或下游仍能承接受控流量

数据能否从真相源重建例如商品详情可从数据库恢复；一次性令牌通常不能

业务接口收到读写请求

Redis可丢弃的副本

数据库唯一真相源

当前架构建议

热点读取与延迟目标已经形成明确收益，且 Redis 丢失后可以回源重建。让数据库继续做唯一真相源，缓存只保存带 TTL 的副本。

落地边界 先更新数据库，再删除缓存；为 TTL 加随机抖动，并给回源路径设置限流。Redis 命中率下降时，数据库容量必须守得住。