2023年某电商大促期间，一个日活千万的资讯App因缓存层设计缺陷，导致核心推荐接口响应延迟从15ms飙升到2.3秒，直接损失超过400万GMV——事后复盘发现，问题出在架构师对“全链路幂等”的假设错误，而这不是个例。

缓存策略里最容易翻车的两种模式

很多团队在初期会选择“旁路缓存”（Cache-Aside），即先读缓存，未命中再查库并回写。但遇到高并发写入时，这个模式会频繁出现“缓存击穿”——某个热点Key突然失效，几千个请求同时穿透到数据库。去年某在线教育平台就是因此导致MySQL连接池瞬间打满，数据库宕机6分钟。更稳妥的做法是加“互斥锁”或改用“读穿/写穿缓存”（Read/Write Through），让缓存层自己负责数据加载，但代价是缓存组件自身需要支持高可用和哨兵机制。

服务拆分后的“数据一致性”陷阱

微服务化之后，最常踩的坑是“跨服务事务没有兜底”。比如用户下单后，订单服务调用库存服务扣减库存，再调用积分服务加积分。如果积分服务调用超时，订单服务直接回滚，但库存已经扣了——最终库存和订单状态不一致。实际场景里，某出行平台的拼车订单就因为这个逻辑导致超卖2000单。解决方案是引入“本地消息表+定时任务”或者“事务性消息”（如RocketMQ的事务消息），保证最终一致性，而不是死磕强事务。

限流与熔断的“阈值幻觉”

大多数团队会把限流阈值设成“预估峰值的120%”，但忽略了一个事实：流量不只有水平增长，还有突发脉冲。比如某社交App的Feed流接口，平时QPS是800，活动期间瞬时冲到5000，而限流阈值设成960（800*1.2），结果直接打挂上游网关。正确的做法是同时设置“滑动窗口限流”和“漏桶/令牌桶”，并且对每个下游依赖单独配置熔断阈值。例如，对Redis超时的熔断阈值设为5秒内超过20次异常就断开，而不是等到整个服务线程池占满。

三个最常踩的误区与具体应对

• 误区一：把所有层都做高可用就万事大吉。真实情况是，链路越长，故障点越多。建议优先对“用户感知最明显”的接口做降级预案（比如首页Feed、支付回调），其他非核心功能允许降级。
• 误区二：分布式锁只用Redis就能搞定。Redis分布式锁在Master节点宕机时可能丢失锁，导致重复执行业务逻辑。至少用RedLock或切换到ZooKeeper这类强一致性组件，并加上“锁超时自动续期”机制。
• 误区三：监控只关注平均响应时间。平均值会掩盖长尾请求。必须监控TP99和TP999，对超过500ms的请求单独打日志，并设置告警——某金融App就是靠抓TP999异常定位到数据库连接泄漏问题。