架构师面试中，80%的候选人都能熟练画出微服务架构图，但问到"你的服务如何保证数据最终一致性"时，往往只回答"使用消息队列"，却说不清事务消息与本地消息表的区别——这就是架构知识"似懂非懂"的典型症状。

1. 从单体到分布式：必须理清的3个核心取舍

某创业公司早期用单体架构快速验证市场，用户量突破10万后，一次促销活动导致数据库连接池被打满，整个系统宕机4小时。复盘时发现，如果当初在订单和库存模块间引入消息队列做异步削峰，即使库存扣减延迟5秒，用户也能正常下单。这个案例揭示了架构演进的核心矛盾：强一致性带来的是可用性下降，而最终一致性则需配合补偿机制。常见的场景是：用本地消息表+定时任务实现最终一致，远比分布式事务协议（如XA）更实用，尤其当你的数据库不支持全局事务时。

2. 缓存不是"放数据就行"：穿透、雪崩、击穿的实战解法

某电商平台双11大促时，热门商品详情页的缓存失效瞬间，大量请求直接打到数据库，MySQL连接数飙升到上限，导致页面加载耗时从50ms变成12秒。事后分析发现，他们使用了最简单的"过期时间+主动刷新"策略，但没做两件事：第一，对热点key设置随机过期时间，避免集中失效；第二，在数据库层加布隆过滤器，拦截不存在的数据查询。更实用的做法是：用本地缓存（如Caffeine）做一级缓存兜底，即使Redis挂掉，热点数据也能从本地获取，这比单纯依赖Redis的哨兵模式更抗压。

3. 数据库设计最容易被忽视的"隐性成本"：索引失效与查询反模式

某SaaS系统的一张日志表，数据量从100万涨到500万后，一个简单的分页查询从10ms变成了3秒。问题出在开发者用了SELECT * FROM logs WHERE created_at > '2024-01-01' ORDER BY id LIMIT 1000, 20——这种"深分页"导致MySQL需要扫描前1000行再丢弃，而正确的做法是用游标分页（WHERE id > last_id LIMIT 20）。更隐蔽的反模式是：在频繁查询的列上使用函数（如DATE(created_at)），这会让索引完全失效，此时应该考虑使用覆盖索引或生成列来优化。

4. 架构师最常踩的3个误区

• 误区一：盲目追求"高可用"而忽略成本——某团队为内部管理系统的报表功能引入Kubernetes集群，结果每月云服务成本从2000元涨到8000元，而实际上用一台4核8G的云服务器做单点部署，加个定时备份和负载均衡器就足够应对日均1000次查询。
• 误区二：把"技术选型"当成"堆砌新技术"——看到别人用Redis Cluster就盲目跟进，结果业务场景只是简单的KV缓存，单机Redis完全够用，反而因集群的节点通信和槽位迁移增加了运维复杂度。
• 误区三：轻视监控和可观测性——线上出问题时，只能登录服务器看日志，却没有链路追踪和指标监控。正确的做法是：哪怕只部署一个服务，也要加上健康检查接口和关键指标暴露（如请求量、错误率、P99延迟），用Grafana+Prometheus做可视化，成本低但救命。