超过80%的线上故障源于系统架构设计阶段未考虑边界条件，而非代码实现失误——这是Netflix工程团队在分析2万起生产事件后得出的结论。

限流熔断：不是越强越好，而是匹配业务水位

某电商平台在双十一前将限流阈值统一提升300%，结果导致下游库存服务因瞬时流量冲垮，反而比未调整时多损失2000万订单。正确的做法是：根据核心链路与旁路逻辑分别设定阈值。例如，用户登录接口可容忍1秒延迟，但支付接口需在200毫秒内响应。建议使用滑动窗口算法替代固定计数器，避免毛刺流量导致误触发。

数据库分片：按热度分库比按取模分片更抗冲击

一家社交APP早期按用户ID取模分64库，结果某明星入驻后其粉丝涌入单个热点库，导致该库CPU飙升至95%。改用按用户活跃度分片后，将头部1%用户独立部署到高配集群，普通用户按区域分片，整体查询延迟下降73%。注意：分片键需避免使用自增ID，否则写入压力会集中在末位节点。

异步消息：重复消费比丢失消息更可怕

某物流系统使用RabbitMQ传输运单状态，当消费者异常重启后，同一批运单被重复处理导致出现50万条重复数据。最终方案是：在消息体中嵌入全局唯一ID，消费者侧用Redis做幂等校验（SETNX+过期时间），而非依赖消息队列自身的去重机制——因为多数消息队列的at-least-once语义会天然产生重复。

• 误区一：直接使用默认配置部署Nginx/Tomcat。应至少修改：worker_connections不超过系统ulimit值，Tomcat的maxConnections需与数据库连接池匹配，否则高并发下会雪崩。
• 误区二：全量接口统一加50毫秒超时。应区分读接口（如200毫秒）、写接口（如1秒）、批量接口（如3秒），超时时间过长会耗尽线程池。
• 误区三：用ZooKeeper存储业务配置。ZK不适合高频读写（超过1000次/秒的写操作会导致集群抖动），业务配置建议用etcd或配置中心。