# 1. 线性一致性（Linearizability）与可串行化（Serializability）的本质区别是什么？为什么严格可串行化（Strict Serializability）被视为二者的交集？ A 线性一致性是事务级隔离语义 B 严格可串行化同时满足事务串行等价与实时顺序一致，是二者的交集 ✓ 正确答案 C 可串行化只保证单操作排序 D 线性一致性不保证读旧值限制
# 2. NWR quorum 模型（Dynamo 风格）如何通过 R+W>N 保证读到最新值？Sloppy Quorum 与 Hinted Handoff 又会引入怎样的一致性退化？ A Hinted Handoff 后数据立即强一致 B R+W>N 时读写集合可以不重叠 C Sloppy Quorum 不会引入一致性退化 D R+W>N 保证了读写集合必有交集，从而读到最新值 ✓ 正确答案
# 3. CAP 定理精确约束的是什么（发生网络分区时一致性与可用性只能二选一）？为什么它常被误读为“三选二”，且分区未发生时并不适用？ A CAP 是 C、A、P 三者任选两个 B 分区未发生时也只能二选一 C 分区发生时只能在一致性与可用性间二选一，P 是条件而非可选项 ✓ 正确答案 D CAP 要求永远同时满足三者
# 4. 因果一致性（Causal Consistency）如何借助向量时钟（Vector Clock）判定并发与偏序？它与线性一致性在协调开销上的本质差异是什么？ A 因果一致性比线性一致性协调开销更高 B 向量时钟提供全局实时排序 C 向量时钟用偏序判定因果关系，互不可比则为并发 ✓ 正确答案 D 因果一致性要求所有操作全局有序
# 5. PACELC 中的 PA/EL 与 PC/EC 分别描述什么场景？相比 CAP，它补充了系统正常运行（无分区）时延迟与一致性的何种权衡？ A PACELC 只讨论分区时的一致性 B PACELC 与 CAP 无关 C 无分区时不存在延迟与一致的权衡 D PA/EL 在分区时优先可用、正常时优先低延迟，PC/EC 优先一致，EL/EC 反映无分区时延迟与一致的权衡 ✓ 正确答案
# 6. Raft 的线性一致读优化，ReadIndex 与 Lease Read 的实现与适用条件 A Lease Read 依赖时钟租约，在租约期内无需与多数派交互即可本地读 ✓ 正确答案 B ReadIndex 每次读都需完整日志同步 C ReadIndex 依赖时钟同步 D Lease Read 不要求 Leader 身份
# 7. 会话一致性保证 Read-Your-Writes、Monotonic Reads、Monotonic Writes、Writes-Follow-Reads 分别如何用会话令牌或读时间戳实现？ A 会话一致性是全局强一致 B 四类会话一致性都通过会话令牌或时间戳记录读写位置来保证 ✓ 正确答案 C Read-Your-Writes 不保证读到自己写的 D 会话一致性无需记录读位置
# 8. 最终一致性依赖哪些收敛机制（LWW 最后写入获胜、CRDT 无冲突复制数据类型）？CRDT 需要满足什么代数性质（join-半格、单调合并）？ A 最终一致性无需收敛机制 B LWW 能保留所有并发更新 C CRDT 合并结果依赖顺序 D CRDT 合并需满足幂等、可交换、结合且单调，保证并发更新收敛 ✓ 正确答案
# 9. 为什么 Cassandra 类系统即使配置 R+W>N 仍可能读到旧值（节点宕机恢复、读修复未完成）？Read Repair 与反熵（Anti-Entropy）如何协作收敛？ A Anti-Entropy 只处理读路径 B R+W>N 保证绝对不读旧值 C Read Repair 只修复后台数据 D 节点宕机恢复或读修复未完成时，即使 R+W>N 也可能读到旧值 ✓ 正确答案
# 10. Raft 的日志匹配性质（Log Matching Property）包含哪两条不变式？Follower 如何通过 AppendEntries 的 prevLogIndex/prevLogTerm 一致性检查发现并修复日志冲突？ A 日志匹配性质保证同 index 同 term 的日志内容相同，且此前日志一致 ✓ 正确答案 B 不同节点的日志可以任意冲突 C prevLogIndex 检查用于跳过日志 D Follower 拒绝后 Leader 不重试
# 11. 为什么 Raft Leader 不能仅靠计数直接提交前任 term 的日志（Figure 8 已提交日志被覆盖问题），而必须通过提交本 term 日志间接提交旧日志？ A 直接计数提交旧日志是安全的 B 复制到多数派即可安全提交任何 term 日志 C 新 Leader 一定保留所有已提交日志 D Leader 需通过提交本 term 日志间接提交前任 term 日志，避免被覆盖 ✓ 正确答案
# 12. Raft 选举中 RequestVote 的授予规则（日志至少与自己一样新、每个 term 只投一票）如何保证当选者一定包含所有已提交日志？随机化选举超时如何避免选票分裂（Split Vote）？ A 随机化超时会加剧选票分裂 B 候选者可任意获得选票 C 只投票给日志不落后于自己的候选者，且每 term 一票，可保证当选者含已提交日志 ✓ 正确答案 D 当选者无需包含已提交日志
# 13. Raft 集群成员变更的 Joint Consensus（两阶段联合配置）与单节点变更（single-server change）各自如何避免出现两个不相交多数派？ A 单节点变更会引入脑裂 B 成员变更可直接切换 C 新旧配置多数派可不相交 D Joint Consensus 用两阶段联合配置，单节点变更用相邻配置多数派相交避免脑裂 ✓ 正确答案
# 14. Basic Paxos 的 Prepare/Promise 与 Accept/Accepted 两阶段各自承担什么职责？为什么提案编号（proposal number）必须全局单调递增且 Leader 需尊重已承诺的最大值？ A Prepare 阶段直接提交值 B Prepare 承诺不接收旧编号并收集已接受值，Accept 提交值，编号需单调递增且沿用已承诺最大值 ✓ 正确答案 C 提案编号可重复 D 无需尊重已承诺的最大值
# 15. Multi-Paxos 如何通过稳定 Leader 省略多数提案的 Prepare 阶段？它与 Raft 强 Leader、连续日志模型的本质差异在哪里？ A Multi-Paxos 通过稳定 Leader 省略 Prepare，Raft 用强 Leader 连续日志模型简化 ✓ 正确答案 B Multi-Paxos 每次提案都需 Prepare C Raft 日志可以不连续 D 两者本质实现完全相同
# 16. Raft 日志压缩（Snapshot + InstallSnapshot RPC）如何防止日志无限增长？落后太多的 Follower 如何通过快照追赶，期间 Leader 需保留什么？ A 快照只用于删除日志 B 快照压缩旧日志，InstallSnapshot 把快照发给落后 Follower 追赶，Leader 保留快照点后的日志 ✓ 正确答案 C 落后 Follower 只能靠增量日志追赶 D Leader 无需保留任何日志
# 17. Learner/Non-voting 成员在 Raft 中不参与投票计数，它在新节点加入预热、只读副本与跨地域容灾场景中有哪些典型用法？ A Learner 不接收日志 B Learner 参与投票计数 C Learner 不参与投票，用于新节点预热、只读副本与跨地域容灾 ✓ 正确答案 D Learner 只能用于只读
# 18. ZooKeeper 的 ZAB 协议与 Raft 在 epoch（zxid 高位）、Leader 选举时的日志同步（DIFF/TRUNC/SNAP）与事务提交上有何异同？ A ZAB 与 Raft 都用 epoch/term 标识任期，ZAB 用 DIFF/TRUNC/SNAP 同步日志，都与 Raft 日志匹配对应 ✓ 正确答案 B ZAB 不使用 epoch C ZAB 与 Raft 提交机制完全不同 D ZAB 无日志同步
# 19. Raft 的 Commit Index 与 Applied Index 有什么区别？为什么状态机必须严格按日志顺序 apply，乱序 apply 会破坏什么？ A 两者含义相同 B Commit Index 是已提交可应用的序号，Applied Index 是已应用的序号，状态机必须按序 apply 保证确定性 ✓ 正确答案 C 状态机可乱序 apply D 乱序 apply 不影响一致性
# 20. 为什么说 2PC 是阻塞协议（参与者投 Yes 后等待协调者裁决期间持锁阻塞）？Presumed Abort / Presumed Commit 如何通过默认推断减少日志与恢复开销？ A 2PC 参与者可自行决定结果 B 2PC 参与者在等待裁决期间持锁阻塞，Presumed Abort/Commit 用默认推断减少日志与恢复开销 ✓ 正确答案 C Presumed 推断不减少开销 D 2PC 是非阻塞协议
# 21. Google Percolator 的数据模型包含哪几列（Data、Lock、Write）？事务提交如何通过 Prewrite（上锁并检测冲突）+ Commit primary key 两轮完成，secondary 如何异步提交？ A secondary 在 Commit primary 前提交 B Percolator 只有 Data 一列 C Percolator 用 Data/Lock/Write 三列，Prewrite 上锁检测冲突，Commit primary 定成败、secondary 异步提交 ✓ 正确答案 D Prewrite 不检测冲突
# 22. Percolator 如何处理客户端崩溃后的残留锁（锁带 TTL，遇到过期锁写 Rollback 记录）？Prewrite 阶段如何通过检查 Write 列检测写写冲突？ A 过期锁被清除并写 Rollback 记录，Prewrite 检查 Write 列检测写写冲突 ✓ 正确答案 B 残留锁永久阻塞 C Prewrite 不检查冲突 D 锁没有 TTL
# 23. Google Spanner 的 TrueTime API 返回一个时间不确定区间 [earliest, latest]，Commit Wait 如何据此保证外部一致性（External Consistency）？为什么依赖原子钟/GPS 时钟？ A Commit Wait 立即提交 B Commit Wait 等待真实时间越过 latest 后提交，保证外部一致性，依赖原子钟/GPS 缩小不确定区间 ✓ 正确答案 C TrueTime 返回精确时间 D 外部一致性无需时间同步
# 24. Percolator 的快照读如何在 read_ts 上避免读到未提交数据（遇到锁则触发清理并回退重试）？只读事务为何可以省去加锁与提交阶段？ A 快照读在 read_ts 读已提交数据，遇锁清理重试，只读事务无需加锁与提交 ✓ 正确答案 B 快照读可读取未提交数据 C 只读事务也需提交 D 遇锁不处理
# 25. 确定性事务（Calvin 模型）通过定序器（Sequencer）预先排序事务来避免 2PC，它对依赖型事务（dependent transaction）有什么限制？ A Calvin 无需排序 B Calvin 用定序器预排序避免 2PC，但对运行时尚无法确定写集/依赖的依赖型事务受限 ✓ 正确答案 C Calvin 仍依赖 2PC D 依赖型事务无任何限制
# 26. 2PC 结合 WAL（MySQL XA、PostgreSQL PREPARE TRANSACTION）如何在参与者崩溃后恢复 in-doubt 事务？悬挂的 prepared 事务长期不决会带来哪些危害？ A 崩溃后 prepared 事务无法恢复 B 参与者崩溃后从 WAL 恢复 prepared 事务，悬挂 prepared 事务会长期持锁阻塞并耗尽资源 ✓ 正确答案 C 悬挂 prepared 事务无危害 D prepared 事务不占锁
# 27. 相比传统 2PC，Percolator 式去中心化两阶段提交（无独立协调者、由 primary key 驱动裁决）在延迟与协调者可用性上有哪些改进与代价？ A 去中心化提交仍需独立协调者 B 去中心化提交用 primary key 裁决，消除协调者单点并降延迟，但依赖 primary 与异步窗口更复杂 ✓ 正确答案 C 去中心化提交延迟更高 D primary key 无裁决作用
# 28. 2PC 中协调者与参与者的 Prepare/Commit/Abort 日志记录分别有哪些？为什么协调者必须先持久化 Commit 决定再通知参与者？ A 协调者先持久化 Commit 决定再通知，崩溃后能恢复裁决，保证参与者一致 ✓ 正确答案 B 协调者可先通知再写日志 C 协调者无需记录日志 D 参与者无需 prepared 日志
# 29. 对比 TiDB（TiKV/RocksDB）、CockroachDB（Pebble）、OceanBase（自研 LSM-Tree）的存储引擎，Compaction 策略、写放大与空间放大有何差异？ A 写放大与引擎无关 B 三者 Compaction 完全相同 C RocksDB 分层 Compaction 写放大较高，Pebble 优化写放大，OceanBase 用转储/合并平衡写放大与空间放大 ✓ 正确答案 D OceanBase 无合并机制
# 30. Quorum 读与线性一致读的代价（读放大 vs 延迟） A 两者代价相同 B 线性一致读无延迟 C Quorum 读无读放大 D Quorum 读需读多副本产生读放大，线性一致读需协调确认增加延迟 ✓ 正确答案
# 31. 三者分别如何提供 SQL 兼容性（TiDB 兼容 MySQL 协议、CRDB 兼容 PostgreSQL 协议、OceanBase MySQL/Oracle 双模式）？协议兼容与语法/语义兼容的典型坑有哪些？ A 三者都兼容 MySQL B 协议兼容即完全兼容 C TiDB 兼容 MySQL、CRDB 兼容 PostgreSQL、OceanBase 双模式，但协议兼容不等于语义兼容，函数/隔离级别等行为可能不同 ✓ 正确答案 D 语义兼容无坑
# 32. 三者事务模型有何不同（TiDB 基于 Percolator 的乐观/悲观事务、CRDB 可串行化隔离、OceanBase Paxos+两阶段提交）？默认隔离级别与分布式死锁处理有何差异？ A 三者默认都是可串行化 B 三者事务模型完全相同 C TiDB 用 Percolator 乐观/悲观事务、CRDB 可串行化、OB 用 Paxos+2PC，默认隔离级别与死锁处理各有差异 ✓ 正确答案 D 分布式死锁无需处理
# 33. 三者分别如何实现 HTAP（TiDB TiFlash 列存副本、CRDB 无专用列存、OceanBase 行列混合与并行执行）？列存副本与行存的数据新鲜度如何保证？ A 三者 HTAP 实现完全相同 B 三者都无列存 C TiDB 用 TiFlash 列存副本异步同步、CRDB 无专用列存、OB 行列混合，新鲜度取决于同步机制 ✓ 正确答案 D 列存新鲜度无关紧要
# 34. 三者的调度组件（PD、Allocator/Replication、RootService）如何实现分片（Region/Range/Tablet）迁移、副本均衡与热点打散？ A 三者调度组件职责完全不同 B PD/Allocator/RootService 分别负责 TiDB/CRDB/OB 的分片迁移、副本均衡与热点打散 ✓ 正确答案 C 热点无需打散 D 调度组件不做副本均衡
# 35. 节点或可用区故障时，三者在 RPO（Raft/Paxos 多数派自动选主）与切换时间上有何差异？跨地域部署的延迟代价如何？ A 跨地域部署无延迟代价 B 三者故障时会有数据丢失 C 三者都靠多数派共识自动选主、RPO 通常为 0，跨地域同步使写延迟随 RTT 上升 ✓ 正确答案 D 切换时间与多数派无关
# 36. 三者在数据迁移（TiDB Lightning/DM、CRDB IMPORT/MOVABLE、OceanBase OMS）与 CDC 生态工具上的成熟度差异？ A TiDB 用 Lightning/DM/TiCDC、CRDB 用 IMPORT/MOVABLE、OB 用 OMS，TiDB 的 MySQL 生态迁移成熟度较高 ✓ 正确答案 B 三者迁移工具完全相同 C 三者都无 CDC D 迁移工具与生态无关
# 37. 为什么共识组通常部署奇数个节点？3 节点与 4 节点集群在可容忍故障数与可用性上为何没有差别却多花成本？ A 偶数节点更优 B 4 节点比 3 节点容错更强 C 3 与 4 节点都只能容忍 1 个故障，可用性相同但 4 节点多花成本，故常用奇数节点 ✓ 正确答案 D 节点数与多数派无关
# 38. 混合逻辑时钟（HLC）在分布式数据库中的应用 A HLC 与事务时间戳无关 B HLC 只用逻辑计数 C HLC 无法保证因果排序 D HLC 结合物理与逻辑时钟，用于事务时间戳、快照隔离与因果排序 ✓ 正确答案
