10 道架构师 / 高级开发面试题・逐题完整版高分答案风格：面试官最爱、逻辑严谨、可直接背诵、自带亮点

1. 微服务架构核心设计原则、服务拆分标准、难点

考察点：架构认知、DDD、边界设计、分布式治理

高分回答：

1. 微服务核心设计原则

• 单一职责：一个服务只做一件事，职责内高内聚。

• 自治独立：独立部署、独立数据库、独立技术栈，不强依赖其他服务。

• 轻量级通信：HTTP/REST 或 gRPC，避免重型 RPC。

• 去中心化：去中心化数据、去中心化治理，避免中心化单点。

• 高可用容错：熔断、降级、隔离，支持部分失败。

• 自动化：CI/CD、自动化测试、容器化部署。

2. 服务拆分标准（实战）

• 按业务域拆分（DDD 领域驱动）：用户域、订单域、支付域、商品域。

• 按变更频率拆分：频繁变动 vs 稳定模块分离。

• 按团队组织拆分：康威定律，组织沟通结构 = 系统架构。

• 按数据读写分离：查询多、写多分离。

3. 拆分难点

• 边界模糊：如订单和商品、订单和支付互相交织。

• 分布式事务：跨服务数据一致性。

• 联调复杂度：链路变长、排查困难。

• 过度拆分：服务太多，运维、性能、调用成本剧增。

• 共享数据、公共耦合：字典、配置、用户信息等。

总结：拆分遵循「高内聚低耦合」，优先 DDD 领域边界，不追求绝对细，追求业务清晰、可独立演进。

---

2. CAP 定理与 BASE 理论，业务如何取舍？

考察点：分布式理论根基、架构取舍能力

高分回答：

1. CAP 定理分布式系统无法同时满足：

• C（一致性）：所有节点同一时间数据一致。

• A（可用性）：服务一直可用，响应正常。

• P（分区容错）：网络分区仍可运行。结论：分布式下 P 必须保证，只能在 CP 或 AP 之间选。

2. BASE 理论（对 CAP 的落地补充）

• Basically Available（基本可用）：允许部分降级、流量削峰。

• Soft state（软状态）：允许中间状态、异步同步。

• Eventual consistency（最终一致性）：数据最终一致，不要求强一致。

3. 业务取舍

• CP 场景：支付、交易、金融、库存扣减。需要强一致，宁可短暂不可用。

• AP 场景：首页、商品列表、评论、点赞。追求高可用，允许短暂不一致。

总结：互联网绝大多数业务选 AP + 最终一致性，核心链路用 CP 或分布式事务保证。

---

3. 缓存穿透、击穿、雪崩，完整解决方案

考察点：高并发、缓存设计、实战方案

高分回答：

1. 缓存穿透

• 现象：查询不存在的数据，缓存不命中，直接查 DB，流量打垮库。

• 方案：

1. 缓存空值：不存在也缓存空值，设置短过期。

2. 布隆过滤器：提前过滤不存在的 key。

3. 参数合法性校验。

2. 缓存击穿

• 现象：热点 Key 过期，大量并发同时击穿到 DB。

• 方案：

1. 互斥锁（Redisson lock）：只允许一个线程重建缓存。

2. 热点 Key 永不过期，后台异步更新。

3. 过期时间随机打散，避免集体失效。

3. 缓存雪崩

• 现象：大量 Key 同一时间过期 / Redis 宕机，全部请求到 DB。

• 方案：

1. 过期时间 随机 + 错开。

2. 集群高可用：主从、哨兵、集群。

3. 多级缓存：本地缓存 (Caffeine) + Redis。

4. 限流、熔断、降级。

5. 缓存预热。

---

4. 分布式事务方案：2PC、TCC、SAGA、可靠消息

考察点：一致性方案、场景选型、架构权衡

高分回答：

1. 2PC（两阶段提交）

• 角色：协调者 + 参与者

• 阶段：准备阶段、提交 / 回滚阶段

• 优点：强一致。

• 缺点：同步阻塞、协调者单点、性能差。

• 适用：短事务、低并发、数据库级（Seata AT 模式）

2. TCC（Try-Confirm-Cancel）

• Try：资源预留、冻结。

• Confirm：确认执行。

• Cancel：释放预留。

• 优点：性能高、不锁库。

• 缺点：代码侵入高，需实现幂等、防悬挂。

• 适用：订单、支付、库存 核心交易。

3. SAGA 长事务

• 把大事务拆成多个小事务 + 补偿回滚。

• 适用：长流程、跨多系统、异步（物流、审批、分销）。

4. 可靠消息最终一致性（RocketMQ / 本地消息表）

• 本地事务 + 消息发送保证原子性。

• 消费方幂等去重。

• 适用：非强一致、高吞吐（通知、积分、日志）

选型总结：

• 强一致、简单：Seata AT(2PC)

• 高性能、核心交易：TCC

• 长流程、多系统：SAGA

• 高吞吐、最终一致：可靠消息

---

5. MySQL 索引（B + 树）、最左匹配、索引失效、分库分表

考察点：数据库底层、性能优化、海量数据架构

高分回答：

1. 为什么用 B+ 树

• 多路平衡查找树，磁盘 IO 少。

• 叶子节点形成有序链表，范围查询极快。

• 非叶子不存数据，只存键，树更矮。

2. 最左匹配原则

• 联合索引 (a,b,c)，必须从左开始连续匹配。

• 有效：a、a+b、a+b+c。

• 失效：b、b+c、c 等跳过左边列。

3. 索引失效场景

• 索引列运算、函数、类型隐式转换。

• !=、not in、is null /not null（有时失效）。

• like '% xx' 左边模糊。

• 联合索引不满足最左。

• MySQL 优化器认为全表更快。

4. 分库分表

• 垂直分库：按业务拆（用户库、订单库）。

• 垂直分表：大字段、冷热字段拆分。

• 水平分表：按 userId、orderId 哈希取模 / 范围。

• 问题：跨库分页、排序、join、分布式 ID、事务。

• 中间件：Sharding-JDBC、MyCat。

6. 高可用：熔断、降级、限流、重试、幂等

考察点：系统容错、稳定性设计、Sentinel 落地

高分回答：

1. 熔断

• 失败率达到阈值，暂时切断调用，快速失败。

• 状态：关闭 → 打开 → 半开。

• 框架：Sentinel、Hystrix、Resilience4j。

2. 降级

• 压力过大时，非核心功能关闭，保证核心可用。

• 如：关闭推荐、评论、头像、活动弹窗。

3. 限流

• 控制 QPS，保护系统不被打垮。

• 算法：令牌桶、漏桶、滑动窗口。

• 位置：网关层、API 层、服务层。

4. 重试

• 只对幂等接口重试。

• 策略：间隔重试、次数限制、熔断重试。

5. 幂等

• 多次请求结果一致。

• 方案：

1. 唯一键约束

2. 分布式锁（Redis/Redisson）

3. 状态机判断

4. 全局唯一请求号 + 去重表

总结：限流防流量激增、熔断防级联失败、降级保核心、重试提高可用、幂等保证安全。

7. MQ 消息丢失、重复、顺序、积压解决方案

考察点：异步架构、可靠性、生产实战

高分回答：

1. 消息丢失

• 生产者：confirm 机制，确认发送成功。

• Broker：开启持久化、集群、同步刷盘。

• 消费者：手动 ACK，业务成功再确认。

2. 重复消费

• MQ 只能保证 至少投递一次。

• 解决：消费端幂等（唯一 ID、分布式锁、状态判断）。

3. 顺序消费

• 保证：相同 key（如 orderId）hash 到同一个队列。

• 消费者单线程消费该队列。

4. 消息积压

• 原因：消费慢、下游阻塞、堆积过多。

• 方案：

1. 增加消费者线程 / 实例。

2. 批量消费。

3. 临时扩容队列数。

4. 过滤非核心消息、异步化。

5. 死信队列处理失败消息。

8. 常用设计模式 + 架构场景

考察点：代码抽象、可扩展性、架构思维

高分回答：

1. 单例模式：工具类、配置类、线程池、连接池。保证全局唯一。

2. 工厂模式：屏蔽对象创建复杂逻辑，如支付渠道工厂（微信 / 支付宝 / 云闪付）。

3. 策略模式：替换 if-else，如不同优惠、不同校验规则、不同序列化方式。

4. 模板方法：固定流程骨架，子类实现细节（如订单创建通用流程）。

5. 装饰器模式：动态增强功能，如缓存、日志、限流增强。

6. 观察者模式：事件驱动、消息通知、订单状态变更。

7. 责任链模式：审批流、风控校验、过滤器链。

8. 建造者模式：复杂对象构建，如请求参数、DTO。

亮点回答： 我在项目中大量用 策略 + 工厂 + 模板 消灭臃肿 if-else，让系统易扩展、符合开闭原则。

9. 单体 → 微服务 常见坑与规避

考察点：架构演进、实战踩坑、决策能力

高分回答：

1. 过度拆分

• 坑：服务太多、调用链长、性能差、运维爆炸。

• 规避：先按大领域拆，不追求过细。

2. 分布式事务滥用

• 坑：强行追求强一致，性能差、复杂度高。

• 规避：能最终一致不用强一致。

3. 分布式追踪缺失

• 坑：出问题无法定位。

• 规避：SkyWalking/Pinpoint，全链路压测。

4. 联调、测试、部署复杂

• 规避：Mock、文档、网关统一入口、CI/CD、容器化。

5. 分布式会话、登录状态

• 解决方案：JWT、Redis Session 共享。

6. 日志分散

• ELK、Loki 统一日志。

总结：微服务不是银弹，业务稳定、团队能力、基础设施 到位再拆。

10. 线上性能瓶颈定位（CPU、内存、IO、锁、GC）

考察点：线上排查、JVM、Linux、真实架构能力

高分回答：标准排查流程：监控 → 定位进程 → 定位线程 → 看栈 / GC / 堆 / 磁盘

1. CPU 高

• top 查看 CPU 高的进程 PID。

• top -Hp PID 定位高耗 CPU 线程。

• jstack 打印线程栈，找到死循环、频繁 GC、大量计算。

2. 内存溢出 / 泄漏 OOM

• jmap dump 堆 dump 文件。

• MAT/JVisualVM 分析：大对象、集合未释放、静态缓存。

• 检查：线程池、连接池、本地缓存、Bean 生命周期。

3. IO 高（磁盘 / 网络）

• iostat、iotop 查看磁盘等待高。

• 原因：大量日志、慢 SQL、文件读写、网络阻塞。

4. 死锁、锁竞争

• jstack 直接查看死锁。

• 大量 BLOCKED 线程：锁竞争激烈，改用分段锁、无锁、Redisson 锁优化。

5. GC 频繁

• jstat -gc 查看 YGC/FullGC 频率。

• 原因：堆太小、大对象、内存泄漏、新生代比例不合理。

• 调整：Eden 区、晋升阈值、CMS/G1 调优。

工具总结：

• Linux：top、iostat、netstat、dstat

• JVM：jps、jstack、jmap、jstat

• 诊断：Arthas（最常用）、SkyWalking、Prometheus + Grafana