在 PHP 面试中，特别是涉及 ThinkPHP 框架的中高级岗位，幂等设计与重复请求处理是高频且能区分候选人深度的考点。很多开发者能说出“用 Redis 加锁”，但面试官更想听到你对业务场景、锁粒度、异常兜底和框架集成的系统性思考。本文将以 ThinkPHP 为背景，拆解这一问题的完整回答逻辑。
一、为什么幂等设计是面试必问？
实际业务中，重复请求无处不在：
- 用户手抖连续点击“提交订单”
- 网络超时导致客户端重试
- 消息队列重复投递
- 第三方支付回调多次通知
- 网关或 Nginx 重试机制
如果接口不具备幂等性，轻则产生重复数据，重则引发资金损失。面试官通过这个问题，可以考察你是否具备生产环境思维，而不仅仅是增删改查。
二、幂等设计的核心思路
幂等的本质是：同一个业务操作，无论执行多少次，对系统状态的影响都相同。
在 ThinkPHP 中，常见实现方案有以下几种，面试时建议按“由简到繁”的顺序阐述。
1. 数据库唯一索引（最简单可靠）
适用于插入类操作。例如用户领取优惠券，可以建立 user_id + coupon_id 的唯一索引。
// 控制器中捕获异常
try {
Db::name('user_coupon')->insert([
'user_id' => $userId,
'coupon_id' => $couponId,
]);
} catch (\think\exception\PDOException $e) {
// 唯一索引冲突，说明已领取
return json(['code' => 0, 'msg' => '请勿重复领取']);
}
面试加分点：不要只依赖 SELECT 再 INSERT，并发下必然穿透。唯一索引是最后一道防线。
2. 悲观锁与乐观锁
- 悲观锁：
SELECT ... FOR UPDATE，适合强一致场景，但会阻塞。 - 乐观锁：版本号字段，更新时
WHERE version = old_version，适合读多写少。
ThinkPHP 中乐观锁示例：
$affected = Db::name('order')
->where('id', $orderId)
->where('version', $version)
->update(['status' => 1, 'version' => $version + 1]);
if (!$affected) {
throw new Exception('操作冲突，请重试');
}
3. Redis 分布式锁 + 令牌机制
这是面试中最常被追问的方案。核心流程：
- 客户端先申请一个唯一令牌（token）
- 提交请求时携带该 token
- 服务端用 Redis
SETNX判断 token 是否存在 - 存在则删除 token 并执行业务；不存在则拒绝
ThinkPHP 中可封装一个幂等服务：
class IdempotentService
{
public function check(string $token, int $expire = 60): bool
{
$key = 'idempotent:' . $token;
$redis = Cache::store('redis')->handler();
// SETNX + 过期时间，保证原子性
$result = $redis->set($key, 1, ['nx', 'ex' => $expire]);
return (bool)$result;
}
}
注意：一定要设置过期时间，否则死锁。同时要说明 Redlock 的争议，以及生产环境更推荐用 Lua 脚本保证原子性。
4. 状态机幂等
对于订单、支付等有状态流转的业务，通过状态判断实现幂等。例如支付回调：
$order = Db::name('order')->where('order_no', $orderNo)->find();
if ($order['status'] != 0) {
// 已处理过，直接返回成功
return 'success';
}
// 更新订单状态并记录流水
这种方式天然幂等，且能防止并发更新，建议配合 WHERE status = 0 条件更新。
三、重复请求处理的完整链路
面试时不要只谈单点方案，要展示全链路思维：
| 层级 | 措施 |
|---|---|
| 前端 | 按钮禁用、防抖、加载动画 |
| 网关/Nginx | limit_req 限流 |
| 应用层 | Token 机制、Redis 锁 |
| 业务层 | 状态机、唯一索引 |
| 数据层 | 唯一约束、事务 |
在 ThinkPHP 中，可以结合中间件实现统一拦截：
// app/middleware/Idempotent.php
public function handle($request, \Closure $next)
{
$token = $request->header('X-Idempotent-Token');
if ($token && !$this->checkToken($token)) {
return json(['code' => 429, 'msg' => '请勿重复提交']);
}
return $next($request);
}
注册中间件后，所有需要幂等的路由自动生效，代码侵入性低。
四、面试高频追问与应对
追问 1：Redis 锁超时了但业务还没执行完怎么办？
答：这是经典问题。方案包括：看门狗自动续期（Redisson 思路）、将锁的 value 设为唯一值并在释放时校验、或者改用状态机 + 数据库乐观锁兜底。面试时要坦诚说明没有银弹，要结合业务容忍度选择。
追问 2：分布式锁和唯一索引，选哪个？
答：唯一索引是最终一致性保障，适合插入；分布式锁用于减少并发冲突，提升性能。生产环境通常两者结合：先用 Redis 挡掉大部分重复请求，再用唯一索引兜底。
追问 3：ThinkPHP 的事务和锁如何配合？
答：注意 Db::startTrans() 与 lock(true) 的使用顺序。悲观锁必须在事务内生效，且要避免长事务。ThinkPHP 中可写：
Db::startTrans();
try {
$order = Db::name('order')->lock(true)->where('id', $id)->find();
// 业务处理
Db::commit();
} catch (\Exception $e) {
Db::rollback();
}
五、总结
回答“幂等设计与重复请求处理”时，建议按以下结构组织：
- 先讲业务场景，说明为什么需要幂等
- 再列方案对比，从唯一索引到 Redis 锁，体现技术广度
- 重点讲一个方案，深入细节如原子性、过期时间、异常兜底
- 最后谈全链路，展示架构思维
在 ThinkPHP 面试中，能结合框架特性（中间件、Db 门面、事务）落地这些方案，并主动提及并发安全和生产踩坑经验，就能从众多候选人中脱颖而出。记住：面试官要的不是背诵方案，而是你权衡取舍的能力。
未经允许不得转载：任鹏个人博客 » ThinkPHP 面试精讲：幂等设计与重复请求处理
