📚 课程目录第2章高频面试问题与回答框架

第2章：同城多活架构与单元化设计

本章聚焦交易系统高可用架构中的核心高频面试题——同城多活与单元化设计。面试官常通过这些问题考察候选人对分布式系统设计、数据一致性、容灾切换的实战经验。回答时需同时体现架构选型逻辑、技术权衡细节以及线上演进策略。

考察点	架构设计能力、对 CAP/多活模式的理解、RTO/RPO 意识、全局 ID 生成 & 单元化数据分片经验
回答框架	1. 分层拆分：接入层（DNS/HTTP 路由）+ 应用层（单元化无状态服务）+ 数据层（单元化分片、仅本单元写）。 2. 核心机制：用户维度 Hash 绑定单元、各单元 DB 独立、跨单元通过 MQ + 对账做最终一致。 3. 容灾切换：心跳检测 + 配置中心切换路由 + 数据库主从切换，控制 RTO < 30s。
示例回答	“我会采用用户 Hash 分片的单元化方案，每个单元包含完整业务栈和私有数据库。接入层根据 userId 路由到对应单元；跨单元数据通过 MQ 异步同步、辅以准实时对账保一致。容灾时配置中心切换路由，DB 跨机房主从切换，使 RTO 控制在 30 秒内。”
可能追问	单元内 DB 写不下的垂直拆分方案？跨单元事务如何处理？如何做全链路压测验证多活？
避坑提醒	🛑 避免只讲概念不提指标（RTO/RPO），面试官期待具体数值和可验证的方案。切忌说“所有单元都写同一条数据”，单元化必须做到写隔离。

考察点	对单元定义的深度理解、数据隔离与扩展性、全链路路由一致性、灰度发布与运维支持
回答框架	1. 单元定义：按用户/商户维度划分，一个单元包含完整的业务服务和存储。 2. 路由层：全链路（网关→服务→DB）保持相同路由策略，避免跨单元调用。 3. 数据扩展：支持水平扩展（增加单元数），单元内可再垂直分片。 4. 运维配套：单元级别的灰度、监控、日志、变更管控。
示例回答	“单元化的核心是‘封闭性’——一个用户的所有写操作在同一个单元完成。我设计时保证网关、RPC、DB 三层路由一致；每个单元拥有独立 DB，跨单元读走统一缓存或异步同步。扩展时整体新增单元并迁移数据，实现近乎线性的容量增长。”
可能追问	单元间数据做汇总分析怎么办？单元内热点用户如何解决？单元扩容的具体流程？
避坑提醒	🛑 切勿忽视“路由一致性”这个关键点。如果服务层路由与 DB 层路由不一致，会导致数据错乱。回答时要强调“全链路统一路由策略”。

考察点	分布式事务方案选型、消息可靠性、对账补偿设计、时效性要求权衡
回答框架	1. 避免强一致：采用本地消息表 + MQ 异步通知，接收方幂等消费。 2. 对账补偿：离线 T+1 对账 + 准实时对账（分钟级），发现不一致自动修复。 3. 兜底策略：设置超时告警，人工介入或自动回滚。
示例回答	“我会优先使用本地消息表 + 可靠 MQ 的方案。发送方在本地事务中写入消息表，异步投递到 MQ；消费端幂等处理。同时增加准实时对账任务，每 5 分钟比对单元间关键字段，一旦不符自动触发补偿或告警，确保最终一致。”
可能追问	消息堆积导致对账延迟怎么办？如何保证幂等？跨单元场景下如何做分布式 ID 防重？
避坑提醒	🛑 不要只提“MQ + 对账”，要说出具体的对账周期、补偿动作（自动冲正还是人工），以及对账文件生成方式。否则显得缺乏落地细节。

维度	同城双活	同城多活（单元化）	异地多活
机房距离	几公里	几公里	跨城上千公里
数据同步	主从复制（同步/半同步）	单元内独立写 + 异步同步	异步复制 + 对账
RTO	秒级	30 秒内	分钟级
RPO	0 ~ 秒级	近 0	秒级 ~ 分钟级
典型场景	金融核心交易	高并发交易系统	全局异地容灾

  💡 面试加分点： 在回答中主动提及 “全链路压测验证” 和 “故障自愈演练”，能体现你有真实的多活落地经验，而非纸上谈兵。