大多数系统崩溃并非源于高并发，而是架构层面对一个关键边界条件的忽视：每秒1000次写入的日志系统，在磁盘I/O达到80%时，任何突发流量都可能触发雪崩。这是《系统架构速查手册：精华要点汇总 - 编号117009》最想纠正的认知偏差。

缓存穿透与布隆过滤器的真实代价

某电商大促期间，一个查询商品详情的接口突然飙升到每秒5000次请求，缓存层和数据库层都被打穿。排查发现，攻击者构造了大量不存在的商品ID，这些ID在缓存和数据库中都不存在，每次请求都直击数据库。布隆过滤器被当作银弹引入，但忽略了两个细节：布隆过滤器的误判率在数据量超过预设容量后会急剧上升，从1%飙升到15%，导致大量合法请求也被误拦；而动态扩容布隆过滤器需要重建整个位图，重建期间请求会再次穿透到数据库。最终方案改用Redis的bitmap配合分段滑动窗口，将误判率控制在0.1%以下，同时重建时间从3秒降到200毫秒。

分布式事务的取舍：为什么80%的场景不需要两阶段提交

一家金融公司最初用Seata的AT模式（两阶段提交）处理订单和积分系统的一致性，结果在压测时发现，当订单并发达到3000TPS，积分服务的两阶段准备阶段就要等待2秒，导致数据库连接池瞬间耗尽。实际业务中，积分扣减允许秒级延迟，且很少出现积分系统宕机超过30秒的情况。改用本地消息表+定时任务补偿后，订单写入本地事务，消息表记录积分扣减意图，另一个服务每5秒扫描一次未处理的消息并重试。这个方案下，订单TPS提升到12000，积分最终一致性的延迟不超过10秒，且只有0.03%的补偿记录需要人工介入。

数据库连接池的"最优值"是个陷阱

多数教程告诉你连接池大小设置为“CPU核心数×2+1”，但这个公式只适用于纯计算型任务。在一个典型的Web服务中，每个请求平均等待数据库响应20毫秒，而CPU处理一次请求只需1毫秒。此时连接池大小应该根据“等待时间/处理时间”的比值来推导：假设最大吞吐目标为每秒1000请求，每个请求占用连接20毫秒，那么最小连接池大小应当是1000×0.02=20。实际线上案例中，将连接池从默认的20扩大到50，数据库连接数从500飙升到1250，数据库CPU反而从40%涨到90%，因为上下文切换和锁竞争抵消了并发增益。合理的做法是在20-30之间进行线性压测，找到吞吐量不再增长的拐点。

3条高频踩坑点和修正建议：

• 误区1：用默认超时设置应对所有场景。 连接池超时时间统一设为30秒，结果某次数据库慢查询让所有线程阻塞在等待中。建议：为读操作和写操作分别设置不同的超时时间（读操作500ms，写操作2s），并启用超时熔断，连续5次超时则快速失败返回降级数据。
• 误区2：服务拆分后忽略内部调用链的流量放大。 一个下单接口拆成订单、库存、支付三个服务，每个服务独立限流1000TPS，但下单接口实际会调用三次内部服务，导致总流量放大3倍，限流形同虚设。建议：在网关层设置基于“调用链深度”的限流系数，每多一层内部调用，前端限流阈值降低30%。
• 误区3：监控只关注平均延迟而忽略P99。 平均延迟50ms时，P99可能已经达到800ms，这意味着1%的请求体验极差，且这些长尾请求往往是慢查询或资源争用的早期信号。建议：为每个接口配置P99延迟告警，阈值设为平均延迟的3倍，一旦触发立即排查慢调用堆栈。