# 1. Saga 长事务模式，拆分 + 补偿？ A Saga 需要全局锁和两阶段提交，与 XA 相同 B Saga 把大事务拆成多个子事务并配套补偿，失败时逆序执行补偿回滚，实现分布式事务的最终一致性 ✓ 正确答案 C Saga 提供强隔离性，中间状态对外不可见 D Saga 失败时无需补偿，直接终止即可
# 2. 分布式事务（Distributed Transaction）的必要性，跨库更新？ A 单机数据库事务就能解决跨库更新的原子性问题 B 分布式事务只影响性能，与一致性无关 C 跨库/跨服务更新需保证原子性，因此需要分布式事务，可按业务选择强一致（XA）或最终一致（Saga/消息表） ✓ 正确答案 D 分布式事务不需要权衡，强一致方案总是最优
# 3. CAP 三角形中的约束冲突，CP（ZooKeeper、etcd）vs AP（DNS、Cassandra）？ A ZooKeeper 在分区时保证可用性，返回任何数据 B CAP 定理说明分区时 C 和 A 可以同时满足 C Cassandra 是严格的 CP 系统，始终返回一致数据 D 分区时 CP 系统（ZooKeeper、etcd）优先一致性牺牲可用性，AP 系统（DNS、Cassandra）优先可用性允许最终一致 ✓ 正确答案
# 4. CAP 定理的精确表述，一致性、可用性、分区容忍性不可兼得？ A CAP 定理允许在分区时同时满足 C 和 A B CAP 定理指分区发生时一致性 C 与可用性 A 不可兼得，P 是必须面对的现实 ✓ 正确答案 C 分区容忍性是可选的，系统可以不保证 P D CAP 定理说明一致性、可用性、分区容忍性三者完全无关
# 5. Paxos 与 Raft 的差异？ A Raft 不依赖多数派，靠单个 Leader 即可 B Paxos 有显式 Leader，实现比 Raft 简单 C Raft 与 Paxos 在一致性保证上不等价 D Paxos 抽象、无显式 Leader、难实现；Raft 显式 Leader、模块化、易实现，两者都基于多数派保证一致性 ✓ 正确答案
# 6. Raft 一致性算法的角色，Leader、Follower、Candidate？ A Raft 中 Leader 处理写请求并复制日志，Follower 被动跟随，Candidate 是选举中间态，通过多数派投票选出唯一 Leader ✓ 正确答案 B Raft 中所有节点都同时处理写请求，无需 Leader C Candidate 是最常见的节点状态 D Follower 负责向客户端返回写结果
# 7. Google Spanner 的 TrueTime（原子钟 + GPS 提供有界误差的时间区间）如何通过 commit wait 保证外部一致性（真实时间顺序与提交顺序一致）？工程代价是什么？ A commit wait 会减少提交延迟，提高性能 B Spanner 用逻辑时钟保证外部一致性，无需物理时间 C Spanner 用 TrueTime 提供有界误差时间区间，提交时等待 ε（commit wait）保证外部一致性，代价是提交延迟和昂贵的时间基础设施 ✓ 正确答案 D TrueTime 不需要 GPS 和原子钟，普通时钟即可
# 8. 混合逻辑时钟（HLC）如何用物理时钟 + 逻辑计数器在无需紧密时钟同步下提供因果序？CockroachDB/YugabyteDB 如何基于 HLC 处理读的不确定性区间（uncertainty interval）？ A CockroachDB 不需要处理不确定性区间，因为 HLC 精确 B HLC 完全依赖紧密时钟同步，时钟漂移不影响因果序 C HLC 只提供逻辑时钟，丢失物理时间信息 D HLC 用物理时钟 + 逻辑计数器提供因果序，CockroachDB 基于 HLC 处理时钟漂移导致的不确定性区间以保证一致读 ✓ 正确答案
# 9. BASE 理论（Basically Available、Soft state、Eventual consistency）的应用？ A BASE 追求强一致，与 ACID 完全等价 B BASE 指基本可用、软状态、最终一致，接受短暂不一致换取高可用与性能，常用于缓存、消息队列、NoSQL ✓ 正确答案 C BASE 不允许任何中间状态，始终一致 D BASE 只适用于关系型数据库，不适用于 NoSQL
# 10. Multi-Raft 分片共识（每个 Region/Tablet 一个 Raft 组）在工程上如何共享传输、存储引擎与心跳以降低成本？元数据管理与再平衡有哪些挑战？ A Multi-Raft 不需要元数据管理，Region 自动路由 B Multi-Raft 的每个 Region 都有独立的网络连接和存储引擎，成本高 C Multi-Raft 每个 Region 一个 Raft 组，通过共享传输、存储引擎、合并心跳降低成本，难点在元数据管理与再平衡 ✓ 正确答案 D Multi-Raft 中 Region 不会分裂或迁移
# 11. CDC 的实现，基于 binlog（WAL、Debezium）、基于触发器、基于时间戳？ A 触发器型 CDC 对写性能无影响 B 基于时间戳的 CDC 能捕获所有删除操作 C 基于 binlog/WAL 的 CDC 无侵入、实时、可捕获完整变更，是主流方案；触发器型有侵入，时间戳型无法捕获删除且实时性差 ✓ 正确答案 D binlog 解析型 CDC 会影响数据库写入性能
# 12. Flink CDC 与 Debezium 的核心差异（Flink CDC 以 Flink 作业运行、支持无锁全量+增量衔接与 exactly-once；Debezium 依托 Kafka Connect 生态）是什么？如何选型？ A Flink CDC 和 Debezium 都只能运行在 Kafka 上 B Flink CDC 以 Flink 作业运行、支持无锁增量快照与 exactly-once；Debezium 依托 Kafka Connect 生态发布到 Kafka，通常 at-least-once ✓ 正确答案 C Debezium 天然支持 exactly-once，无需去重 D Flink CDC 无法做全量增量衔接
# 13. CDC 管道如何处理 schema 演进（加列、改类型、删列）？Debezium 事件结构与 Schema Registry 兼容策略（BACKWARD/FORWARD/FULL）如何配合下游不中断？ A Schema Registry 只管理一台 schema，不处理演进 B schema 演进无需处理，下游自动适应 C Debezium 事件含 schema 与 payload，通过 Schema Registry 的 BACKWARD/FORWARD/FULL 兼容策略管理 schema 演进，保证下游不中断 ✓ 正确答案 D 加列必须用 BACKWARD 策略
# 14. Debezium 增量快照算法（按主键切分 chunk、chunk 间用低水位/高水位与 binlog 对齐，1.6+ 通过 signal 表触发）如何实现无全局锁的全量增量衔接？与旧版全局锁快照有何差异？ A 旧版全局锁快照不阻塞业务，更适合生产 B 增量快照仍会对表加全局锁，与旧版相同 C 增量快照无法捕获快照期间的变更，会丢数据 D Debezium 增量快照按主键切 chunk、用低/高水位与 binlog 对齐、经 signal 表触发，实现无全局锁的全量增量衔接 ✓ 正确答案
# 15. CDC 的消费链路，Debezium → Kafka → 下游消费？ A Kafka 在 CDC 链路中只起临时作用，不持久化 B Debezium 直接把变更写入下游数据库，无需 Kafka C CDC 链路为源库 → Debezium 采集 → Kafka 传输 → 下游消费，Kafka 提供可靠传输与解耦 ✓ 正确答案 D 该链路只能支持单一下游消费
# 16. CDC（Change Data Capture）的概念，捕获数据库变更事件？ A CDC 与 binlog/WAL 无关 B CDC 需要应用层主动上报变更，否则无法捕获 C CDC 只能捕获新增数据，无法捕获删除 D CDC 通过解析数据库变更日志捕获插入/更新/删除事件，用于数据同步、实时分析等 ✓ 正确答案
# 17. Debezium 的工作原理与应用场景？ A Debezium 直接修改源库数据，产生变更 B Debezium 作为 Kafka Connect 连接器解析源库日志，把变更发布到 Kafka，支持断点续传，用于数据同步与实时处理 ✓ 正确答案 C Debezium 只能处理 MySQL，不支持其他数据库 D Debezium 不支持断点续传，宕机会丢事件
# 18. CDC 的一致性保证，at-least-once、exactly-once？ A exactly-once 无需任何配合，天然实现 B at-least-once 保证事件不重复 C CDC 默认多为 at-least-once，靠下游幂等去重；exactly-once 需端到端事务或幂等写入配合 ✓ 正确答案 D CDC 无法保证任何一致性
# 19. XA 协议（两阶段提交）的实现与局限？ A XA 两阶段提交不会阻塞，协调者故障也不影响 B XA 通过准备/提交两阶段实现强一致原子性，但阻塞、锁持有时长、协调者单点，性能差 ✓ 正确答案 C XA 适合高并发长事务场景 D XA 不需要事务管理器，各资源自行提交
