# 1. 基于游标的分页模式，cursor-based pagination？ A 游标分页与 OFFSET 分页通过相同方式定位，性能一致 B 游标分页在翻页期间数据变化会导致数据重复或跳行 C 游标分页无法利用索引，只能全表扫描 D 游标分页基于排序键位置定位，翻页性能稳定且不随页数增加而退化 ✓ 正确答案
# 2. Seek（键集）分页与索引的配合，为什么基于 WHERE 游标的分页能利用索引避免深翻页，其排序键的唯一性要求是什么？ A Seek 分页的排序键可以不唯一，只要加 LIMIT 即可 B Seek 分页依赖排序键唯一，否则会在相等键值处出现重复或跳过 ✓ 正确答案 C Seek 分页会随页数增加而线性退化，与 OFFSET 相同 D Seek 分页无法利用索引定位，只能全表扫描
# 3. 去重（Dedup）的实现，唯一索引、Redis SET、消息队列？ A Redis SET 是权威的持久化去重手段，故障不会丢失数据 B 数据库唯一索引是最强去重约束，通常作为可靠兜底，Redis 作为性能前置 ✓ 正确答案 C 消息队列天然保证 Exactly-Once，无需去重 D 唯一索引只能用于去重，不能作为业务约束
# 4. 幂等表（Idempotency Table）的设计，请求指纹 + 响应缓存？ A 幂等表只记录请求，不缓存响应，因此重复请求会重新执行业务 B 幂等表不需要唯一索引，靠应用层判断即可 C 幂等表用唯一索引保证同一幂等键只处理一次，重复请求返回缓存结果 ✓ 正确答案 D 幂等键可以由请求体任意拼接，无需保证唯一性
# 5. 状态机（State Machine）的数据库建模，status 字段 + transition 函数？ A 状态历史表没有必要，直接覆盖 status 即可 B status 字段可以任意变化，无需约束合法性 C status 字段存状态，transition 函数定义合法转移，历史表记录转移流水 ✓ 正确答案 D transition 规则只能放在数据库触发器里，应用层无法实现
# 6. 状态转移的合法性校验，CHECK 约束、触发器、应用层？ A CHECK 约束能校验跨行状态转移合法性 B 触发器能读取新旧状态在数据库层拦截非法转移，但增加写入开销 ✓ 正确答案 C 应用层校验最可靠，数据库层无法绕过 D 触发器校验比应用层更灵活但可被绕过
# 7. 状态转移的并发控制，乐观锁（版本号）、悲观锁（SELECT FOR UPDATE）？ A 悲观锁更新失败会影响行数，需要重试 B 悲观锁不产生任何锁等待，适合读多写少场景 C 乐观锁适合写冲突频繁的场景 D 乐观锁通过版本号条件更新，冲突时影响行数为 0 需重试 ✓ 正确答案
# 8. Etcd 分布式锁，Lease + Revision？ A etcd 锁不依赖租约，key 永不过期 B Lease 提供 TTL 自动释放避免死锁，Revision 用于原子互斥保证单一持有者 ✓ 正确答案 C Lease 只用于续期，与自动释放无关 D etcd 锁没有一致性保证，可能与 Redis 锁等价
# 9. ZooKeeper 分布式锁的实现，临时顺序节点如何保证互斥与公平排队，Watch 机制如何感知锁释放，与 etcd Lease+Revision、Redis 锁在一致性与可用性上的差异？ A Redis 锁与 ZK 锁一致性相同 B ZK 锁基于临时节点，但会话断开不会自动释放锁 C ZK 用临时顺序节点保证互斥与公平排队，Watch 感知释放，与 etcd 同为强一致（CP） ✓ 正确答案 D ZK 锁不保证公平性，后到先得
# 10. 分布式锁（Distributed Lock）的应用，定时任务、库存扣减、限流？ A 定时任务用分布式锁保证多实例下仅一个实例执行，避免重复作业 ✓ 正确答案 B 分布式锁只能用于 Redis，无法用数据库实现 C 库存扣减不需要锁，靠数据库自动避免超卖 D 分布式锁用于提升单机性能，与互斥无关
# 11. 一致性消息（Transactional Message）的实现，RocketMQ、Kafka 事务消息？ A 一致性消息仅用于 RocketMQ，Kafka 不支持 B Kafka 事务消息能直接与业务数据库事务原子提交 C 半消息对消费者完全可见，可提前消费 D RocketMQ 用半消息 + 回查机制保证本地事务与消息发送的一致性 ✓ 正确答案
# 12. 事务性发件箱（Transactional Outbox）模式，业务事件写入 outbox 表？ A Outbox 模式只用于 Redis 消息，不适用于任何 MQ B 业务事件与业务操作在同一数据库事务内写入 outbox 表，由独立投递器异步发送 ✓ 正确答案 C Outbox 表不需要关联业务事务，可任意写入 D 投递器发送失败后事件直接被丢弃，无需重试
# 13. 本地消息表（Local Message Table）模式，业务库 + 消息表同事务写入？ A 本地消息表发送后消息立即删除，不保存任何状态 B 业务更新与消息写入同事务提交，服务器崩溃后待发消息仍可恢复重新发送 ✓ 正确答案 C 本地消息表与业务库无关，可独立写入 D 该模式保证消息恰好发送一次，不可能重复
# 14. Exactly-Once 投递的语义，消息系统与业务系统的协同？ A 消息系统单独即可保证 Exactly-Once，无需业务配合 B Exactly-Once 需消息系统可靠投递与业务系统幂等消费协同实现 ✓ 正确答案 C Exactly-Once 等价于 At-Least-Once D 幂等消费只能用于 Redis，无法用于消息处理
# 15. 幂等性（Idempotency）的定义，相同请求执行多次与一次效果相同？ A 幂等性指操作执行次数越多效果越强 B 幂等性指同一操作执行多次与执行一次的效果相同，是安全重试的基础 ✓ 正确答案 C 所有接口天然幂等，无需设计 D 幂等性只与数据库无关，仅影响网络层
# 16. 幂等键（Idempotency Key）的应用，支付、退款、消息处理？ A 支付/退款/消息处理用幂等键配合唯一索引防止重复扣款与重复消费 ✓ 正确答案 B 幂等键只在支付场景使用，退款与消息无需 C 幂等键不需要唯一约束，靠内存判断即可 D 幂等键会在并发下失效，无法防止重复扣款
# 17. 消息队列的重复消费，Exactly-Once vs At-Least-Once？ A MQ 本身默认保证 Exactly-Once，无需业务处理 B At-Most-Once 能保证消息不丢，是最佳选择 C 默认 At-Least-Once 语义下可能重复消费，需应用层幂等消化重复 ✓ 正确答案 D 重复消费只会发生在内存队列，与 MQ 无关
# 18. 重复事件（Duplicate Event）的检测，幂等键、版本号？ A 重复事件检测与消息系统无关，只能靠人工 B 只需幂等键，版本号无意义 C 版本号只能用于数据库，无法用于事件 D 幂等键去重相同事件，版本号防止旧版本覆盖新状态 ✓ 正确答案
# 19. 重试（Retry）的策略，指数退避、抖动、最大重试次数？ A 指数退避增长间隔，加入抖动避免惊群，并设置最大重试次数防止无限重试 ✓ 正确答案 B 重试次数越多越好，无需上限 C 抖动会让重试更快，应移除 D 重试不需要幂等，直接重发即可
# 20. 复杂状态机，Hierarchical State Machine（HSM）、Workflow Engine？ A 工作流引擎只能处理单一步骤，无法编排 B HSM 与工作流引擎功能完全相同，只是名字不同 C HSM 用层级父状态复用转移，工作流引擎支持编排、并行与人工干预 ✓ 正确答案 D HSM 比简单状态机更简单，无需层级
# 21. Spring Batch 的分块与重启实现？ A Spring Batch 必须整批一次提交，失败整批回滚 B Chunk 式处理每块提交一次事务，重启时基于 JobRepository 断点续跑 ✓ 正确答案 C 重启后从头重新执行，无法续跑 D Spring Batch 不持久化执行状态
# 22. 批处理的重启（Restart）策略，断点续传、幂等执行？ A 断点续传足够，无需幂等 B 批处理重启后必须从头开始，无法续传 C 幂等执行与重启无关，重启一定重复处理 D 断点续传解决从哪继续处理，幂等执行保证重复处理不产生副作用 ✓ 正确答案
# 23. 批处理（Batch Job）的分块（Chunking）原则，每块多少行？ A 块越大越好，一次提交全部数据最高效 B 分块在吞吐、内存与失败回滚代价之间权衡，通常每块 100~1000 行 ✓ 正确答案 C 块越小遍越快，无任何代价 D 分块与事务无关，仅影响内存
# 24. 批处理的进度跟踪，checkpoint、状态表？ A 批处理无需跟踪进度，一次执行完即可 B checkpoint 只存内存，不持久化 C 状态表只用于展示，崩溃后无法恢复 D checkpoint 记录处理位置用于断点恢复，状态表记录批次元数据用于监控 ✓ 正确答案
# 25. 回调（Callback）的实现，长轮询、Webhook、消息推送？ A 长轮询由客户端请求驱动，Webhook 由服务端主动推送，消息推送通过总线解耦 ✓ 正确答案 B 长轮询与应用推送相同，服务端主动发送 C Webhook 无需接收方地址，服务端自动找到 D 消息推送无法异步，只能同步等待
# 26. 异步任务（Async Task）的数据库实现，任务表 + 状态机？ A 任务表只存内存，重启后任务丢失 B 任务表持久化任务，状态机驱动流转，配合锁避免并发重复执行 ✓ 正确答案 C 异步任务无需状态机，直接执行即可 D 任务表无法支持重试
# 27. 最大努力通知（Best-Effort Notification），业务 + 异步通知？ A 业务成功后异步尽力通知下游，允许延迟与丢失，靠重试与补偿追求最终一致 ✓ 正确答案 B 最大努力通知保证与业务事务强一致 C 最大努力通知只用于强一致场景 D 该模式不进行任何重试，通知一次即止
# 28. 可靠消息投递的语义，At-Least-Once、At-Most-Once、Exactly-Once？ A Exactly-Once 无需业务配合即可实现 B At-Most-Once 保证不丢，是最佳选择 C At-Least-Once 保证不丢但可能重复，配合消费端幂等是工程常用选择 ✓ 正确答案 D 三种语义保证效果完全相同
# 29. 分布式场景中抖动（Jitter）的应用，重试退避中引入随机抖动如何避免惊群与同步风暴，指数退避与全抖动/等抖动策略如何设计？ A 抖动会让重试更集中，加剧故障 B 抖动将重试时间随机化，避免所有客户端同时重试造成惊群与同步风暴 ✓ 正确答案 C 全抖动与等抖动都固定重试时间，不做随机化 D 抖动只影响网络层，与重试无关
