# 1. Read Your Writes、Monotonic Reads、Read After Write、Causal Consistency 在客户端/代理/数据库协同实现？ A 单调读允许读到更旧数据 B 因果一致不要求因果顺序 C Read Your Writes 保证读到自己写入，Monotonic Reads 防读到更旧，Causal Consistency 保证因果顺序可见，由客户端/代理/数据库协同实现 ✓ 正确答案 D 这些保证与代理无关
# 2. 为什么缓存常常是最终一致而非强一致？请从 CAP 与工程现实两端解释。 A 缓存应强一致，否则不可用 B 缓存强一致成本为零 C 缓存无需一致性 D 缓存与数据库跨系统强一致在 CAP 下不可兼得，且强一致削弱缓存性能收益，故用最终一致（TTL + 失效 + 补偿） ✓ 正确答案
# 3. Cache-Aside、Read-Through、Write-Through、Write-Behind、Refresh-Ahead 的失效、雪崩、击穿、穿透防护矩阵？ A Cache-Aside 写时先写缓存再写 DB B 无需防护雪崩击穿穿透 C 所有策略都同步写 DB D Cache-Aside 读时查缓存未命中回填、写时失效缓存；雪崩靠过期抖动、击穿靠 singleflight/锁、穿透靠布隆/空值防护 ✓ 正确答案
# 4. Hinted Handoff 在节点短暂不可用、复制积压与恢复合并时的实现与限制？ A 健康节点代写并记录 hint，目标恢复后重放追平，避免写丢失；但 hint 容量有限、重放有延迟，只保证最终一致 ✓ 正确答案 B 节点不可用时写操作直接丢弃 C hint 绝不会丢失 D 它保证强一致
# 5. Write-Behind 的异步刷写、丢失风险、批量合并、限速与重放对账的设计？ A 写操作同步写 DB B Write-Behind 异步批量回写 DB 提升性能，需持久化缓冲避免丢失、批量合并、限速与重放对账保证最终一致 ✓ 正确答案 C 回写窗口内崩溃不会丢数据 D 无需对账
# 6. Cache-Aside 与 Write-Through 中云缓存一致性模式的选择？ A Cache-Aside 写时先写缓存再写 DB B Cache-Aside 读时查缓存回填、写时失效缓存，灵活性能好；Write-Through 写路径一致，按读多写少/写一致性需求选择 ✓ 正确答案 C Write-Through 每次写都提高命中率 D 两者写路径完全一致
# 7. Anti-Corruption Layer（ACL）在跨系统语义翻译、防腐、契约版本与双向同步中的适用约束？ A ACL 让外部模型直接进入领域模型 B ACL 在边界翻译语义、隔离外部变化、管理契约版本，保护领域模型不被污染；双向同步需处理冲突与一致性 ✓ 正确答案 C ACL 只用于前端 D ACL 无需版本管理
# 8. 缓存与数据库双写一致性中延迟双删（先删缓存→写数据库→延迟再删缓存）+ Canal binlog 订阅异步补偿的最终一致方案 A 延迟双删（先删缓存→写 DB→延迟再删）+ Canal binlog 订阅异步补偿，实现缓存与 DB 最终一致 ✓ 正确答案 B 先写 DB 再删缓存即可保证一致 C 双写必然是强一致 D 无需补偿
# 9. 缓存击穿（hot key）、缓存雪崩（同时过期）、缓存穿透（恶意/不存在 key）的典型治理与 Lua/Bloom/二级缓存？ A 穿透用过期抖动治理 B 击穿与雪崩相同 C 穿透用 Bloom/空值拦截，击穿用 singleflight/永不过期，雪崩用过期抖动/多级缓存，Lua 保证原子、二级缓存扛热点 ✓ 正确答案 D 无需治理
# 10. 缓存预热、灰度切流、读写穿透、cache stampede 防抖、singleflight 模式的工程实现？ A singleflight 让并发回源各自打 DB B cache stampede 无需治理 C 预热加载热点、灰度切流验证、读写穿透统一路径、singleflight 合并并发回源防惊群 ✓ 正确答案 D 预热只用于冷数据
# 11. Health Endpoint Monitoring 的健康探测、流量摘除、级联熔断与“假阳性剔除”如何避免？ A 健康探测失败一次就摘除即可 B 健康端点探测 + 流量摘除 + 级联熔断，用连续失败阈值、重试、liveness/readiness 分离避免假阳性误摘 ✓ 正确答案 C 假阳性无影响 D 健康与就绪探针相同
# 12. Outbox + Inbox 模式如何用本地表与发布器实现可靠消息，避免双写不一致？ A Outbox 写业务与写消息分属两个事务 B 无需发布器 C Inbox 用于发送端 D Outbox 在本地事务内写业务与待发消息、发布器投递，Inbox 本地去重表保证幂等消费，避免双写不一致 ✓ 正确答案
# 13. Outbox/Inbox 模式、Polling Publisher、Transaction Log Tailing 在可靠消息中的取舍？ A Polling Publisher 轮询 Outbox 表简单可靠但延迟，Transaction Log Tailing 尾随 binlog 实时不侵入但复杂，按需取舍 ✓ 正确答案 B Polling Publisher 实时无延迟 C Transaction Log Tailing 需业务写 Outbox 表 D 三者完全相同
# 14. Sidecar 在多语言异构系统中的最大副作用是什么？请给出治理建议。 A Sidecar 无资源开销 B 最大副作用是资源开销与部署运维复杂度，治理是控制资源、统一管理、按需使用、评估 eBPF 替代 ✓ 正确答案 C Sidecar 不增加延迟 D 每个服务都应带多个 sidecar
# 15. “Effectively-Once”与“Exactly-Once Effect”通过幂等 + at-least-once + 去重实现的真实边界是什么？ A 它保证消息投递恰好一次 B 跨系统恒能保证 C 无需去重 D Effectively-Once 通过幂等 + at-least-once + 去重实现"效果层面"恰好一次，依赖幂等键与原子去重，非传输层恰好一次 ✓ 正确答案
# 16. 为什么“端到端 Exactly-Once”并不存在？请从消息层、存储层、应用层给出反例。 A 消息层重复投递、存储层重复写入、应用层重复执行，任一环节都可能重复/丢失，端到端 Exactly-Once 不存在，只能追求效果层面幂等 ✓ 正确答案 B 端到端恰好一次可以实现 C 只需保证消息层恰好一次 D 应用层不会重复执行
# 17. Ambassador 模式如何作为进程外的代理对外代表应用 A Ambassador 作为进程外代理代表应用访问外部，统一处理连接/重试/限流/认证/观测，应用无外部耦合 ✓ 正确答案 B Ambassador 在应用内处理外部调用 C Ambassador 只处理内部调用 D Ambassador 与主应用同进程
# 18. 如何设计可重试且幂等的补偿链以避免悬挂事务 A 补偿可重复执行，无需幂等 B 补偿用唯一键幂等去重、状态机保证精确状态、可重试幂等、与正向事务协调，避免悬挂事务 ✓ 正确答案 C 悬挂事务无法避免 D 补偿无需状态机
# 19. Event Sourcing 的快照（snapshot）为何必要以减少重放 A 快照用于修改历史事件 B 快照与重放无关 C 快照保存状态与位置，重放从快照开始只算增量，减少重放量，避免事件多时重放全部成本高 ✓ 正确答案 D 事件流很短无需快照
# 20. Saga 执行中部分失败如何保证已提交步骤最终被补偿 A 部分失败时已提交步骤无需补偿 B 对已提交步骤逆序执行补偿链，补偿幂等 + 状态机 + 重试，保证最终被补偿，实现最终一致 ✓ 正确答案 C Saga 提供原子回滚 D 补偿失败就放弃
# 21. 事件溯源如何天然支持审计、回放与时空旅行调试 A 事件溯源只存当前状态 B 事件不可变且是事实源，天然支持审计（事件即记录）、回放（重放重建）、时空旅行调试（回到任意时点） ✓ 正确答案 C 事件可修改 D 无法追溯历史
# 22. 事件版本演进（schema evolution）如何在溯源中兼容 A 新增事件字段复用旧编号 B schema 变更即可破坏 C 演进不需要兼容 D 新增字段带默认值/新编号、删除保留编号、版本化 + 迁移器 + Schema Registry 校验，保证历史事件可重放兼容 ✓ 正确答案
# 23. 何时不该用 CQRS/ES，简单 CRUD 反而增加复杂度 A 简单 CRUD 用 CQRS/ES 更高效 B 简单 CRUD 用 CQRS/ES 增加读写模型、事件投影、最终一致等复杂度，属于过度设计；读写差异大、查询复杂、需审计回放时才用 ✓ 正确答案 C CQRS/ES 适用于所有场景 D 简单 CRUD 最适合 CQRS
# 24. 补偿操作必须满足幂等与可逆，否则如何保证最终一致 A 补偿可重复执行即可，无需可逆 B 不可逆操作可直接放 Saga C 补偿无需幂等 D 补偿须幂等（重试安全）与可逆（撤销正向），否则用预留/确认设计或人工/对账兜底保证最终一致 ✓ 正确答案
# 25. Exactly-Once 语义的实现路径中幂等消费者 + 去重表 vs 事务消息 vs 两阶段提交的取舍？ A 2PC 不阻塞，适合长事务 B 只需幂等即可，无需去重 C 幂等消费者+去重表简单实现 Effectively-Once，事务消息保证发送原子，2PC 强一致但阻塞、不适合长事务，按需取舍 ✓ 正确答案 D 事务消息无开销
# 26. Compensating Transaction 与 Saga 中云原生环境下长事务的回滚设计？ A Saga 用本地事务 + 幂等补偿 + 状态机实现长事务回滚，避免 2PC 锁资源阻塞，追求最终一致 ✓ 正确答案 B 云原生长事务用 2PC 回滚 C 长事务应持有全局锁 D 补偿无需幂等
# 27. Circuit Breaker 与 Bulkhead 中云服务的故障隔离与快速失败模式？ A Circuit Breaker 做资源隔离，Bulkhead 做快速失败 B 无需隔离 C 两者功能相同 D Circuit Breaker 失败率触顶快速失败，Bulkhead 独立资源池隔离防耗尽，二者配合实现云服务故障隔离与快速失败 ✓ 正确答案
# 28. 多级缓存（本地 Caffeine + 分布式 Redis）一致性协同中本地缓存 TTL 短 + 消息广播失效，避免跨节点脏读 A 本地缓存 TTL 越长越好 B 本地缓存 TTL 短减少脏窗口，写后消息广播失效各节点本地缓存 + Redis 统一失效，避免跨节点脏读 ✓ 正确答案 C 本地缓存无需失效 D 跨节点脏读不可避免
# 29. Sidecar、Ambassador、Adapter 在服务网格中的部署模式与对延迟、CPU、可观测性的影响？ A Sidecar 提供统一治理与可观测性，但增加延迟、CPU 与资源开销（多一跳代理），需权衡 ✓ 正确答案 B Sidecar 不消耗资源 C Sidecar 降低延迟 D Adapter 不增加任何开销
# 30. Strangler Fig 在单体→微服务迁移中如何与 API 网关、影子流量、契约测试、回滚开关协同？ A 网关分流 + 影子流量验证 + 契约测试兼容 + 回滚开关回退，渐进安全迁移单体到微服务 ✓ 正确答案 B 一次性切全部流量 C 迁移无需回滚 D 影子流量直接切换
# 31. 为什么 ACL 与 BFF（Backend for Frontend）经常一起出现？它们的边界与协同如何设计？ A ACL 面向前端，BFF 面向外部系统 B 二者互斥 C 两者功能完全相同 D ACL 管内部↔外部系统的防腐翻译，BFF 管前端↔内部服务的聚合适配，二者都在边界适配故常一起出现 ✓ 正确答案
# 32. 为什么“Exactly-Once Delivery”在分布式系统中是错误的认知？需要重新定义为哪些可达成目标？ A 消息投递能保证恰好一次 B at-most-once 足够 C 投递与处理无关 D "恰好一次投递"在分布式中不可能（ACK 丢失/重试必然重复或丢失），可达成的是 Effectively-Once（at-least-once + 幂等 + 去重） ✓ 正确答案
# 33. Saga 如何用一系列本地事务+补偿（compensation）替代 2PC A Saga 用全局锁保证原子 B Saga 提供强原子 C Saga 拆成本地事务 + 补偿，无全局锁、失败逆序补偿，追求最终一致，替代 2PC 的全局锁与阻塞 ✓ 正确答案 D 2PC 适合长事务
# 34. 为何长事务不适合 2PC 而适合 Saga（锁资源太久） A 2PC 长事务不锁资源 B 长事务用 2PC 更佳 C Saga 也持全局锁 D 2PC 长事务锁资源太久、阻塞、协调器等待，Saga 本地事务独立提交不持长锁、用补偿回滚，更适合长事务 ✓ 正确答案
# 35. CQRS 为何把写模型（命令）与读模型（查询）分离 A 写模型保业务规则、读模型保查询性能，各自独立优化与扩展，避免单一模型同时满足两种差异巨大的关注点 ✓ 正确答案 B 读写应合一模型简化 C 读写模型必须完全一致 D 分离无收益
# 36. CQRS 引入的最终一致读延迟对业务交互的影响 A 最终一致读延迟让写后立即读可能读到旧数据，影响体验与一致性，用关键路径强一致读/同步投影/会话一致性缓解 ✓ 正确答案 B 读延迟无影响 C 读模型总是最新 D 无需缓解
# 37. CQRS 的读模型如何由事件异步投影（projection）更新 A 读模型同步更新，无延迟 B 投影器直接读写模型 C 写模型发事件，投影器异步消费事件更新读模型，最终一致、幂等、可重放 ✓ 正确答案 D 读模型与事件无关
# 38. Envoy 作为 Sidecar 如何实现流量管理与 mTLS A Envoy 只做负载均衡，不做 mTLS B Envoy 不处理入站流量 C mTLS 证书由应用手动管理 D Envoy 作为 Sidecar 用 xDS 配置实现流量管理（路由/熔断/重试），用 SDS 自动签发轮换证书实现 mTLS 双向认证加密 ✓ 正确答案
# 39. Event Sourcing 用"事件日志"替代"当前状态"的存储范式 A 事件溯源用不可变追加的事件日志作为事实源，状态由事件重放派生，可重建历史、可审计，替代当前状态覆盖存储 ✓ 正确答案 B 事件溯源直接存当前状态 C 事件可被覆盖 D 历史无法重建
# 40. Saga 的隔离性缺失（脏读/丢失更新）如何靠语义解决 A Saga 用数据库锁保证隔离 B Saga 无全局锁会脏读/丢失更新，用语义锁、状态机、乐观锁、幂等等业务语义解决，保证最终一致 ✓ 正确答案 C Saga 提供完整隔离 D 无需解决隔离
# 41. Sidecar 与 Ambassador 在"入站/出站"职责上的区别 A Sidecar 只处理出站 B Sidecar 是通用旁路代理，入站出站服务间流量都管；Ambassador 偏代表应用对外访问的外部/出站代理 ✓ 正确答案 C Ambassador 处理入站 D 两者职责完全相同
# 42. Sidecar 带来的资源开销与启动顺序（init container）问题 A Sidecar 无资源开销 B 主容器无需等待 Sidecar C Sidecar 增加资源开销与启动顺序问题（主容器依赖 Sidecar 就绪），用 init container 与启动顺序管理解决 ✓ 正确答案 D Sidecar 启动顺序无关
# 43. Sidecar 模式如何将横切关注（日志/监控/TLS）从主容器剥离 A 主容器应实现日志/TLS B Sidecar 只做日志 C Sidecar 把日志/监控/TLS/重试等横切关注从主容器剥离到旁路代理，主容器只关注业务，集中治理、语言无关、独立升级 ✓ 正确答案 D 横切关注应留在主容器
# 44. TCC（Try-Confirm-Cancel）与 Saga 的补偿思想异同 A TCC 与 Saga 都依赖全局锁 B 两者完全相同 C TCC 无预占阶段 D 两者都用补偿避免 2PC 阻塞，但 TCC 有显式 Try 预占 + Confirm/Cancel，Saga 是本地事务 + 逆序补偿 ✓ 正确答案
# 45. eBPF 方案为何被视为 Sidecar 的潜在替代 A eBPF 仍需每 Pod 一个 sidecar 进程 B eBPF 与内核无关 C eBPF 增加延迟 D eBPF 在内核透明处理流量，无用户态 sidecar 进程，降低资源开销、延迟与运维复杂度，是 Sidecar 潜在替代 ✓ 正确答案
# 46. 与 Library/SDK 方式相比，Sidecar 的解耦与升级优势 A SDK 语言无关、升级无需改应用 B SDK 升级更简单 C Sidecar 与 SDK 相同 D Sidecar 把横切逻辑从应用剥离、语言无关、独立升级（不动应用代码），相比 SDK 有解耦与升级优势 ✓ 正确答案
# 47. 如何向面试官说明 Sidecar 之于微服务可观测性的价值 A Sidecar 只能在单一语言中采集 B Sidecar 统一采集指标/追踪/日志、注入 traceId 跨链路追踪、语言无关、覆盖流量治理，是微服务可观测性的关键基础设施 ✓ 正确答案 C Sidecar 不采集可观测性 D 各服务需各自接观测 SDK
