幂等处理方案学习

幂等处理

一.什么是幂等

简单来说，对于同一个系统，在同样条件下，一次请求和重复多次请求对资源的影响是一致的，就称该操作为幂等的。比如说如果有一个接口是幂等的，当传入相同条件时，其效果必须是相同的。

一般我们在系统中，幂等可能存在两种类型的问题：

• 接口幂等：常说的接口防重复提交。
• 消息队列幂等：如何保障消息队列客户端对相同的消息仅消费一次。

二.幂等可能会带来的问题

2.1接口幂等

问题：

• 重复提交：用户多次点击提交按钮或重试请求，导致相同的请求被多次处理。例如，重复下单、重复支付等。

后果：

• 数据不一致：例如，在电商系统中，重复下单可能导致库存减少多次，导致库存不足或错误的库存状态。
• 业务逻辑错误：重复创建资源（如用户、订单、记录等），可能会造成系统中出现重复数据，影响后续处理和查询。
• 经济损失：如重复支付会直接导致用户的金钱损失，影响用户体验并可能引发投诉。
• 状态不一致：例如，用户提交表单后，系统反馈操作成功，但由于重复请求导致状态与实际情况不符，可能引发用户困惑。

2.2消息队列幂等

问题：

• 消息重复消费：由于网络波动、消费者故障或重试机制，可能导致同一消息被多次消费。

后果：

• 数据重复处理：如果同一条消息被多次消费，可能导致系统对相同事件的多次处理，例如再次扣款、重复发货、重复记录日志等。
• 业务逻辑混乱：在复杂的业务流程中，重复消费消息可能导致状态混乱，例如用户行为记录、任务状态更新等。
• 资源浪费：多次处理相同消息可能导致资源的浪费，例如 CPU、内存、数据库连接等。
• 系统性能下降：在高并发情况下，重复消费的消息可能会加重系统的负担，导致性能下降和响应延迟。

三.如何解决接口幂等问题

3.1分布式锁

当用户提交请求时，服务器端可以生成一个唯一的标识，例如使用 UUID。

在处理用户请求之前，服务器尝试获取一个分布式锁。如果成功获取到分布式锁，那么则执行接下来的正常业务逻辑流程。因为锁已经被获取，这样可以确保其他请求无法使用相同的标识，避免重复处理。在请求处理完成后，服务器需要释放分布式锁。

如果由于网络波动,导致连续发送了两个创建订单操作,但是他们携带的唯一标识是一样的,这样就能起到取出的作用

3.2Token 机制

1.生成Token：在客户端首次发起请求之前，服务端为该特定操作生成一个唯一的Token（通常是一个随机字符串）。这个Token需要具备不可预测性和时效性，以确保安全性。
2. 传递Token：生成的Token随初始请求一起发送给客户端，客户端在后续的相同操作请求中携带此Token。
3. 存储Token：服务端接收到Token后，将其存储在一个全局可访问的地方，如Redis数据库，键值对形式存储，键通常是Token值，值可以是操作标识或者过期时间等元数据。
4. 验证Token：当客户端再次发起相同的请求时，必须包含第一次请求时获得的Token。服务端接收请求后，首先检查提供的Token是否有效（比如是否存在于Redis中，是否过期）。
5. 执行操作与删除Token：如果Token有效，服务端执行请求对应的业务逻辑一次，并在操作完成后从存储中移除或标记Token为已使用，防止同一Token被再次使用。
6. 幂等性保障：如果因为网络重传或其他原因导致相同的请求再次到达，由于Token已经被验证并处理过，服务端将识别出重复请求，并直接返回第一次操作的结果或告知请求已经处理，从而保证接口的幂等性。

反思

选择合适的幂等性解决方案需基于业务需求、并发场景及系统架构。分布式锁虽然有效，但增加了系统复杂性和性能开销。Token 机制则需谨慎管理有效性和存储，以避免在高并发情况下的延迟和存储压力。整体来看，幂等性不仅是技术实现，更是对业务逻辑的深刻理解与设计，必须平衡安全性、性能与用户体验之间的关系。