# 1. 幂等键（Idempotency Key）模式中接口层用请求唯一标识实现幂等的通用框架？ A 幂等键由服务端生成，每次请求都不同 B 幂等键只用于 GET 请求的缓存 C 服务端用唯一约束 + 结果缓存，保证同一键的重复请求返回一致结果 ✓ 正确答案 D 幂等键记录不需要清理，可以永久保留
# 2. Strangler Fig 的切流策略中路由层按比例切流、双写与影子流量如何降低风险，回滚条件与数据一致性窗口如何设计？ A 一次性把全部流量切到新系统，避免中间状态 B 影子流量把真实请求复制给新系统但不返回结果，用于验证 ✓ 正确答案 C 双写是让新旧系统只读，不写任何数据 D 回滚条件只需看延迟，不看错误率
# 3. 分布式追踪中 traceId/spanId 如何跨服务传播，采样策略与 W3C trace context 的作用 A 每个服务生成独立的 traceId，互不关联 B span 通过 parentSpanId 形成树形结构，traceId 贯穿整条调用链 ✓ 正确答案 C 全量追踪开销很小，无需采样 D W3C trace context 只用于单机调用，不跨服务
# 4. 配置中心与动态刷新中配置变更如何灰度发布与回滚，监听推送 vs 客户端轮询的实现差异 A 配置变更必须重启应用才能生效 B 灰度发布只适用于代码，不适用于配置 C 配置中心无法回滚，只能手工改回 D 推送方式实时性好但需维持长连接，轮询方式简单但实时性差 ✓ 正确答案
# 5. Saga 在订单场景的落地中下单 Saga 的步骤与补偿顺序如何设计（扣库存→扣款→失败回滚），超时与重试如何配置？ A Saga 用单一分布式事务保证强一致 B 失败时按执行顺序回滚补偿，而不是逆序 C Saga 步骤失败后无需清理已扣的库存 D 补偿操作按逆序执行，且每步需幂等 ✓ 正确答案
# 6. 分布式锁的租约与看门狗续期中锁过期后必须用 fencing token 防止旧持有者写入，Redlock 的争议点是什么？ A 看门狗在锁过期后释放锁，防止续期 B 锁过期后旧持有者可以继续正常写入，无需隔离 C Redlock 完全不受时钟漂移影响，无争议 D fencing token 是单调递增版本号，可防止过期持有者写入共享资源 ✓ 正确答案
# 7. Event Sourcing 的投影与重放中如何从事件流构建读模型，快照（snapshot）如何降低重放成本，事件版本化如何处理？ A 快照保存当前状态，重放时从最近快照开始，降低重放成本 ✓ 正确答案 B 事件流是可变数据，可随时修改 C 事件重放从最新事件开始，往前累加 D 事件一旦发布就无法处理版本演进
# 8. 编排式（Orchestration）Saga 的控制器中如何集中维护各步骤状态并决定补偿顺序，与工作流引擎（Temporal）的关系？ A 编排器由各个服务各自维护自己的状态，无中心协调 B 编排器集中维护步骤状态，失败时决定并执行补偿顺序 ✓ 正确答案 C 补偿顺序由在失败步骤之后的服务决定 D 工作流引擎与编排式 Saga 无关
# 9. Outbox 模式的发布机制中轮询发布与 CDC（Debezium）的差异，事件表的分区/索引与清理，重复发布如何靠幂等消费兜底？ A 业务表与 outbox 表在不同事务中写入，保证原子性 B CDC 通过监听 binlog 捕获 outbox 插入，实时性好但引入组件复杂度 ✓ 正确答案 C outbox 事件表不需要清理，可以无限增长 D 发布后事件不会重复，消费者无需幂等
# 10. 两阶段提交与 Saga 的适用场景中强一致 vs 最终一致业务的取舍？ A 2PC 保证强一致但存在阻塞问题，Saga 保证最终一致但更灵活 ✓ 正确答案 B Saga 保证强一致，2PC 保证最终一致 C 2PC 永不阻塞，性能最好 D 两者都适用于强一致业务
# 11. Sidecar 模式中服务网格中数据面代理的部署与配置同步机制？ A 服务网格中 sidecar 通过 xDS 从控制面获取配置并增量更新 ✓ 正确答案 B sidecar 部署在独立主机上，与业务容器不共享网络 C sidecar 只能用于日志收集，不能承载流量 D 业务代码必须修改才能使用 sidecar
# 12. 多活与容灾中同城双活与两地三中心的复制拓扑、故障切换与数据丢失窗口 A 两地三中心中异地中心始终承载读写流量 B 异地中心使用同步复制以保证 RPO 为 0 C 同城双活通过同步复制实现 RPO 接近 0 ✓ 正确答案 D RTO 指的是数据丢失量，与切换时间无关
# 13. 分布式任务调度中分片、抢占与幂等如何配合，为什么调度器本身不能成为单点 A 分片让任务在单个节点上顺序执行 B worker 崩溃后任务无需重新调度 C 任务重复执行无需幂等，因为 failover 保证不重复 D 调度器通过 leader 选举与状态持久化避免单点故障 ✓ 正确答案
# 14. CQRS 的读写分离中命令侧写聚合、查询侧用读模型，投影（projection）如何异步更新读模型，与 Event Sourcing 的组合方式？ A CQRS 用同一个模型同时处理读写 B 投影器订阅事件流异步更新读模型，实现最终一致 ✓ 正确答案 C 命令侧直接写入读模型，保证强一致 D CQRS 与 Event Sourcing 无法组合
# 15. BFF 模式的职责中移动端/Web 端需要各自后端聚合接口，BFF 如何做认证与裁剪，与 API Gateway 的边界？ A 所有前端共用同一个后端聚合接口 B BFF 为特定前端聚合数据，并做认证与响应裁剪 ✓ 正确答案 C API Gateway 负责业务数据聚合，BFF 负责路由鉴权 D BFF 与 API Gateway 职责完全相同，可以互相替代
# 16. 协同式（Choreography）Saga 的事件链中事件驱动如何解耦服务，故障定位为何更难，如何用事件追踪与幂等消费兜底？ A 协同式 Saga 依靠中心协调器统一调度 B 服务间通过事件链协作，耦合低但故障定位更难 ✓ 正确答案 C 事件链中每个服务无需关心事件是否重复 D 协同式 Saga 没有补偿机制，失败即停止
# 17. 分布式锁的正确性中锁续期（watchdog）、fencing token 与可重入在分布式锁中的边界？ A 可重入锁允许任意线程释放锁 B fencing token 用于在锁内做重入计数 C watchdog 定期续期，保证持锁线程运行期间锁有效 ✓ 正确答案 D 锁过期后旧持有者仍可正常写入，无需隔离
# 18. Leader 选举的租约机制中 etcd 或 ZooKeeper 的临时节点加会话超时如何实现故障转移，脑裂时如何保证单一领导？ A ZooKeeper 用临时节点 + 会话超时，Leader 崩溃后会话超时自动让位 ✓ 正确答案 B 会话超时后临时节点永久保留，其他节点无法竞选 C 脑裂时每个分区都能成为独立 Leader D Leader 不需要心跳续约，会话永不超时
# 19. Sidecar 与 Ambassador 中服务网格边车代理与 API 网关的部署位置与职责差异？ A Ambassador 与业务服务同部署，每服务一个 B Sidecar 独立部署在服务之外，作为统一入口 C Sidecar 管服务间东西向流量，Ambassador 管南北向外部流量 ✓ 正确答案 D 两者的职责完全相同
# 20. CQRS 与事件溯源中读写模型分离的扩展性收益与最终一致性的代价？ A 事件流无法重放重建读模型 B 事件溯源让读模型与写模型强一致，无延迟 C 投影是同步阻塞的，读操作必须等待写完成 D 读写模型可独立扩展，但读模型与写模型存在最终一致窗口 ✓ 正确答案
# 21. 密钥管理中 Secret 的集中存储与自动轮换如何避免硬编码，轮换期间新旧密钥如何共存 A 密钥应硬编码在代码中，方便调用 B 轮换时立即删除旧密钥，防止泄露 C 集中存储把密钥从代码抽离，轮换期间新旧密钥共存以保证平滑过渡 ✓ 正确答案 D 密钥只需定期人工更换，无需自动轮换
