如何保证分布式情况下的幂等性

最新推荐文章于 2025-05-27 23:03:18 发布
原创 最新推荐文章于 2025-05-27 23:03:18 发布 · 564 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#分布式

文章探讨了分布式服务中幂等性的概念，列举了重复提交、接口幂等的含义，并详细解释了如何通过唯一主键、Token机制和数据库乐观锁等方式实现幂等性，强调根据业务场景选择合适的解决方案。

关于这个分布式服务的幂等性，这是在使用分布式服务的时候会经常遇到的问题，比如，重复提交的问题。而幂等性，就是为了解决问题存在的一个概念了。

什么是幂等

幂等（idempotent、idempotence）是⼀个数学与计算机学概念，常⻅于抽象代数中。

在编程中⼀个幂等操作的特点是其任意多次执⾏所产⽣的影响均与⼀次执⾏的影响相同。幂等函数，或 幂等⽅法，是指可以使⽤相同参数重复执⾏，并能获得相同结果的函数。这些函数不会影响系统状态， 也不⽤担⼼重复执⾏会对系统造成改变。例如，“setTrue()”函数就是⼀个幂等函数,⽆论多次执⾏，其结 果都是⼀样的，更复杂的操作幂等保证是利⽤唯⼀交易号(流⽔号)实现.

接⼝幂等性就是⽤户对于同⼀操作发起的⼀次请求或者多次请求的结果是⼀致的，不会因为多次点击⽽ 产⽣了副作⽤。

什么是接口的幂等性

在HTTP/1.1中，对幂等性进行了定义。它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外），即第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。这里的副作用是不会对结果产生破坏或者产生不可预料的结果。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。

不能保证幂等性的操作

  • 前端重复提交表单：在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。

  • 用户恶意进行刷单：例如在实现用户投票这种功能时，如果用户针对一个用户进行重复提交投票，这样会导致接口接收到用户重复提交的投票信息，这样会使投票结果与事实严重不符。

  • 接口超时重复提交：很多时候 HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。

  • 消息进行重复消费：当使用 MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。

如果放到数据库的操作层面，那么就有很多操作需要去保证幂等性了。

  • A: 查询操作

查询对于结果是不会有改变的，查询⼀次和查询多次，在数据不变的情况下，查询结果是⼀样的。 select是天然的幂等操作

  • B: 删除操作

删除⼀次和多次删除都是把数据删除。(注意可能返回结果不⼀样，删除的数据不存在，返回0，删除 的数据多条，返回结果多个,在不考虑返回结果的情况下,删除操作也是具有幂等性的)

  • C: 更新操作

修改在⼤多场景下结果⼀样,但是如果是增量修改是需要保证幂等性的,如下例⼦:

把表中id为XXX的记录的A字段值设置为1,这种操作不管执⾏多少次都是幂等的

把表中id为XXX的记录的A字段值增加1,这种操作就不是幂等的

  • D: 新增操作

增加在重复提交的场景下会出现幂等性问题,如以上的⽀付问题

如何实现幂等性

其实实现幂等性的方案有不少，但是呢，这就得需要你根据不同的业务场景去选择合适的方式了。

实现方式一

数据库唯一主键

数据库唯一主键的实现主要是利用数据库中主键唯一约束的特性，一般来说唯一主键比较适用于“插入”时的幂等性，其能保证一张表中只能存在一条带该唯一主键的记录。

使用数据库唯一主键完成幂等性时需要注意的是，该主键一般来说并不是使用数据库中自增主键，而是使用分布式 ID 充当主键（可以参考 Java 中分布式 ID 的设计方案 这篇文章），这样才能能保证在分布式环境下 ID 的全局唯一性。

而实际上生成这个主键的方式就是在当请求的时候后，生成分布式唯一ID，然后当做主键插入数据库，来保证唯一即可。

实现方式二

Token机制

Token机制，实际上也可以称为 Token 令牌

  1. 服务端提供了发送token的接⼝。我们在分析业务的时候，哪些业务是存在幂等问题的，就必须在 执⾏业务前，先去获取token，服务器会把token保存到redis中。（微服务肯定是分布式了，如果 单机就适⽤jvm缓存）。

  2. 然后调⽤业务接⼝请求时，把token携带过去，⼀般放在请求头部。

  3. 服务器判断token是否存在redis中，存在表示第⼀次请求，这时把redis中的token删除，继续执⾏业务。

  4. 如果判断token不存在redis中，就表示是重复操作，直接返回重复标记给client，这样就保证了业务代码，不被重复执⾏。

实现方式三

数据库乐观锁

数据库乐观锁方案一般只能适用于执行“更新操作”的过程，我们可以提前在对应的数据表中多添加一个字段，充当当前数据的版本标识。这样每次对该数据库该表的这条数据执行更新时，都会将该版本标识作为一个条件，值为上次待更新数据中的版本标识的值。

为了每次执行更新时防止重复更新，确定更新的一定是要更新的内容，我们通常都会添加一个 version 字段记录当前的记录版本，这样在更新时候将该值带上，那么只要执行更新操作就能确定一定更新的是某个对应版本下的信息。

这样的话，有了 version 的存在，这样就能保住更新的幂等，多次更新对结果不会产生影响。

你还了解有哪些实现幂等性操作的方式呢？

分布式架构中的幂等性
07-24
在分布式系统中，将原本需要通过分布式事务来保证的操作分解成一系列幂等性的异步消息处理过程。例如，通过消息队列发送消息，并确保消息的处理过程是幂等的，这样即使消息重发，也不会导致不一致的状态。 #### 四...
【分布式系统】幂等性
2301_79757798的博客
02-19 763
在计算机科学和数学领域中，” 幂等性 “虽然源于相同的概念，但其应用和具体含义有所不同。
Redission分布式锁实现接口幂等性
囚徒之困
08-07 1040
接口幂等性，redission分布式锁
分布式系统下如何保障幂等性？
码上就行-Java的博客
10-01 1490
在分布式系统中，幂等性是保障系统稳定性和数据一致性的关键之一。Redis凭借其内存操作的高性能、分布式支持以及原子性操作的特性，成为了幂等性保障的理想选择。在高并发场景下，Redis的SetNX命令为幂等性提供了简洁而高效的解决方案。同时，在极端情况下，通过CAP理论，我们可以选择适当的权衡策略来应对Redis宕机或网络延迟的问题。尽管Redis有其独特的优势，但在不同的场景中，数据库索引、状态控制、分布式锁等其他方式也可以用来保障幂等性，确保系统的可靠性和一致性。t=O83A。
分布式.幂等性
记录 分享 成就
07-30 909
数学中在一次元运算为幂等时，其作用在任一元素两次后会和其作用一次的结果相同；在二次元运算为幂等时，自己重复运算的结果等于它自己的元素。计算机学中幂等指多次操作产生的影响只会跟一次执行的结果相同，通俗的说某个行为重复的执行，最终获取的结果是相同的，不会因为重复执行对系统造成变化。......
分布式项目保证消息幂等性的常见策略
累计发表博客60余万字，优快云 博客专家、Java 领域优质创作者、华为云享专家、阿里云专家博主。专注分享 Java 优质文章，毕设实战项目开发，全网粉丝10W+
05-27 1111
在分布式系统中，确保消息消费的幂等性是关键问题。本文介绍了6种常见的幂等策略：1）数据库唯一索引，防止数据重复插入；2）乐观锁，基于版本号控制更新；3）悲观锁，通过行级锁确保数据一致性；4）状态机，按业务流程限制状态流转；5）Redis分布式锁，实现高并发场景下的快速检查；6）Token机制，防止请求重复提交。每种策略适用于不同场景，如订单创建、状态变更、秒杀活动等。实际项目中可根据具体需求组合使用这些策略，以最小成本实现功能要求。
如何保证分布式服务接口的幂等性
通往IT大道的专栏
07-29 451
系统异常时666请求到了，单号更成666，接着888请求到了，单号又更新成888，但是666更新成功的响应丢了，调用方没收到成功响应，自动重试，再次发起666请求，单号又被更新成666了，这数据显然就错了.若有一个订单已支付，就已经有了一条支付流水，那么如果重复发送这个请求，则此时先插入支付流水，orderId已存在，唯一键约束生效，报错插入不进去。对于更新订单服务，可以通过一个版本号机制，每次更新数据前校验版本号，更新数据同时自增版本号，这样的方式，来解决ABA问题，确保更新订单服务的幂等性。
分布式系统接口幂等性
tengxvincent的博客
08-17 4998
1.幂等性定义 1.1 数学定义 1.2 HTTP规范的定义 2. 何种接口提供幂等性 2.1 HTTP支持幂等性的接口 2.2 实际业务 3.分布式系统接口幂等性 References 1.幂等性定义 1.1 数学定义 在数学里，幂等有两种主要的定义： 在某二元运算下，幂...
分布式系统设计之接口幂等性
yingrou5033的博客
10-31 1311
本文介绍了适用于分布式系统下各业务场景下的幂等性设计。接口幂等性是指用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。在表单提交、接口超时的重试机制、mq消费者收到重复消息等场景下，需要做幂等性处理。insert操作，这种情况下多次请求，可能会产生重复数据。是没有问题的。这种情况下多次请求，可能会导致数据错误。
分布式锁与幂等性问题
姚明锋的博客
10-12 1412
分布式系统由独立的服务器通过网络松散耦合组成。在这个系统中每个服务器都是一台独立的主机，服务器之间通过内部网络连接。分布式系统有以下几个特点： 可扩展性：可通过横向水平扩展提高系统的性能和吞吐量。 高可靠性：高容错，即使系统中一台或几台故障，系统仍可提供服务。 高并发性：各机器并行独立处理和计算。 廉价高效：多台小型机而非单台高性能机。 互斥性（锁） 分布式锁条件 （1）：存储空间 锁是一个抽...
Redis分布式锁解决接口幂等的两种方案
12-21
通过编写测试用例，模拟并发调用，验证在分布式锁保护下的接口幂等性，确保在高并发情况下，多次调用接口不会导致数据异常。 ### 五、总结 利用Redis分布式锁解决接口幂等性，既保证了接口的正确性，又简化了开发...
分布式事务-幂等
08-08
总的来说，幂等性是构建可靠分布式系统的关键要素之一，它有助于提高系统的容错性，减少异常情况下的数据不一致问题，同时简化了错误恢复和补偿流程。在设计和实现分布式事务时，充分理解和应用幂等性原则至关重要。
38_分布式系统中接口的幂等性该如何保证？比如不能重复扣款？.zip
11-13
在分布式系统设计中，接口的幂等性是一个关键概念，尤其是在金融系统或者订单处理系统中，确保操作的唯一性和不可重复执行是至关重要的。例如，我们提到的“不能重复扣款”的需求，就直接涉及到幂等性的应用。下面将...
高并发架构设计
不忘初心 砥砺前行
07-04 4133
高并发是指系统或应用程序在同一时间段内接收到大量并发请求的能力。具体来说，高并发环境下系统需要能够同时处理大量的请求，而不会出现性能问题或响应延迟。
性能优化
不忘初心 砥砺前行
02-29 2506
性能问题和Bug不同，后者的分析和解决思路更清晰，很多时候从应用日志（文中的应用指分布式服务下的单个节点）即可直接找到问题根源，而性能问题，其排查思路更为复杂一些。 对应用进行性能优化，是一个系统性的工程，对工程师的技术广度和技术深度都有所要求。一个简单的应用，它不仅包含了应用代码本身，还和容器（虚拟机）、操作系统、存储、网络、文件系统等紧密相关，线上应用一旦出现了性能问题，需要我们从多方...
SnowFlake 分布式 id 生成器
不忘初心 砥砺前行
02-05 2370
在高并发或者分表分库情况下怎么保证数据id的幂等性呢？ 经常用到的解决方案有以下几种。 微软公司通用唯一识别码（UUID） Twitter公司雪花算法（SnowFlake） 基于数据库的id自增 对id进行缓存 这里我们要谈到snowflake算法了 snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID。 其核心思想是：使用41bit作为毫秒数，10...
限流神器Sentinel
不忘初心 砥砺前行
06-12 1688
这篇文章介绍一下阿里开源的流量防卫兵Sentinel，一款非常优秀的开源项目，经过近10年的双十一的考验，非常成熟的一款产品。sentinel顾名思义：卫兵；在Redis中叫做哨兵，用于监控主从切换，但是在微服务中叫做流量防卫兵。Sentinel 以流量为切入点，从流量控制熔断降级系统负载保护等多个维度保护服务的稳定性。丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一。
@Async注解没起效果的场景
不忘初心 砥砺前行
05-11 1085
而在类中直接进行方法的内部调用，在test()方法中调用async()方法，调用的是该类原对象的async方法，相当于调用了this.async()方法，而并非UserService代理类的async()方法。而@Async注解的异步功能，需要使用Spring的AOP生成UserService类的代理对象，该代理对象没法访问UserService类的private方法，因此会出现@Async注解失效的问题。有时候，我们的方法会使用static修饰，这样在调用的地方，可以直接使用类名.方法名，访问该方法了。
分布式锁实现幂等性
最新发布
11-18
<think> 首先，用户的问题是如何使用分布式锁实现幂等性。这基于提供的引用内容。 回顾引用内容： - 引用[1]：描述了使用分布式锁实现接口幂等性的步骤：生成锁key、获取锁、设置过期时间、执行业务逻辑。 - 引用[2]：展示了Redisson实现分布式锁的代码示例，用于处理重复上报数据的场景。 - 引用[3]：提到分布式锁的互斥性和Redis的实现方式。 - 引用[4]：讨论了数据库锁和分布式锁实现幂等性的流程图，使用唯一标识作为Redis key。 - 引用[5]：提供了一个Spring Boot配置示例，用于添加拦截器实现幂等性。 用户的问题是：如何实现幂等性？所以我的回答应该聚焦在分布式锁的具体实现上，参考这些引用。 系统级指令： - 所有行内数学表达式用$...$。 - 独立公式用$$...$$单独成段。 - LaTeX语法正确。 - 使用中文回答。 - 生成相关问题。 - 回答中引用的段落末尾自然地添加引用标识，例如[^1]。 - 回答结构清晰，帮助用户逐步解决问题。 - 尽量保证回答真实可靠。 用户可见层指令： - 回答结构清晰，逐步解决问题。 - 保证真实可靠。 我的回答结构： 1. **解释幂等性**：简要说明什么是幂等性及其重要性。 2. **分布式锁的概念**：解释分布式锁如何帮助实现幂等性。 3. **实现步骤**：基于引用内容，详细描述步骤： - 生成锁key（基于唯一标识）。 - 获取分布式锁（使用Redis等）。 - 设置锁的过期时间。 - 执行业务逻辑。 - 释放锁。 4. **代码示例**：提供代码片段，参考引用中的例子。 5. **注意事项**：讨论设置过期时间、锁的释放等关键点。 6. **生成相关问题**：在最后添加相关问题。 在回答中，引用相关的引用内容，并在末尾添加标识。 生成相关问题： - 基于主题，如：如何选择唯一标识？分布式锁的性能问题？其他实现幂等性的方法？ 确保使用中文。 大纲回答： 1. **引言**：定义幂等性，解释为什么分布式锁有效。 2. **核心步骤**： - 步骤1：确定唯一标识（如请求ID、订单号）。 - 步骤2：基于唯一标识生成分布式锁key。 - 步骤3：尝试获取锁（使用Redis set命令或Redisson）。 - 步骤4：如果获取成功，设置过期时间。 - 步骤5：执行业务逻辑。 - 步骤6：释放锁。 3. **代码示例**：提供一个简单的Redisson或Redis实现。 4. **注意事项**：避免死锁、设置合理的过期时间。 5. **总结**。 6. **相关问题**。 在回答中，自然地添加引用标识。 </think> ### 如何使用分布式锁实现接口幂等性 接口幂等性是指多次重复执行同一操作时，结果与执行一次相同，这在分布式系统中尤为重要，例如防止重复支付或数据重复提交。分布式锁通过确保同一时刻只有一个请求能执行业务逻辑来实现幂等性，核心是利用锁的互斥性（即同一时间只有一个客户端能获取锁）[^3]。下面我将基于引用内容，逐步解释实现方法，并提供代码示例。 #### 1. **理解幂等性与分布式锁的关系** - 幂等性的本质：无论请求执行多少次，系统状态保持一致。例如，重复提交订单时，只创建一次订单。 - 分布式锁的作用：在分布式环境中，使用 Redis、Zookeeper 等中间件实现锁的互斥。当请求到达时，先尝试获取锁；获取成功则执行业务逻辑；获取失败则视为重复请求，直接返回成功或错误提示[^1][^4]。 - 关键优势：减少无效请求对服务端的压力，尤其适用于高并发场景（如物联网设备重复上报数据）[^2]。 #### 2. **实现分布式锁幂等性的步骤** 以下是核心步骤，需结合唯一标识（如订单号、请求ID）作为锁的 key： | 步骤 | 描述 | 关键点 | |------|------|--------| | **步骤1：生成唯一锁 key** | 基于请求参数（如订单号、用户ID）生成分布式锁的 key。例如，订单支付请求使用订单号作为 key。 | 确保 key 全局唯一，避免锁冲突[^1][^4]。 | | **步骤2：尝试获取分布式锁** | 使用 Redis 或 Redisson 的 API 尝试加锁。设置等待时间为 0（非阻塞模式），避免请求堆积。 | 如果锁获取成功，继续下一步；如果失败，直接返回幂等响应（如“操作成功”或错误提示）[^2][^3]。 | | **步骤3：设置锁的过期时间** | 在获取锁后，立即设置一个合理的过期时间（如 10-30 秒）。这是防止死锁的关键：如果业务逻辑异常崩溃，锁能自动释放[^1][^4]。 | | **步骤4：执行业务逻辑** | 在锁保护下执行核心操作（如数据库写入）。此时，系统状态仅被修改一次。 | 业务逻辑应设计为幂等（如使用数据库唯一索引）以增强可靠性[^4]。 | | **步骤5：释放锁** | 业务完成后，主动释放锁。即使设置了过期时间，也应确保在 finally 块中释放，避免资源泄漏[^2][^4]。 | #### 3. **代码实现示例** 以下是一个基于 Redisson 的 Java 示例（参考引用[2]和[5]），适用于 Spring Boot 项目。Redisson 简化了 Redis 分布式锁的 API。 ```java import org.redisson.Redisson; import org.redisson.api.RLock; import org.redisson.api.RedissonClient; import org.redisson.config.Config; public class IdempotentService { private RedissonClient redisson; // 注入 RedissonClient 实例 public void processRequest(String requestId) { // 步骤1: 生成锁 key，基于唯一标识如请求ID String lockKey = "lock:" + requestId; // 步骤2: 获取分布式锁 RLock lock = redisson.getLock(lockKey); boolean isLocked = false; try { // 尝试加锁，等待0秒（非阻塞），设置10秒自动过期 isLocked = lock.tryLock(0, 10, TimeUnit.SECONDS); if (isLocked) { // 步骤3: 锁获取成功，执行业务逻辑 executeBusinessLogic(requestId); } else { // 锁获取失败，代表重复请求 System.out.println("重复请求，直接返回成功"); } } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { // 步骤5: 确保锁被释放 if (isLocked) { lock.unlock(); } } } private void executeBusinessLogic(String requestId) { // 实际业务逻辑，如数据库操作 System.out.println("处理业务: " + requestId); } } ``` - **解释**: - `tryLock(0, 10, TimeUnit.SECONDS)`：第一个参数为等待时间（0 表示不等待），第二个为锁过期时间。这确保了高并发下只有第一个请求能执行业务[^2]。 - **Spring Boot 集成**：通过拦截器自动处理幂等性（参考引用[5]）。示例配置： ```java @Configuration public class WebConfig implements WebMvcConfigurer { @Autowired private IdempotentInterceptor idempotentInterceptor; // 自定义拦截器 @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(idempotentInterceptor); } } ``` 拦截器在请求前检查锁，实现全局幂等控制。 #### 4. **关键注意事项** - **设置合理的过期时间**：过期时间太短可能导致业务未完成锁已释放，引发重复执行；太长则占用 Redis 资源。建议根据业务平均耗时设置（如业务耗时 + 缓冲时间）[^4]。 - **避免死锁**：务必在 `finally` 块中释放锁，即使业务逻辑抛出异常。 - **唯一标识的选择**：使用请求参数（如订单号）或生成唯一 ID（如 UUID），确保不同请求的 key 不冲突[^1]。 - **性能优化**：对于高频请求，Redis 单线程模型可能成为瓶颈；可考虑分片或使用更轻量级锁（如 Lua 脚本）[^3]。 - **适用场景**：适用于重复请求无害的场景（如数据上报），不适用于需保证绝对一致性的操作（需结合事务）[^2]。 #### 5. **总结** 分布式锁是实现接口幂等性的高效方法，通过互斥机制确保同一请求只执行一次核心逻辑。核心步骤包括生成唯一 key、非阻塞加锁、设置过期时间、执行业务和释放锁。结合 Redis 或 Redisson，实现简单可靠。在实际应用中，需测试锁的获取率和业务耗时，以优化过期时间和并发性能[^1][^4]。 ### 相关问题 1. **如何选择分布式锁的唯一标识（key）来避免冲突？** 2. **分布式锁在高并发场景下可能有哪些性能瓶颈？如何优化？** 3. **除了分布式锁，还有哪些实现接口幂等性的方法？** 4. **Redis 分布式锁在集群环境下如何保证可靠性？** 5. **如何处理分布式锁获取失败后的错误反馈机制？** [^1]: 关键步骤包括生成锁 key、获取锁、设置过期时间，确保业务逻辑只执行一次。 [^2]: 使用 Redisson 的 `tryLock(0, timeout)` 实现非阻塞加锁，适用于重复上报场景。 [^3]: 分布式锁的互斥性基于 Redis 单线程模型，适合处理并发请求。 [^4]: 分布式锁实现幂等性的流程图强调唯一标识作为 key 和设置合理过期时间的重要性。 [^5]: Spring Boot 集成示例通过拦截器全局管理幂等性。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值