146 lines
6.7 KiB
Markdown
146 lines
6.7 KiB
Markdown
---
|
||
tags: [test/review, architecture, arch/idempotency]
|
||
create time: 2026-08-09 12:00
|
||
---
|
||
|
||
# 幂等设计方案 — 测试题
|
||
|
||
## 概述
|
||
本测试覆盖六种主流幂等方案（唯一索引防重、Token 预获取、乐观锁版本号校验、状态机校验、网关 Request ID 去重）以及三层防御最佳实践。共 10 道题目（6 选择 + 3 填空 + 1 简答）。
|
||
|
||
---
|
||
|
||
## 一、选择题（6道，由浅入深）
|
||
|
||
> **难度阶梯**: Q1-Q2 基础概念 → Q3-Q4 核心原理 → Q5-Q6 深入应用/边界场景
|
||
|
||
### Q1（基础）— 考察定义层面
|
||
|
||
以下哪个描述最准确地表达了"幂等"的概念？
|
||
|
||
A. 相同的请求只在系统中出现一次
|
||
B. 多次执行同一操作与执行一次的效果相同
|
||
C. 使用 Redis SETNX 来防止重复执行
|
||
D. 数据库的 UNIQUE INDEX 约束
|
||
|
||
### Q2（基础）→
|
||
|
||
以下哪种幂等方案**不适合**短延迟批处理场景（如批量导入数据）？
|
||
|
||
A. 数据库唯一索引防重
|
||
B. Token 预获取模式
|
||
C. 乐观锁版本号校验
|
||
D. 网关层 Request ID 去重
|
||
|
||
### Q3（进阶）— 核心原理
|
||
|
||
Lua 脚本 `if redis.call("GET", key) == expected then redis.call("SET", key, "USED") end` 在 Token 幂等模式中的核心作用是什么？
|
||
|
||
A. 设置 Token 的过期时间
|
||
B. 原子性地检查 Token 是否有效并标记为已使用
|
||
C. 生成一个新的 Token
|
||
D. 删除已经过期的所有 Token
|
||
|
||
### Q4（进阶）— 比较/辨析
|
||
|
||
以下关于各幂等方案的对比中，哪一个是错误的？
|
||
|
||
A. 唯一索引防重的实现复杂度低但会额外占用存储
|
||
B. Token 预获取可以防止 CSRF
|
||
C. 状态机校验不需要额外的数据结构
|
||
D. 网关 Request ID 方案可以保证跨重试窗口外的重复请求也被拦截
|
||
|
||
### Q5（深入）— 场景推理
|
||
|
||
某支付系统收到同一笔交易的重复扣款请求（同一个 biz_no）。以下哪种组合方案能提供最可靠的防护？
|
||
|
||
A. 仅用数据库唯一索引
|
||
B. 仅用网关 Request ID
|
||
C. 三层防御：网关 Request ID → Token 模式 → 数据库唯一索引兜底
|
||
D. 仅用乐观锁版本号
|
||
|
||
### Q6（深入）— 源码级/边界场景
|
||
|
||
使用唯一索引做幂等时，以下哪种做法可以正确避免 ToCToU 竞态条件？
|
||
|
||
A. SELECT count(1) WHERE biz_no='xxx'，如果为 0 则 INSERT
|
||
B. 直接 INSERT，利用 Duplicate entry 错误判断已被处理过
|
||
C. SELECT FOR UPDATE 后手动插入
|
||
D. 先在内存 Map 中记录已处理的 biz_no
|
||
|
||
---
|
||
|
||
## 二、填空题（3道）
|
||
|
||
### F1 — 填空1
|
||
|
||
去重是_____，幂等是_____。去重是手段，幂等是目标——用唯一索引去重是为了达到幂等效果。
|
||
|
||
> **提示**: 原文中有明确的区分："XX是强调语义...YY是强调数据..."
|
||
|
||
### F2 — 填空2
|
||
|
||
Token 预获取模式中，客户端先调用 _____ 接口获取一次性 Token，服务端存入 Redis 并设置过期时间（如 5 分钟），然后客户端携带 Token 发起实际业务请求。
|
||
|
||
> **提示**: 回想原文中描述的完整流程步骤。
|
||
|
||
### F3 — 填空3
|
||
|
||
Redis SETNX **不适合**单独做业务幂等的原因是：Redis 非持久化宕机可能丢数据；而且 SETNX 只能保证互斥，不能保证"之前是否已经_____过"。
|
||
|
||
> **提示**: 考虑 SETNX 的能力边界。
|
||
|
||
---
|
||
|
||
## 三、简答题（1道）
|
||
|
||
### S1
|
||
|
||
某电商下单接口面临用户重复点击导致重复创建订单的问题。请设计一个完整的幂等方案，要求：
|
||
1. 从流量入口到数据存储的全链路设计
|
||
2. 说明每层的作用和依赖关系
|
||
3. 讨论失败降级策略
|
||
|
||
> **答题框架提示**:
|
||
> 1. 第一道防线：什么位置做什么事
|
||
> 2. 第二道防线：什么机制保证什么
|
||
> 3. 第三道防线：最终兜底
|
||
> 4. 异常场景分析
|
||
|
||
---
|
||
|
||
## 参考答案与解析
|
||
|
||
### 选择题答案
|
||
|
||
| 题号 | 正确答案 | 解析 |
|
||
|------|---------|------|
|
||
| Q1 | B | 幂等的定义是"多次执行与执行一次效果相同"。A 是去重的定义，C 和 D 是实现幂等的手段而非定义本身。 |
|
||
| Q2 | B | Token 模式需要多一次 API 调用（先领 token 再提交），对于批量导入这种高频操作会严重拖慢用户体验。此时唯一索引方案更合适。 |
|
||
| Q3 | B | Lua 脚本将 GET 和 SET 打包成原子操作——不存在 ToCToU 竞态。如果分开执行两个步骤，其他线程可能在中间时刻拿到同一个 Token。 |
|
||
| Q4 | D | D 是错误的！网关 Request ID 只保护单次请求窗口内的重复（通常设定 TTL 如 300 秒），超出窗口的重复请求无法覆盖。这是其固有限制。 |
|
||
| Q5 | C | 三层防御互为补充：网关层拦截大部分重复流量降低后端压力，Token 模式控制高风险操作的不可重入性，数据库唯一索引作为最后防线保证最终一致性。任何一层被突破都有下一层兜住。 |
|
||
| Q6 | B | 直接 INSERT 利用 Duplicate entry 错误是最原子性的做法。A 是典型的 ToCToU——检查和插入之间有竞态窗口。C 的 SELECT FOR UPDATE 也可以但不如 D 简洁高效。D 的内存 Map 不解决分布式问题。 |
|
||
|
||
### 填空题答案
|
||
|
||
| 题号 | 答案 | 解析 |
|
||
|------|------|------|
|
||
| F1 | `数据`；`语义` | 去重强调数据层面——相同的请求只出现一次；幂等强调语义层面——多次执行结果相同。去重是手段，幂等是目标。 |
|
||
| F2 | `/token/generate` | Token 预获取流程：① 客户端调用 /token/generate 获取一次性 Token；② 服务端存入 Redis，UNUSABLE 状态，5 分钟过期；③ 客户端携带 Token 发起业务请求；④ 服务端 Lua 原子消费 Token。 |
|
||
| F3 | `成功执行` | SETNX 只能保证"此刻没人持有这个 key"，但不能回答"之前是否已经成功处理过这个请求"。除非你在 Redis 里也存一份状态——那本质上就是把数据库该做的事搬到了 Redis。 |
|
||
|
||
### 简答题参考答案
|
||
|
||
S1：**参考答案要点**：
|
||
1. **第一道防线（网关层）**：客户端在 HTTP 头中携带 X-Request-ID（UUID），网关层用 Redis SETNX reqid:id 1 EX 300s 做去重。重复请求直接从缓存返回之前的响应。
|
||
2. **第二道防线（业务层）**：对支付等高风险接口采用 Token 模式——用户必须先领取一次性 Token 才能提交订单，Token 原子消费确保不可重入。
|
||
3. **第三道防线（存储层）**：order_idempotent 表以 biz_no 为唯一索引。INSERT 时 Duplicate entry → 查询已有结果返回。
|
||
4. **异常降级**：网关层 Redis 挂了时放行（靠后续两层兜底）；Token 服务挂了时切换到 Request ID 模式（用户体验下降但不会中断）；数据库层永远生效因为它是物理约束。
|
||
|
||
**评分标准**：答出任意 2 个要点即可得满分；完全正确需覆盖全部要点。
|
||
|
||
## 关联笔记
|
||
- [[Redis 分布式锁]]
|
||
- [[ZooKeeper 分布式锁]]
|