幂等性概念及场景
- 概念：多次调用方法或接口不改变业务状态，重复调用结果与单次调用一致。例如在京东下单，多次点击提交订单只能成功一次。
- 场景：包括用户重复点击、网络波动导致多次请求、mq 消息重复消费、代码中设置失败或超时重试机制等情况都需保证幂等性。
不同请求类型的幂等分析
- GET 请求：查询操作天然幂等，多次查询结果相同。
- POST 请求：新增操作，多次请求结果不同，需考虑幂等解决方案。
- PUT 请求：更新操作，若为绝对值更新则幂等，增量更新则非幂等。如“update item set money = 500 where id = 1”是幂等的，“set money = money + 500”不是幂等的。
- DELETE 请求：一般根据唯一值删除，本身是幂等的。
幂等性解决方案
-
数据库唯一索引：适用于解决新增操作的幂等性问题，但要求表中有相应的唯一索引。
-
token 加 redis 方案
-
- 适用范围：可解决新增和修改操作的幂等性问题，较为通用，能满足创建商品、提交订单、转账支付等多种业务场景。
- 流程：第一次请求（如查看商品详情）时，后台生成唯一的 token（可使用 uuid），以当前登录用户为 key、token 为 value 存储到 redis，并返回给前端。第二次请求（如提交订单）时，前端携带 token 访问服务端，服务端在 redis 中查找该 token，若存在则处理业务并删除 token，若不存在则直接返回。通过这种方式保证只有一个请求能成功处理业务，实现幂等性。
-
分布式锁方案
- 原理：通过加锁处理来解决新增和修改操作的幂等性问题。
- 流程：先获取分布式锁（如使用 redis 提供的分布式锁），判断是否获取成功。若失败则快速响应新增或修改失败；若成功则正常处理下单等操作，最后务必手动释放锁，并注意控制锁的力度，尽量保持最小范围，以减少对性能的影响。
回答面试官问题思路
首先解释幂等性概念，接着说明新增或修改操作可能引发幂等问题。对于新增数据，可根据表中是否有唯一索引选择使用数据库唯一索引，若没有则可采用分布式锁或 token 加 redis 方案，其中 token 加 redis 方案性能相对较高，并详细描述其流程。
