快速做效果图的网站叫什么区别,广元网络推广,淘宝网店制作,网站推广的优势目录标题 幂等不能解决接口超时吗#xff1f;幂等的重要性什么是幂等?为什么需要幂等?接口超时了#xff0c;到底如何处理#xff1f; 如何设计幂等?幂等设计的基本流程实现幂等的8种方案1.selectinsert主键/唯一索引冲突#xff08;常用#xff09;2.直接insert 主键… 目录标题 幂等不能解决接口超时吗幂等的重要性什么是幂等?为什么需要幂等?接口超时了到底如何处理 如何设计幂等?幂等设计的基本流程实现幂等的8种方案1.selectinsert主键/唯一索引冲突常用2.直接insert 主键/唯一索引冲突3.状态机幂等常用4.抽取防重表5.token令牌前后端交互常用6.悲观锁(如select for update)不用7.乐观锁8.分布式锁分布式环境下常用 HTTP的幂等GET方法HEAD 方法OPTIONS方法DELETE方法POST 方法PUT 方法 幂等不能解决接口超时吗
处理接口超时问题需要综合考虑多个方面包括设置合理的超时时间、实现重试机制、引入熔断器、加强监控和报警、记录详细的日志、实施限流和降级策略、采用异步处理方式、优化代码和逻辑、合理管理资源以及使用缓存和负载均衡等。通过这些措施可以有效提升系统的稳定性和可靠性。同时确保操作的幂等性是处理重试问题的关键可以避免因重试导致的数据不一致。
本篇就主要讲解超时重试带来的幂等性问题。幂等性是处理分布式系统中接口超时和重试问题的一个重要概念但它本身并不直接解决超时问题。幂等性是指一个操作可以多次执行而不会改变结果的状态。在处理超时和重试时确保操作的幂等性可以避免重复操作带来的副作用。
幂等的重要性
当前互联网的系统几乎都是解耦隔离后会存在各个不同系统的相互远程调用。调用远程服务会有三个状态成功失败或者超时。前两者都是明确的状态而超时则是未知状态。我们转账超时的时候如果下游转账系统做好幂等控制我们发起重试那即可以保证转账正常进行又可以保证不会多转一笔。所以掌握幂的用法非常重要
什么是幂等?
幂等是一个数学与计算机科学概念。
在数学中幂等用函数表达式就是f(x) f(f(x))。比如求绝对值的函数就是幂等的abs(x) abs(abs(x))。 计算机科学中幂等表示一次和多次请求某一个资源应该具有同样的副作用或者说多次请求所产生的影响与一次请求执行的影响效果相同。
为什么需要幂等?
举个例子 我们开发一个转账功能假设我们调用下游接口超时了。一般情况下超时可能是网络传输丢包的问题也可能是请求时没送到还有可能是请求到了返回结果却丢了。这时候我们是否可以重试呢如果重试的话是否会多转了一笔钱呢 转账超时
当前互联网的系统几乎都是解耦隔离后会存在各个不同系统的相互远程调用。调用远程服务会有三个状态成功失败或者超时。前两者都是明确的状态而超时则是未知状态。我们转账超时的时候如果下游转账系统做好幂等控制我们发起重试那即可以保证转账正常进行又可以保证不会多转一笔。
其实除了转账这个例子日常开发中还有很多很多例子需要考虑幂等。比如 MQ消息中间件消费者读取消息时有可能会读取到重复消息。重复消费 比如提交form表单时如果快速点击提交按钮可能产生了两条一样的数据前端重复提交 接口超时了到底如何处理
如果我们调用下游接口超时了我们应该怎么处理呢 有两种方案处理
方案一就是下游系统提供一个对应的查询接口。如果接口超时了先查下对应的记录如果查到是成功就走成功流程如果是失败就按失败处理。
拿我们的转账例子来说转账系统提供一个查询转账记录的接口如果渠道系统调用转账系统超时时渠道系统先去查询一下这笔记录看下这笔转账记录成功还是失败如果成功就走成功流程失败再重试发起转账。 方案二下游接口支持幂等上游系统如果调用超时发起重试即可。 两种方案都是挺不错的但是如果是MQ重复消费的场景方案一处理并不是很妥所以我们还是要求下游系统对外接口支持幂等。
如何设计幂等?
既然这么多场景需要考虑幂等那我们如何设计幂等呢
幂等意味着一条请求的唯一性。不管是你哪个方案去设计幂等都需要一个全局唯一的ID去标记这个请求是独一无二的。
如果你是利用唯一索引控制幂等那唯一索引是唯一的如果你是利用数据库主键控制幂等那主键是唯一的如果你是悲观锁的方式底层标记还是全局唯一的ID
全局的唯一性ID
全局唯一性ID我们怎么去生成呢你可以回想下数据库主键Id怎么生成的呢是的我们可以使用UUID但是UUID的缺点比较明显它字符串占用的空间比较大生成的ID过于随机可读性差而且没有递增。
我们还可以使用雪花算法Snowflake 生成唯一性ID。
雪花算法是一种生成分布式全局唯一ID的算法生成的ID称为Snowflake IDs。这种算法由Twitter创建并用于推文的ID。
一个Snowflake ID有64位。
第1位Java中long的最高位是符号位代表正负正数是0负数是1一般生成ID都为正数所以默认为0。接下来前41位是时间戳表示了自选定的时期以来的毫秒数。接下来的10位代表计算机ID防止冲突。其余12位代表每台机器上生成ID的序列号这允许在同一毫秒内创建多个Snowflake ID。 当然全局唯一性的ID还可以使用百度的Uidgenerator或者美团的Leaf。
幂等设计的基本流程
幂等处理的过程说到底其实就是过滤一下已经收到的请求当然请求一定要有一个全局唯一的ID标记哈。然后怎么判断请求是否之前收到过呢把请求储存起来收到请求时先查下存储记录记录存在就返回上次的结果不存在就处理请求。
一般的幂等处理就是这样啦如下 实现幂等的8种方案
幂等设计的基本流程都是类似的我们简简单单来过一下幂等实现的8中方案哈
1.selectinsert主键/唯一索引冲突常用 为什么前面已经select查询了还需要try…catch…捕获重复异常呢
是因为高并发场景下两个请求去select的时候可能都没查到然后都走到insert的地方啦。 当然用唯一索引代替数据库主键也是可以的哈都是全局唯一的ID即可。
2.直接insert 主键/唯一索引冲突
1方案中都会先查一下流水表的交易请求判断是否存在然后不存在再插入请求记录。如果重复请求的概率比较低的话我们可以直接插入请求利用主键/唯一索引冲突去判断是重复请求。 大家别搞混哈防重和幂等设计其实是有区别的。防重主要为了避免产生重复数据把重复请求拦截下来即可。而幂等设计除了拦截已经处理的请求还要求每次相同的请求都返回一样的效果。不过呢很多时候它们的处理流程可以是类似的。 3.状态机幂等常用
很多业务表都是有状态的比如转账流水表就会有0-待处理1-处理中、2-成功、3-失败状态。转账流水更新的时候都会涉及流水状态更新即涉及状态机 (即状态变更图)。我们可以利用状态机实现幂等一起来看下它是怎么实现的。
比如转账成功后把处理中的转账流水更新为成功状态SQL这么写
update transfr_flow set status2 where biz_seq‘666’ and status1;简要流程图如下
状态机是怎么实现幂等的呢
第1次请求来时bizSeq流水号是 666该流水的状态是处理中值是 1要更新为2-成功的状态所以该update语句可以正常更新数据sql执行结果的影响行数是1流水状态最后变成了2。第2请求也过来了如果它的流水号还是 666因为该流水状态已经2-成功的状态了所以更新结果是0不会再处理业务逻辑接口直接返回。
4.抽取防重表
1,2方案都是建立在业务流水表上bizSeq的唯一性上。很多时候我们业务表唯一流水号希望后端系统生成又或者我们希望防重功能与业务表分隔开来这时候我们可以单独搞个防重表。当然防重表也是利用主键/索引的唯一性如果插入防重表冲突即直接返回成功如果插入成功即去处理请求。
5.token令牌前后端交互常用
token 令牌方案一般包括两个请求阶段
客户端请求申请获取token服务端生成token返回客户端带着token请求服务端校验token
流程图如下 1、客户端发起请求申请获取token。 2、服务端生成全局唯一的token保存到redis中一般会设置一个过期时间然后返回给客户端。 3、客户端带着token发起请求。 4、服务端去redis确认token是否存在一般用 redis.del(token)的方式如果存在会删除成功即处理业务逻辑5、如果删除失败不处理业务逻辑直接返回结果。
6.悲观锁(如select for update)不用
什么是悲观锁
通俗点讲就是很悲观每次去操作数据时都觉得别人中途会修改所以每次在拿数据的时候都会上锁。官方点讲就是共享资源每次只给一个线程使用其它线程阻塞用完后再把资源转让给其它线程。
悲观锁如何控制幂等的呢就是加锁呀一般配合事务来实现。
举个更新订单的业务场景 假设先查出订单如果查到的是处理中状态就处理完业务再然后更新订单状态为完成。如果查到订单并且是不是处理中的状态则直接返回 整体的伪代码如下
begin; # 1.开始事务
select * from order where order_id666 # 查询订单判断状态
ifstatus !处理中{//非处理中状态直接返回return ;
}
## 处理业务逻辑
update order set status完成 where order_id666 # 更新完成
commit; # 5.提交事务这种场景是非原子操作的在高并发环境下可能会造成一个业务被执行两次的问题 当一个请求A在执行中时而另一个请求B也开始状态判断的操作。因为请求A还未来得及更改状态所以请求B也能执行成功这就导致一个业务被执行了两次。
可以使用数据库悲观锁select …for update解决这个问题.
begin; # 1.开始事务
select * from order where order_id666 for update # 查询订单判断状态,锁住这条记录
ifstatus !处理中{//非处理中状态直接返回return ;
}
## 处理业务逻辑
update order set status完成 where order_id666 # 更新完成
commit; # 5.提交事务这里面order_id需要是索引或主键哈要锁住这条记录就好如果不是索引或者主键会锁表的 悲观锁在同一事务操作过程中锁住了一行数据。别的请求过来只能等待如果当前事务耗时比较长就很影响接口性能。所以一般不建议用悲观锁做这个事情。
7.乐观锁
悲观锁有性能问题可以试下乐观锁。
什么是乐观锁
乐观锁在操作数据时,则非常乐观认为别人不会同时在修改数据因此乐观锁不会上锁。只是在执行更新的时候判断一下在此期间别人是否修改了数据。
怎样实现乐观锁呢
就是给表的加多一列version版本号每次更新记录version都升级一下versionversion1。具体流程就是先查出当前的版本号version然后去更新修改数据时确认下是不是刚刚查出的版本号如果是才执行更新 比如我们更新前先查下数据查出的版本号是version 1
select order_idversion from order where order_id666然后使用version 1和订单Id一起作为条件再去更新
update order set version version 1statusP where order_id666 and version 1最后更新成功才可以处理业务逻辑如果更新失败默认为重复请求直接返回。 流程图如下 为什么版本号建议自增的呢
因为乐观锁存在ABA的问题如果version版本一直是自增的就不会出现ABA的情况啦。
8.分布式锁分布式环境下常用
分布式锁实现幂等性的逻辑就是请求过来时先去尝试获得分布式锁如果获得成功就执行业务逻辑反之获取失败的话就舍弃请求直接返回成功。执行流程如下图所示 分布式锁可以使用Redis也可以使用ZooKeeper不过还是Redis相对好点因为较轻量级。
Redis分布式锁可以使用命令SET EX PX NX 唯一流水号实现分布式锁的key必须为业务的唯一标识哈 Redis执行设置key的动作时要设置过期时间哈这个过期时间不能太短太短拦截不了重复请求也不能设置太长会占存储空间。
HTTP的幂等
我们的接口一般都是基于http的所以我们再来聊聊Http的幂等吧。HTTP 请求方法主要有以下这几种我们看下各个接口是否都是幂等的。
GET方法
HTTP 的GET方法用于获取资源可以类比于数据库的select查询不应该有副作用所以是幂等的。它不会改变资源的状态不论你调用一次还是调用多次效果一样的都没有副作用。
如果你的GET方法是获取最近最新的新闻不同时间点调用返回的资源内容虽然不一样但是最终对资源本质是没有影响的哈所以还是幂等的。
HEAD 方法
HEAD 方法与 GET 方法类似但只返回响应头不返回响应体。同样不会改变服务器状态。主要区别是HEAD不含有呈现数据而仅仅是HTTP的头信息所以它也是幂等的。如果想判断某个资源是否存在很多人会使用GET实际上用HEAD则更加恰当。即HEAD方法通常用来做探活使用。
OPTIONS方法
HTTP OPTIONS 主要用于获取当前URL所支持的方法也是有点像查询因此也是幂等的。 OPTIONS 方法用于获取目标资源所支持的通信选项。它不会改变服务器状态。
DELETE方法
HTTP DELETE 方法用于删除资源它是的幂等的。比如我们要删除id666的帖子一次执行和多次执行影响的效果是一样的呢。
这个具体只能是指定条件删除
POST 方法
HTTP POST 方法用于创建资源可以类比于提交信息显然一次和多次提交是有副作用执行效果是不一样的不满足幂等性。
比如POST http://www.tianluo.com/articles的语义是在http://www.tianluo.com/articles下创建一篇帖子HTTP 响应中应包含帖子的创建状态以及帖子的 URI。两次相同的POST请求会在服务器端创建两份资源它们具有不同的 URI所以POST方法不具备幂等性。
PUT 方法
在大多数情况下PUT 方法是幂等的因为它用于更新或替换指定资源的全部内容。无论执行多少次相同的 PUT 请求最终结果都应该是相同的。然而在某些特定的情况下PUT 方法可能会表现出非幂等的行为。以下是一些可能导致 PUT 方法不幂等的情况
在大多数情况下PUT 方法是幂等的因为它用于更新或替换指定资源的全部内容。无论执行多少次相同的 PUT 请求最终结果都应该是相同的。然而在某些特定的情况下PUT 方法可能会表现出非幂等的行为。以下是一些可能导致 PUT 方法不幂等的情况
依赖外部状态 如果 PUT 请求的结果依赖于外部状态或系统中的其他数据那么它可能不是幂等的。
示例 假设有一个计数器服务每次 PUT 请求都会增加一个计数器的值
PUT /counter
Content-Type: application/json{value: 1
}在这个例子中每次执行 PUT 请求都会将计数器的值增加 1。因此多次执行相同的请求会导致不同的结果这使得 PUT 不再是幂等的。
包含时间戳或版本号 如果 PUT 请求中包含时间戳或版本号并且这些信息会影响服务器的状态那么 PUT 可能不是幂等的。
示例 假设有一个资源其内容包括一个时间戳字段
PUT /resource/123
Content-Type: application/json{name: John Doe,timestamp: 2024-09-22T12:00:00Z
}每次 PUT 请求的时间戳不同即使内容相同服务器也可能将其视为不同的更新从而导致非幂等行为。
包含自增字段 如果 PUT 请求中包含自增字段如 ID 或序列号并且这些字段在服务器端生成那么 PUT 可能不是幂等的。
示例 假设有一个资源其中包含一个自增的 ID 字段
PUT /resource/123
Content-Type: application/json{name: John Doe,id: 123
}如果 id 是在服务器端生成的并且每次 PUT 请求都会生成一个新的 ID那么多次执行相同的 PUT 请求会导致不同的结果。
并发更新 在并发环境中多个客户端同时对同一个资源进行 PUT 操作时可能会导致非幂等的行为。
示例 假设有两个客户端同时尝试更新同一个资源
客户端 A 发送 PUT 请求更新资源为 { name: John Doe }。客户端 B 在客户端 A 的请求处理完成之前发送 PUT 请求更新资源为 { name: Jane Doe }。
在这种情况下最终资源的状态取决于哪个请求先被处理这可能导致非幂等的行为。
副作用 如果 PUT 请求有副作用例如触发其他操作或事件那么它可能不是幂等的。
示例 假设 PUT 请求不仅更新资源还触发了一个通知事件
PUT /resource/123
Content-Type: application/json{name: John Doe
}每次执行 PUT 请求时都会触发一个通知事件即使资源内容没有变化。这种情况下PUT 请求不再是幂等的。
虽然 PUT 方法在标准定义下是幂等的但在实际应用中由于上述情况的存在PUT 请求可能会表现出非幂等的行为。为了确保 PUT 方法的幂等性应该避免依赖外部状态、时间戳、自增字段和副作用并且在并发环境下使用适当的锁机制来防止竞态条件。通过这些措施可以确保 PUT 方法在分布式系统中的可靠性和一致性。
