文档解析API哪个好用
2026/1/7 22:29:46
幂等性介绍
现如今很多系统都会基于分布式或微服务思想完成对系统的架构设计。那么在这一个系统中，就会存在若干个微服务，而且服务间也会产生相互通信调用。那么既然产生了服务调用，就必然会存在服务调用延迟或失败的问题。当出现这种问题，服务端会进行重试等操作或客户端有可能会进行多次点击提交。如果这样请求多次的话，那最终处理的数据结果就一定要保证统一，如支付场景。此时就需要通过保证业务幂等性方案来完成
幂等性不仅仅只是一次或多次操作对资源没有产生影响，还包括第一次操作产生影响后，以后多次操作不会再产生影响。并且幂等关注的是是否对资源产生影响，而不关注结果。
以SQL为例：
select * from table where id=1此SQL无论执行多少次，虽然结果有可能出现不同，都不会对数据产生
改变，具备幂等性。
insert into table(id,name) values(1,'heima') 。此SQL如果id或name有唯一性约束，多次操作只允许插入一条记录，则具备幂等性。如果不是，则不具备幂等性，多次操作会产生多条数据。
update table set score=100 where id = 1 。此SQL无论执行多少次，对数据产生的影响都是相同的。具备幂等性。
幂等性设计主要从两个维度进行考虑：空间、时间
空间：定义了幂等的范围，如生成订单的话，不允许出现重复下单。
时间：定义幂等的有效期。有些业务需要永久性保证幂等，如下单、支付等。而部分业务只要保证一段时间幂等即可。
同时对于幂等的使用一般都会伴随着出现锁的概念，用于解决并发安全问题。
业务问题抛出
在业务开发与分布式系统设计中，幂等性是一个非常重要的概念，有非常多的场景需要考虑幂等性的问题，尤其对于现在的分布式系统，经常性的考虑重试、重发等操作，一旦产生这些操作，则必须要考虑幂等性问题。以交易系统、支付系统等尤其明显，如：
当用户购物进行下单操作，用户操作多次，但订单系统对于本次操作只能产生一个订单。
当用户对订单进行付款，支付系统不管出现什么问题，应该只对用户扣一次款。
当支付成功对库存扣减时，库存系统对订单中商品的库存数量也只能扣减一次。
当对商品进行发货时，也需保证物流系统有且只能发一次货。
在电商系统中还有非常多的场景需要保证幂等性。但是一旦考虑幂等后，服务逻辑务必会变的更加复杂。因此是否要考虑幂等，需要根据具体业务场景具体分析。而且在实现幂等时，还会把并行执行的功能改为串行化，降低了执行效率。
此处以下单减库存为例，当用户生成订单成功后，会对订单中商品进行扣减库存。 订单服务会调用库存服务进行库存扣减。库存服务会完成具体扣减实现。
现在对于功能调用的设计，有可能出现调用超时，因为出现如网络抖动，虽然库存服务执行成功了，但结果并没有在超时时间内返回，则订单服务也会进行重试。那就会出现问题，stock对于之前的执行已经成功了，只是结果没有按时返回。而订单服务又重新发起请求对商品进行库存扣减。 此时出现库存扣减两次的问题。对于这种问题，就需要通过幂等性进行结果。
HTTP协议语义幂等性
HTTP协议有两种方式：RESTFUL、SOA。现在对于WEB API，更多的会使用RESTFUL风格定义。为了更好的完成接口语义定义，HTTP对于常用的四种请求方式也定义了幂等性的语义。
GET：用于获取资源，多次操作不会对数据产生影响，具有幂等性。注意不是结果。
POST：用于新增资源，对同一个URI进行两次POST操作会在服务端创建两个资源，不具有幂等性。
PUT：用于修改资源，对同一个URI进行多次PUT操作，产生的影响和第一次相同，具备幂等性。
DELETE：用于删除资源，对同一个URI进行多次DELETE操作，产生的影响和第一次相同，具备幂等性。
综上所述，这些仅仅只是HTTP协议建议在基于RESTFUL风格定义WEB API时的语义，并非强制性。同时对于幂等性的实现，肯定是通过前端或服务端完成。
接口幂等
对于幂等的考虑，主要解决两点前后端交互与服务间交互。这两点有时都要考虑幂等性的实现。从前端的思路解决的话，主要有三种：前端防重、PRG模式、Token机制。
token机制
通过token机制来保证幂等是一种非常常见的解决方案，同时也适合绝大部分场景。该方案需要前后端进行一定程度的交互来完成。
服务端提供获取token接口，供客户端进行使用。服务端生成token后，如果当前为分布式架构，将token存放于redis中，如果是单体架构，可以保存在jvm缓存中。
当客户端获取到token后，会携带着token发起请求。
服务端接收到客户端请求后，首先会判断该token在redis中是否存在。如果存在，则完成进行业务处理，业务处理完成后，再删除token。如果不存在，代表当前请求是重复请求，直接向客户端返回对应标识。
但是现在有一个问题，当前是先执行业务再删除token。在高并发下，很有可能出现第一次访问时token存在，完成具体业务操作。但在还没有删除token时，客户端又携带token发起请求，此时，因为token还存在，第二次请求也会验证通过，执行具体业务操作。
对于这个问题的解决方案的思想就是并行变串行。会造成一定性能损耗与吞吐量降低。
第一种方案：对于业务代码执行和删除token整体加线程锁。当后续线程再来访问时，则阻塞排队。
基于自定义业务流程实现Token机制
核心代码如下
@Componentpublic class FeignInterceptor implements RequestInterceptor {@Overridepublic void apply(RequestTemplate requestTemplate) {//传递令牌RequestAttributes requestAttributes = RequestContextHolder.getRequestAttributes();if (requestAttributes != null){HttpServletRequest request = ((ServletRequestAttributes)requestAttributes).getRequest();if (request != null){Enumeration<String> headerNames = request.getHeaderNames();while (headerNames.hasMoreElements()){String headerName = headerNames.nextElement();if ("token".equals(headerName)){String headerValue = request.getHeader(headerName);//传递tokenrequestTemplate.header(headerName,headerValue);}}}}}}
服务幂等
防重表
对于防止数据重复提交，还有一种解决方案就是通过防重表实现。防重表的实现思路也非常简单。首先创建一张表作为防重表，同时在该表中建立一个或多个字段的唯一索引作为防重字段，用于保证并发情况下，数据只有一条。在向业务表中插入数据之前先向防重表插入，如果插入失败则表示是重复数据。
对于防重表的解决方案，可能有人会说为什么不使用悲观锁。悲观锁在使用的过程中也是会发生死锁的。悲观锁是通过锁表的方式实现的。 假设现在一个用户A访问表A（锁住了表A），然后试图访问表B； 另一个用户B访问表B（锁住了表B），然后试图访问表A。 这时对于用户A来说，由于表B已经被用户B锁住了，所以用户A必须等到用户B释放表B才能访问。 同时对于用户B来说，由于表A已经被用户A锁住了，所以用户B必须等到用户A释放表A才能访问。此时死锁就已经产生了。
MySQL乐观锁
select+insert防重提交
分布式锁
消息幂等
在系统中当使用消息队列时，无论做哪种技术选型，有很多问题是无论如何也不能忽视的，如：消息必达、消息幂等等。本章节以典型的RabbitMQ为例，讲解如何保证消息幂等的可实施解决方案，其他MQ选型均可参考。
消息重试演示
消息队列的消息幂等性，主要是由MQ重试机制引起的。因为消息生产者将消息发送到MQ-Server后，MQ-Server会将消息推送到具体的消息消费者。假设由于网络抖动或出现异常时，MQ-Server根据重试机制就会将消息重新向消息消费者推送，造成消息消费者多次收到相同消息，造成数据不一致。
在RabbitMQ中，消息重试机制是默认开启的，但只会在consumer出现异常时，才会重复推送。在使用中，异常的出现有可能是由于消费方又去调用第三方接口，由于网络抖动而造成异常，但是这个异常有可能是暂时的。所以当消费者出现异常，可以让其重试几次，如果重试几次后，仍然有异常，则需要进行数据补偿。
数据补偿方案：当重试多次后仍然出现异常，则让此条消息进入死信队列，最终进入到数据库中，接着设置定时job查询这些数据，进行手动补偿。
1、修改consumer一方的配置文件
# 消费者监听相关配置listener:simple:retry:# 开启消费者(程序出现异常)重试机制，默认开启并一直重试enabled: true# 最大重试次数max‐attempts: 5# 重试间隔时间(毫秒)initial‐interval: 3000
2、 设置消费异常
当consumer消息监听类中添加异常，最终接受消息时，可以发现，消息在接收五次后，最终出现异常
消息幂等解决
要保证消息幂等性的话，其实最终要解决的就是保证多次操作，造成的影响是相同的。那么其解决方案的思路与服务间幂等的思路其实基本都是一致的。
消息防重表，解决思路与服务间幂等的防重表一致。
redis。利用redis防重。