系统架构设计里，90%的线上故障都源于对“时间”和“空间”两个维度的误判：要么高估了单机的处理能力，要么低估了数据累积后的复杂度。以下三点知识是架构师必须刻进骨子里的硬技能。

1. 缓存穿透与击穿的防御边界：别指望Redis万能

很多团队在业务初期喜欢把所有查询结果都塞进Redis，以为这样就能一劳永逸。真实场景是：某电商平台在大促期间，用户疯狂查询一个不存在的商品ID（穿透），导致缓存层直接失效，所有请求瞬间打到MySQL，数据库连接池耗尽。更隐蔽的是击穿——热点Key刚好在更新时过期，瞬间流量涌入。正确的做法是在缓存层加布隆过滤器拦截恶意ID查询，同时用互斥锁（如Redisson分布式锁）控制击穿时的重建流程，而不是无脑设置“永不过期”去掩盖问题。

2. 分布式事务的取舍：强一致性不是银弹

某支付系统曾要求转账、积分、通知三个服务必须“同时成功”，于是上了Seata AT模式做全局事务，结果业务高峰期出现大量锁等待和超时回滚，用户卡在支付页面长达5秒。实际上，金融业务中用户更在乎最终结果而非瞬时状态：支付成功后发送积分这个动作完全可以接受最终一致性。架构师必须清楚，TCC（Try-Confirm-Cancel）模式适用于短事务且资源冲突少的场景；而SAGA更适合长流程，哪怕中间步骤失败也能通过补偿事务兜底。如果业务允许，用本地消息表+定时任务去异步削峰，比硬扛分布式事务要稳定得多。

3. 数据库分库分表的隐性成本：跨库查询是毒药

不少团队在用户量涨到百万级时，拍脑袋按用户ID哈希分16个库，结果运营部门需要按“注册时间”做批量导出，发现所有库都要扫一遍，慢查询把整个集群拖垮。分库分表最大的坑是以为“层面拆分”能解决所有问题，实际上查询范式被彻底破坏：跨库聚合只能用中间件做归并（如ShardingSphere），但排序、分页、关联查询会变成灾难。真正的做法是先做垂直拆分（按业务分模块数据库），再视情况做水平拆分，且拆分前必须定义好“全局查询”的兜底方案——比如提前离线同步一份ES或ClickHouse给运营查询用，或者干脆设计成限时查询避免全表扫描。

结尾：3条架构师最容易踩的坑

• 别信“自动扩容”能救火：大多数云原生自动扩缩容都有延迟（至少3-5分钟），高峰期爆发时瞬间流量已经冲垮节点。必须提前做容量评估和限流降级，比如用Sentinel配置QPS阈值，超过就返回友好提示，而不是让系统死扛。
• 别把“读写分离”当成万金油：主从同步有延迟，如果业务刚写入就要求立刻读（如支付后展示余额），必须强制读主库或引入缓存层写后即读，否则用户会看到“已扣款但余额未变”的诡异现象。
• 别忽略监控的“业务语义”：只看CPU、内存这些系统指标没用。真正的故障往往出在业务指标上——比如“下单成功率突然跌到50%”比CPU飙到90%更早暴露问题。必须埋点记录每个接口的响应时间分布（P99、P999），以及关键业务流程的失败率。