# 1. 本地消息表 + 定时任务中可靠发布的经典实现与重复消息的处理？ A 消息表与业务表分开事务，无需保证原子性 B 定时任务只投递一次，不会重复 C 业务与消息记录同库同事务保证原子性，定时任务重试投递，消费端幂等去重 ✓ 正确答案 D 消费端无需幂等处理
# 2. 本地消息表与事务消息中两种方案的实现代价与失败兜底（对账/补偿）差异？ A 本地消息表不需要定时任务 B 事务消息无需业务方实现回查 C 本地消息表同库同事务+定时任务，事务消息用半消息+回查，两者都需对账/补偿兜底 ✓ 正确答案 D 两者实现代价完全相同
# 3. 两阶段提交的阻塞问题中 prepare 后协调者宕机为何参与者只能阻塞等待，3PC 的提交阶段超时终止如何缓解 A 2PC 协调者宕机不影响参与者 B 3PC 也有超时终止，不会阻塞 C prepare 后协调者宕机，参与者锁定资源却无指令只能阻塞，3PC 用超时终止缓解 ✓ 正确答案 D 2PC 完全无阻塞问题
# 4. 消息乱序与幂等的冲突中消费端如何用业务版本号或状态机拒绝过期消息，与去重表的配合 A 幂等去重即可解决乱序问题 B 版本号只用于去重 C 去重表保证同一消息只处理一次，业务版本号/状态机拒绝过期消息 ✓ 正确答案 D 乱序消息无需特殊处理
# 5. G-Counter 与 PN-Counter 的 CRDT 语义中 G-Counter 只能单调递增，PN-Counter 如何用两个 G-Counter 表示增减并保证收敛？ A G-Counter 只增不减，PN-Counter 用 P 和 N 两个 G-Counter 分别计增减，合并取 max 保证收敛 ✓ 正确答案 B PN-Counter 只需要一个计数器 C PN-Counter 无法并发合并 D G-Counter 可以表示减少
# 6. PN-Counter 在分布式计数中的实现中如何合并副本的增减计数，在点赞数、库存余量等场景的溢出与负数处理？ A PN-Counter 合并时取各槽位最小值 B PN-Counter 一次性得出全局一致值，无中间不一致 C 溢出无需处理 D 各副本维护 P/N 向量，合并逐槽位取 max 收敛，溢出用大整数、负数在应用层校验 ✓ 正确答案
# 7. 消息投递语义的实现中 Exactly-Once 为什么需要幂等消费 + 唯一键去重？ A MQ 本身能保证不重复投递 B Exactly-Once 靠 At-Least-Once 投递 + 消费端唯一键去重（幂等）实现 ✓ 正确答案 C 幂等消费无需去重 D 唯一键去重无法防重复
# 8. MVCC 的版本链与快照读中 InnoDB 的 undo log 版本链如何支撑可重复读，为什么写写冲突仍需锁而读写不互斥？ A MVCC 让写写也无需互斥 B 可重复读与版本链无关 C 快照读会阻塞写操作 D undo log 版本链加 ReadView 支撑快照读与可重复读，写写冲突仍需锁互斥，读写不互斥 ✓ 正确答案
# 9. 分布式 ID 生成与消息顺序中雪花算法与全局单调递增 ID 在消息排序场景的取舍？ A 雪花 ID 严格单调递增 B 全局单调递增 ID 无中心化瓶颈 C 雪花 ID 趋势递增、分布式高并发但非严格有序，严格消息排序需全局单调递增 ID ✓ 正确答案 D 雪花 ID 与排序无关，任意场景都可用
# 10. 消息队列的投递语义中 At-Most-Once / At-Least-Once / Exactly-Once 各自如何实现？ A At-Most-Once 不重试可丢消息，At-Least-Once 重试可能重复需幂等，Exactly-Once 靠幂等去重/事务实现 ✓ 正确答案 B At-Least-Once 保证不重复 C Exactly-Once 由 MQ 单独保证，无需消费端处理 D At-Most-Once 保证不丢消息
# 11. OR-Set 与 Add-wins/Remove-wins 中为什么同时增删同一元素时需按操作类型裁定胜负，与 G-Set 的关系 A OR-Set 与 G-Set 完全相同，都不支持删除 B Add-wins 表示删除获胜 C 并发增删无需裁定 D OR-Set 用 tag 标记元素，Add-wins/Remove-wins 裁定并发增删胜负，是 G-Set 的删除扩展 ✓ 正确答案
# 12. TCC 与本地消息表的组合中 Try 阶段预留的资源如何在 Confirm 失败时释放，与 Outbox 组合保证最终一致性的边界？ A Try 预留资源、Confirm 失败用 Cancel 释放，Outbox 保证业务与消息原子，整体靠重试对账兜底 ✓ 正确答案 B TCC 的 Confirm 可以随意失败 C Outbox 与 TCC 无关 D Confirm 失败时无需释放预留资源
# 13. 可靠消息投递的三种模式中事务消息、本地消息表、Outbox 的对比与各自的一致性边界？ A 三种模式都不保证原子性 B Outbox 用 MQ 半消息机制 C 事务消息用定时任务发布 D 本地消息表、Outbox、事务消息都保证业务与消息记录原子，区别在发布机制（定时任务/CDC/半消息回查） ✓ 正确答案
# 14. Outbox 模式如何保证数据库写入与消息发布原子性，轮询发布与 CDC（如 Debezium）两种实现的差异？ A 轮询发布实时性最高 B CDC 不依赖数据库 binlog C Outbox 同库同事务保证原子，轮询发布简单有延迟，CDC 实时但依赖 binlog ✓ 正确答案 D Outbox 不保证原子性
# 15. TCC 的 Confirm/Cancel 幂等设计中为什么 TCC 要求 Confirm/Cancel 可重入且不能失败，与 Saga 的逆向补偿有何区别？ A TCC 的 Confirm/Cancel 可重入且不能失败，Cancel 释放预留资源；Saga 用逆向业务操作补偿 ✓ 正确答案 B TCC 的 Confirm 可以失败 C Saga 的补偿针对预留资源 D TCC 与 Saga 完全等价
# 16. 分布式数据的分片与复制中一致性哈希与 Raft 复制组如何配合实现扩展与容错？ A 一致性哈希负责容错，Raft 负责分片 B 分片与复制是同一概念 C Raft 不提供主节点故障转移 D 一致性哈希分片实现水平扩展，每个分片用 Raft 复制组保证容错，两者配合实现扩展与高可用 ✓ 正确答案
# 17. 分布式协调服务选型中 ZooKeeper 的 ZAB 与 etcd 的 Raft 在领导选举/配置发布上的差异？ A ZAB 与 Raft 的选举机制完全相同 B etcd 不支持 watch C ZAB 用 zxid 选举、watch 一次性，Raft 用 term 选举、watch 可持续，两者都支持配置发布与选举 ✓ 正确答案 D ZooKeeper 不支持配置发布
# 18. Saga 与 TCC 的区别中 Saga 的补偿是逆向业务操作而 TCC 是预留-确认-取消，各自适合什么场景？ A Saga 需要 Try 阶段预留资源 B Saga 用逆向业务操作补偿、无需预留，TCC 用预留-确认-取消，TCC 适合需预占资源的场景 ✓ 正确答案 C TCC 的 Cancel 是逆向业务操作 D Saga 与 TCC 完全等价
# 19. 对账任务兜底中对账窗口、差异发现与自动修复如何作为最终一致性的最后防线 A 对账窗口越短越好，无需覆盖延迟 B 对账只能发现差异，不能修复 C 对账窗口覆盖最大延迟，定时比对发现差异并自动修复，无法修复的转人工，作为最终一致性的最后防线 ✓ 正确答案 D 对账与最终一致性无关
