# 1. Saga 模式的编排与协调中编排式（Choreography）vs 协调式（Orchestration）的适用场景、补偿事务的幂等性设计、与 Outbox 模式的组合保证最终一致性、长事务超时与部分失败的处理 A 编排式有中央协调器，便于集中回滚；协调式完全去中心化 B Orchestration 因为去中心化所以性能必然优于 Choreography C Choreography 通过事件驱动服务间协作，无中央单点，但流程隐式、难以全局回滚 ✓ 正确答案 D Saga 模式能够提供完整的事务隔离性（Isolation）
# 2. 数据一致性的会话保证中读己之写（read-your-writes）与单调读如何在多副本读取时实现，为什么 AP 系统需要粘性会话？ A 单调读要求用户一定能读到刚写入的数据 B 粘性会话把同一用户请求固定到同一副本，从而缓解 AP 系统的读己之写与单调读问题 ✓ 正确答案 C 读己之写与单调读是同一概念，没有区别 D 粘性会话会显著提升负载均衡的均匀性
# 3. Quorum 读写与读修复中写 W 读 R 且 W+R>N 能保证读到最新，read repair 与 hinted handoff 如何补一致性 A 只要 W+R=N 就能保证读到最新数据 B read repair 不能纠正过期副本，只能靠后台修复 C W+R>N 时读集合与写集合必有交集，从而保证读到最新写入 ✓ 正确答案 D hinted handoff 是用于强化读一致性的手段
# 4. 网关、BFF 与 Service Mesh 的分工中三层在协议转换、聚合裁剪、流量治理上的职责边界与重叠 A Service Mesh 负责业务聚合与裁剪，BFF 负责服务间 mTLS B 三者职责完全相同，可任意替换 C BFF 面向特定前端做聚合裁剪，Service Mesh 治理服务间通信流量，网关做统一切口 ✓ 正确答案 D 网关只做流量治理，不做协议转换
# 5. CQRS 在订单、库存、查询分离的读写模型与同步机制。 A 读模型由事件投影异步更新，通常是最终一致而非强一致 ✓ 正确答案 B 写模型与读模型必须使用同一个数据库 Schema C CQRS 一定要求强一致，否则无法使用 D 读模型不需要针对查询优化
# 6. BFF（Backend for Frontend）在多端差异化、聚合、协议转换的边界设计。 A BFF 只做针对特定前端的数据聚合、裁剪与协议适配，不复制后端业务逻辑 ✓ 正确答案 B BFF 应承载完整的业务规则与事务逻辑 C BFF 与后端服务一一对应，数量必须等于微服务数量 D BFF 只能用于移动端，不能用于 Web
# 7. Event Sourcing 在金融、审计、协作的事件溯源与快照机制。 A 快照用于减少重放成本，重放时从最近快照开始并只重放其后的事件 ✓ 正确答案 B 事件是可变的，允许修改历史事件 C Event Sourcing 无法支持审计与回放 D 快照一旦创建就永久固定，不会更新
# 8. Outbox/Inbox 模式在可靠消息、本地表 + 发布器的设计。 A Outbox 表与业务数据写在不同事务，才能保证可靠 B Outbox 模式能保证消息恰好投递一次 C Inbox 模式用于让消息发送不重复 D Outbox 在本地事务内同时写业务数据与待发送消息，由发布器投递，保证业务提交与消息产生原子一致 ✓ 正确答案
# 9. CAP 定理的工程实践含义中网络分区不可避免时 C 与 A 的取舍、PACELC 扩展（无分区时 Latency vs Consistency）、CP 系统（ZooKeeper/etcd）与 AP 系统（Eureka/Cassandra）的典型场景选择 A 分布式系统可以同时完美满足 C、A、P 三者 B ZooKeeper 是 AP 系统，Eureka 是 CP 系统 C 网络分区不可避免，分区时需在 C 与 A 之间取舍；PACELC 补充了无分区时 L 与 C 的权衡 ✓ 正确答案 D PACELC 与 CAP 完全无关，是错误的扩展
# 10. 一致性哈希与服务发现中注册中心如何配合一致性哈希实现路由与故障转移？ A 一致性哈希在节点增减时会导致所有数据重新映射 B 一致性哈希把数据哈希到环上顺时针取节点，节点增减只影响少量数据迁移，并可用虚节点平衡分布 ✓ 正确答案 C 一致性哈希不能用于故障转移 D 注册中心与一致性哈希无关
# 11. 写冲突解决中 LWW（last-write-wins）对时钟的依赖与版本向量（vector clock）如何检测并发更新 A 版本向量通过比较各节点版本分量，能识别两个写入是否并发 ✓ 正确答案 B LWW 不依赖时钟，任何情况下都不会丢数据 C 版本向量不会随节点数增长而增大 D LWW 在时钟漂移时依然能正确判定先后顺序
# 12. Service Mesh Sidecar 模式（Envoy/Istio）中数据面与控制面的职责分离、mTLS 自动证书轮换、流量镜像与故障注入、sidecar 资源开销与 eBPF-based mesh（Cilium）的无 sidecar 替代 A 控制面负责数据转发，数据面负责配置下发 B eBPF 方案也依赖 sidecar 进程，无法消除 C mTLS 证书必须人工轮换，无法自动 D 控制面负责策略与证书管理，数据面（sidecar）负责流量转发、mTLS 与可观测性 ✓ 正确答案
# 13. gRPC vs REST 的选型标准中 protobuf 的 schema 演进（向后兼容规则）、HTTP/2 多路复用与流式调用、浏览器兼容性限制、调试可观测性（grpcurl/反射服务）、在内部服务间优先 gRPC 而对外 API 用 REST 的分层策略 A protobuf 字段编号可以随意修改，不影响兼容性 B REST 只支持 HTTP/1.1，不支持 HTTP/2 C gRPC 无法提供调试观察性，只能手工模拟 D gRPC 基于 HTTP/2 支持多路复用与流式，但浏览器默认无法直接调用，故内部服务间用 gRPC、对外用 REST 是常见策略 ✓ 正确答案
# 14. 服务发现的健康检查中为什么 TTL 心跳续约（Eureka）与租约（ZooKeeper）在脑裂时的行为不同，故障摘除延迟差异？ A Eureka 与 ZooKeeper 都依赖 leader 强一致 B ZooKeeper 是 AP 系统，Eureka 是 CP 系统 C Eureka 用 TTL 心跳续约，是 AP 特性，分区时各节点独立维持心跳；ZooKeeper 用 session 租约删临时节点，是 CP 特性，分区时可能短暂不可用 ✓ 正确答案 D 两者摘除延迟机制完全相同
# 15. 服务发现的两种模式中客户端发现（直接连注册中心）与服务端发现（负载均衡器查询）的取舍？ A 服务端发现把路由逻辑集中到负载均衡器，客户端简单统一，但多一跳且 LB 可能成为瓶颈 ✓ 正确答案 B 客户端发现无需查询注册中心，直接随机调用 C 服务端发现不需要注册中心 D 两种模式在负载均衡算法上完全相同
# 16. 注册中心的选型中 Eureka/Consul/etcd/ZooKeeper 在一致性模型与健康检查上的差异？ A Eureka 是 CP 模型，ZooKeeper 是 AP 模型 B Consul 不支持健康检查 C etcd 基于 AP 模型，不提供强一致 D ZooKeeper 用 session 租约 + 临时节点，CP 强一致；Eureka 用心跳 TTL，AP 最终一致 ✓ 正确答案
# 17. gRPC 的流式通信与负载均衡中 L7 负载均衡、客户端侧负载均衡与 xDS 的配合？ A xDS 是 gRPC 专用的二进制协议，与 Envoy 无关 B gRPC 只能使用 L4 负载均衡 C 由于 HTTP/2 长连接多路复用，L4 连接级负载均衡无法把同一连接上的流分发到不同后端，需 L7 或客户端侧负载均衡 ✓ 正确答案 D gRPC 不支持流式通信
# 18. 注册中心的健康检查与故障摘除中临时/持久节点与租约机制（ZooKeeper/etcd）差异？ A 临时节点在客户端断开后仍会保留 B etcd 不支持租约机制 C 持久节点随 session 断开自动删除 D ZooKeeper 临时节点随 session 失效自动删除，etcd 用 lease+TTL 到期删 key，都是基于租约的故障摘除机制 ✓ 正确答案
# 19. DNS 与 SRV 记录的服务发现中 Kubernetes/Consul DNS 如何返回可用实例，与注册中心直连的差异 A SRV 记录只能返回 IP，不能返回端口 B Kubernetes CoreDNS 直接返回每个 Pod 的 IP，无需 Service C DNS 服务发现零 SDK 依赖、跨语言通用，但存在 DNS 缓存导致的更新延迟与较粗的解析粒度 ✓ 正确答案 D DNS 服务发现比注册中心直连更实时细粒度
