精华内容
下载资源
问答
  • 看一下维基百科怎么幂等性:多次调用方法或者接口不会改变业务状态,可以保证重复调用结果和单次调用结果一致。二、使用幂等场景1、前端重复提交用户注册,用户创建商品等操作,前端都会提交一些数据给...

    8a36377c0fa349b7a54189380ee55f4a.png

    大家好,我是狂聊。

    自己最近负责的几个接口,都涉及到了幂等性的操作,抽空总结了一下,这也是面试官比较爱问的问题。

    一、什么是幂等?

    看一下维基百科怎么说的:

    9344031409ec1d0d4a2f837ca55c5300.png

    幂等性:多次调用方法或者接口不会改变业务状态,可以保证重复调用的结果和单次调用的结果一致。

    二、使用幂等的场景

    1、前端重复提交

    用户注册,用户创建商品等操作,前端都会提交一些数据给后台服务,后台需要根据用户提交的数据在数据库中创建记录。如果用户不小心多点了几次,后端收到了好几次提交,这时就会在数据库中重复创建了多条记录。这就是接口没有幂等性带来的 bug。

    2、接口超时重试

    对于给第三方调用的接口,有可能会因为网络原因而调用失败,这时,一般在设计的时候会对接口调用加上失败重试的机制。如果第一次调用已经执行了一半时,发生了网络异常。这时再次调用时就会因为脏数据的存在而出现调用异常。

    3、消息重复消费

    在使用消息中间件来处理消息队列,且手动 ack 确认消息被正常消费时。如果消费者突然断开连接,那么已经执行了一半的消息会重新放回队列。

    当消息被其他消费者重新消费时,如果没有幂等性,就会导致消息重复消费时结果异常,如数据库重复数据,数据库数据冲突,资源重复等。

    三、解决方案

    1、token 机制实现

    通过token 机制实现接口的幂等性,这是一种比较通用性的实现方法。

    示意图如下:

    8ac8c0db4d60f4e8e9bd7aae375b2faa.png

    具体流程步骤:

    客户端会先发送一个请求去获取 token,服务端会生成一个全局唯一的 ID 作为 token 保存在 redis 中,同时把这个 ID 返回给客户端

    客户端第二次调用业务请求的时候必须携带这个 token

    服务端会校验这个 token,如果校验成功,则执行业务,并删除 redis 中的 token

    如果校验失败,说明 redis 中已经没有对应的 token,则表示重复操作,直接返回指定的结果给客户端

    注意:

    对 redis 中是否存在 token 以及删除的代码逻辑建议用 Lua 脚本实现,保证原子性

    全局唯一 ID 可以用百度的 uid-generator、美团的 Leaf 去生成

    2、基于 MySQL 实现

    这种实现方式是利用 mysql 唯一索引的特性。

    示意图如下:

    dacd1ee71833dc4826a67a6bcb9ed6ad.png

    具体流程步骤:

    建立一张去重表,其中某个字段需要建立唯一索引

    客户端去请求服务端,服务端会将这次请求的一些信息插入这张去重表中

    因为表中某个字段带有唯一索引,如果插入成功,证明表中没有这次请求的信息,则执行后续的业务逻辑

    如果插入失败,则代表已经执行过当前请求,直接返回

    3、基于 Redis 实现

    这种实现方式是基于 SETNX 命令实现的

    SETNX key value:将 key 的值设为 value ,当且仅当 key 不存在。若给定的 key 已经存在,则 SETNX 不做任何动作。

    该命令在设置成功时返回 1,设置失败时返回 0。

    示意图如下:

    b5af2434baef18006038bb91f97288a9.png

    具体流程步骤:

    客户端先请求服务端,会拿到一个能代表这次请求业务的唯一字段

    将该字段以 SETNX 的方式存入 redis 中,并根据业务设置相应的超时时间

    如果设置成功,证明这是第一次请求,则执行后续的业务逻辑

    如果设置失败,则代表已经执行过当前请求,直接返回

    总结

    这几种实现幂等的方式其实都是大同小异的,类似的还有使用状态机、悲观锁、乐观锁的方式来实现,都是比较简单的。

    总之,当你去设计一个接口的时候,幂等都是首要考虑的问题,特别是当你负责设计转账、支付这种涉及到 money 的接口,你要格外注意喽!

    【编辑推荐】

    【责任编辑:姜华 TEL:(010)68476606】

    点赞 0

    展开全文
  • 幂等意味着,对于同一个交易多次处理,结果不变。怎么讲呢?假如客户账户Account1现在有100元,执行一次交易(Order01)扣款10元,现在有就变成了90元,在分布式情况下,假如网络超时失败之类情况下,就会导致可能...

    幂等意味着,对于同一个交易的多次处理,结果不变。怎么讲呢?

    假如客户账户Account1现在有100元,执行一次交易(Order01)扣款10元,现在有就变成了90元,在分布式情况下,假如网络超时失败之类的情况下,就会导致可能客户端拿到了TimeoutException,但是实际上Server端执行成功了,这时客户端可能会发起重试,或者用MQ处理的话,MQ会重试。如果再执行一次就扣款10元,就变成了80元,显然这是不对的。况且如果重试操作发生了多次,余额被扣成了负数,客户会疯掉。理想的状态就是,多次的重复处理,结果应该不变,还是90元。假设处理订单的服务方法是f,那么就是:Step1:f(100, Order01) => 90

    Step2:f(90, Order01) => 90

    Step3:f(90, Order01) => 90

    方法f怎么实现呢?伪代码:

    function f(Account, Order){

    Account = Account - Order.amount;

    // update user_account set account = account - orderAmount where userid = xxx;

    // 90 = 100 - 10;

    }

    这段代码实现很简单,就是直接把账户减掉订单金额。这个逻辑明显有问题,在上面的Step2步骤的时候,会导致结果是80,而不是我们期望的不变,还是90元。

    一个改进办法就是我们可以参考乐观锁:每次先拿到当前的某个版本号标志或者价格,然后修改的时候把这个标识作为条件,就可以在余额已经变化的情况下,不操作了(核心原理就是通过某个条件,判断记录是不是已经变化了):

    currentAccount = Account;// 100

    function f(currentAccount, Account, Order){

    Account = if(Account == currentAccount) Account - Order.amount;

    // update user_account set account = account - orderAmount

    // where userid = xxx and account = currentAccount; // 100

    // if(account = 90, currentAccount = 100, 那么这个扣减的操作就不执行,金额不变,实现幂等)

    }

    这样,只要在一个事务操作里,多次操作是没有关系的,发现金额变了,就不会再变了。多加的幂等判断条件是时间戳,版本号字段,等等都可以,只要是能代表字段被修改过就成。

    上面的处理,还有什么问题吗?答案是,如果在上一个订单处理了一段时间以后又有别的订单处理or并发处理,或者是原有订单数据被人工的修订过,那么可能幂等条件被破坏掉了。

    继续用上面的例子,假如订单Order01成功以后,订单Order02这时候增加了10元,那么账户又变成100元,这时候要是Order01再来一次,显然要是按照上面说的按100元的条件对比,还是会执行。Step1:f(100, Order01) => 90

    Step2:f(90, Order01) => 90

    Step3:f(90, Order02) => 100 // 隔了一段时间做了这个操作

    Step4:f(100, Order01) => 90 //这里就不对了,应该不变

    怎么办呢?

    一个简单的办法就是,把成功执行过的订单id都记录下来,或者把订单处理的事务里,给订单记上一个成功状态,这个订单状态的操作一定要和账户操作在一个同步的事务里。每次操作的时候用这个状态作为条件,相当于一个悲观锁,就不会重复了。

    那么有没有跟简单的办法呢?如果我们假设订单不多,或者可能会重复的数据集中在一定时间范围内,那么可以用内存的办法去重,更简单高效:

    例如,我们把新进操作成功的OrderID都直接丢到RoaringBitmap里,假如一天以内的数据是热数据有10-20万,这10-20万个都放到这种压缩的bitmap问题不大,占用内存很小(2-10M),使用也简单,直接检查是不是某个id就可,如果存在就不做任何操作。完全不碰数据库,所以没有io操作,内存的检查操作代价在微秒级。系统每次重启初始化的时候,可以把上一批天的id预先拉出来加载到内存即可。如果获取一天以上的数据,可以先从DB加载,然后放到bitmap,同时可以考虑一下,系统的业务处理流程是不是有问题,或者处了故障,才会导致1天以上数据重复处理,从设计的源头解决问题。。。

    可以看到,这种设计比前面的方式复杂的多,但是如果在你的场景里可用,也比其他方法高效的多。高效的方法,往往跟上下文,具体的场景有关系,需要深刻分析问题来探索。

    总结一下:幂等就是让多次重复操作的结果跟一次操作的结果是一样的。

    可以采用的办法:乐观锁,加上操作时的状态判断,如果状态变了就不操作;

    悲观锁,每次操作的时候锁住资源,使用一个显式的状态去表示操作状态;

    使用RoaringBitmap做一定时间范围的热数据内的操作记录做内存bitmap去重,从而实现幂等,我们线上的每日几亿订单的交易订单处理,处理环节大部分用到了MQ,为了防止MQ消费数据重复(MQ本身重复、下游系统启动拉取重复、失败重试带来的重复、补偿逻辑导致的重复),都默认封装了使用RoaringBitmap来去重的机制,非常还用,谁用谁知道。

    附RoaringBitmap的github地址:RoaringBitmap/RoaringBitmap​github.com

    展开全文
  • 还不知道怎么实现分布式服务接口的幂等性?

    千次阅读 多人点赞 2020-03-20 10:06:20
    2.1 怎么判断请求是否重复2.2 最佳实践3 攻克ABA3.1 什么是 ABA?3.2 解决方案通用解决方案4 总结参考 0 前言 全是干货技术殿堂 文章收录在我 GitHub 仓库,欢迎Star/fork: Java-Interview-Tutorial ...

    文章收录在我的 GitHub 仓库,欢迎Star/fork:
    Java-Interview-Tutorial
    https://github.com/Wasabi1234/Java-Interview-Tutorial

    1 问题背景

    可能你最先想到的就是使用数据库的事务保证。比如创建订单时,要同时往订单表和订单商品表中插入数据,那这些插入数据的INSERT必须在一个数据库事务中执行,数据库的事务可以确保:执行这些INSERT语句,共赴生死!

    假如你有个服务部署在5台机器上,有个付款接口。然后用户在前端操作时,一份订单不小心发起了两次支付请求,然后这俩请求分散在了这个服务部署的不同的机器上,结果一个订单扣款扣两次,gg!

    订单系统调用支付系统进行支付,结果不小心网络超时,然后订单系统走了前面我们看到的那个重试机制,给你重试了一把,好,支付系统收到一个支付请求两次,而且因为负载均衡算法落在了不同的机器了!
    但这还是有很多大坑存在。一个分布式系统中的某个接口,要保证幂等性,如何保证?

    2 如何避免重复下单?

    评论里有同学说,前端页面直接防止用户重复提交表单。没啥毛病,但网络错误会导致重传,很多RPC框架、网关都有自动重试机制,所以重复请求无法避免。
    所以问题归结于如何保证服务接口的幂等性。

    2.1 怎么判断请求是否重复

    1. 插入订单数据前,先查一下订单表里面有没有重复订单?
      这可不好啊,因为你很难用SQL的条件来定义“重复的订单”
    2. 订单用户一样、商品一样、价格一样,就是重复订单?
      万一这搞笑用户就是连续下了俩一模一样订单呢

    2.2 最佳实践

    保证幂等性主要有如下几点

    每个请求须有唯一标识

    比如订单支付请求,得包含订单id,一个订单id最多支付一次

    每次处理完请求后,须有记录标识该请求已被处理

    比如说常见的方案是在MySQL中记录一个状态字段。比如支付之前记录一条这个订单的支付流水

    每次接收请求判断之前是否处理过

    若有一个订单已支付,就已经有了一条支付流水,那么如果重复发送这个请求,则此时先插入支付流水,orderId已存在,唯一键约束生效,报错插入不进去。就不会再重复扣款。

    在往db插条记录时,一般不提供主键,而由数据库在插入时自动生成一个主键。这样重复的请求就会导致插入重复数据。

    MySQL的主键自带唯一性约束,若在一条INSERT语句提供主键,且该主键值在表中已存在,则该条INSERT会执行失败。因此可利用db的“主键唯一约束”,在插数据时带上主键,以此实现创建订单接口的幂等性。

    给订单服务添加一个“orderId生成”的接口,无参,返回值就是一个全局唯一订单号。在用户进入创建订单页面时,前端页面先调用该orderId生成接口得到一个订单号,在用户提交订单的时候,在创建订单的请求中携带该订单号。

    该订单号其实就是订单表的主键,如此一来,重复请求中带的都是同一订单号。订单服务在订单表中插入数据的时候,执行的这些重复INSERT语句中的主键,也都是同一个订单号。而数据库的唯一约束可保证,只有一次INSERT执行成功。

    实际要结合业务,比如使用Redis,用orderId作为唯一键。只有成功插入这个支付流水,才可执行扣款。

    要求是支付一个订单,必须插入一条支付流水,order_id建立一个唯一键unique key
    你在支付一个订单前,先插入一条支付流水,order_id就已经传过去了
    你就可以写一个标识到Redis中,set order_id payed,当重复请求过来时,先查Redis的order_id对应的value,若为payed说明已支付,就别重复支付了!

    然后再重复支付订单时,写尝试插入一条支付流水,db会报错unique key冲突,整个事务回滚即可。
    保存一个是否处理过的标识也可以,服务的不同实例可以一起操作Redis。

    • 幂等创建订单的时序图

    如果因为重复订单导致插入订单表失败,订单服务不要把这个错误返回给前端页面.
    否则,就可能出现用户点击创建订单按钮后,页面提示创建订单失败,而实际上订单却创建成功了.
    正确的做法是,遇到这种情况,订单服务直接返回订单创建成功即可.

    3 怎么解决ABA问题?

    3.1 什么是 ABA?

    比如订单支付后,卖家要发货,发货完成后要填个快递单号。假设说,卖家填了个666,刚填完,发现填错了,赶紧再修改成888。对订单服务来说,这就是2个更新订单的请求。系统异常时666请求到了,单号更成666,接着888请求到了,单号又更新成888,但是666更新成功的响应丢了,调用方没收到成功响应,自动重试,再次发起666请求,单号又被更新成666了,这数据显然就错了.

    • 时序图

    3.2 解决方案

    通用的解决方案

    订单主表增加一列version。每次查询订单的时候,版本号要随着订单数据返回给页面。
    页面在更新数据的请求中,把这个版本号作为更新请求的参数,带回给订单更新接口。

    订单服务在更新数据的时候,需要比较订单的版本号是否和消息中的一致:

    • 不一致 拒绝更新数据
    • 一致 还需要再更新数据的同时,把版本号+1。“比较版本号、更新数据和版本号+1”,这个过程必须在同一个事务里面执行。
    UPDATE orders set tracking_number = 666, version = version + 1
    	WHERE version = 8;
    

    在这条SQL的WHERE条件中,version的值需要页面在更新的时候通过请求传进来。

    通过这个版本号,就可以保证,从我打开这条订单记录开始,一直到我更新这条订单记录成功,这个期间没有其他人修改过这条订单数据。因为,如果有其他人修改过,数据库中的版本号就会改变,那我的更新操作就不会执行成功。我只能重新查询新版本的订单数据,然后再尝试更新。

    有了这个版本号,前文的ABA即有两个 case

    • 把运单号更新为666的操作成功了,更新为888的请求带着旧版本号,那就会更新失败,页面提示用户更新888失败
    • 第二种情况,666更新成功后,888带着新的版本号,888更新成功。这时候即使重试的666请求再来,因为它和上一条666请求带着相同的版本号,上一条请求更新成功后,这个版本号已经变了,所以重试请求的更新必然失败

    无论哪种情况,数据库中的数据与页面上给用户的反馈都是一致的。这样就可以实现幂等更新并且避免了ABA问题

    • 下图展示case1

    4 总结

    • 对于创建订单服务来说,可以通过预先生成订单号,然后利用数据库中订单号的唯一约束这个特性,避免重复写入订单,实现创建订单服务的幂等性
    • 对于更新订单服务,可以通过一个版本号机制,每次更新数据前校验版本号,更新数据同时自增版本号,这样的方式,来解决ABA问题,确保更新订单服务的幂等性。

    两种幂等的实现方法,就可以保证,无论请求是不是重复,订单表中的数据都是正确的。

    实现订单幂等的方法,完全可以套用在其他需要实现幂等的服务中,只需要这个服务操作的数据保存在数据库中,并且有一张带有主键的数据表即可

    参考

    • 后端存储实战
    展开全文
  • 怎么接口幂等性操作?

    千次阅读 2019-06-21 15:04:02
    一、幂等性概念 在编程中.一个幂等操作特点是其任意多次执行所产生影响均与一次执行影响相同。幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果函数。这些函数不会影响系统状态,也...

    一、幂等性概念

    在编程中.一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果的函数。这些函数不会影响系统状态,也不用担心重复执行会对系统造成改变。例如,“getUsername()和setTrue()”函数就是一个幂等函数. 更复杂的操作幂等保证是利用唯一交易号(流水号)实现.

    我的理解:幂等就是一个操作,不论执行多少次,产生的效果和返回的结果都是一样的。

    二、幂等性场景

    1、查询操作:查询一次和查询多次,在数据不变的情况下,查询结果是一样的。select是天然的幂等操作;

    2、删除操作:删除操作也是幂等的,删除一次和多次删除都是把数据删除。(注意可能返回结果不一样,删除的数据不存在,返回0,删除的数据多条,返回结果多个) ;

    3、唯一索引:防止新增脏数据。比如:支付宝的资金账户,支付宝也有用户账户,每个用户只能有一个资金账户,怎么防止给用户创建资金账户多个,那么给资金账户表中的用户ID加唯一索引,所以一个用户新增成功一个资金账户记录。要点:唯一索引或唯一组合索引来防止新增数据存在脏数据(当表存在唯一索引,并发时新增报错时,再查询一次就可以了,数据应该已经存在了,返回结果即可);

    4、token机制:防止页面重复提交。

    原理上通过session token来实现的(也可以通过redis来实现)。当客户端请求页面时,服务器会生成一个随机数Token,并且将Token放置到session当中,然后将Token发给客户端(一般通过构造hidden表单)。

    下次客户端提交请求时,Token会随着表单一起提交到服务器端。

    服务器端第一次验证相同过后,会将session中的Token值更新下,若用户重复提交,第二次的验证判断将失败,因为用户提交的表单中的Token没变,但服务器端session中Token已经改变了。

    5、悲观锁

    获取数据的时候加锁获取。select * from table_xxx where id='xxx' for update; 注意:id字段一定是主键或者唯一索引,不然是锁表,会死人的;悲观锁使用时一般伴随事务一起使用,数据锁定时间可能会很长,根据实际情况选用;

    6、乐观锁——乐观锁只是在更新数据那一刻锁表,其他时间不锁表,所以相对于悲观锁,效率更高。乐观锁的实现方式多种多样可以通过version或者其他状态条件:

    1. 通过版本号实现update table_xxx set name=#name#,version=version+1 where version=#version#如下图(来自网上);

    2. 通过条件限制 update table_xxx set avai_amount=avai_amount-#subAmount# where avai_amount-#subAmount# >= 0要求:quality-#subQuality# >= ,这个情景适合不用版本号,只更新是做数据安全校验,适合库存模型,扣份额和回滚份额,性能更高;

    7、分布式锁

    如果是分布是系统,构建全局唯一索引比较困难,例如唯一性的字段没法确定,这时候可以引入分布式锁,通过第三方的系统(redis或zookeeper),在业务系统插入数据或者更新数据,获取分布式锁,然后做操作,之后释放锁,这样其实是把多线程并发的锁的思路,引入多多个系统,也就是分布式系统中得解决思路。要点:某个长流程处理过程要求不能并发执行,可以在流程执行之前根据某个标志(用户ID+后缀等)获取分布式锁,其他流程执行时获取锁就会失败,也就是同一时间该流程只能有一个能执行成功,执行完成后,释放分布式锁(分布式锁要第三方系统提供);

    8、select + insert

    并发不高的后台系统,或者一些任务JOB,为了支持幂等,支持重复执行,简单的处理方法是,先查询下一些关键数据,判断是否已经执行过,在进行业务处理,就可以了。注意:核心高并发流程不要用这种方法;

    9、状态机幂等

    在设计单据相关的业务,或者是任务相关的业务,肯定会涉及到状态机(状态变更图),就是业务单据上面有个状态,状态在不同的情况下会发生变更,一般情况下存在有限状态机,这时候,如果状态机已经处于下一个状态,这时候来了一个上一个状态的变更,理论上是不能够变更的,这样的话,保证了有限状态机的幂等。注意:订单等单据类业务,存在很长的状态流转,一定要深刻理解状态机,对业务系统设计能力提高有很大帮助

    10、对外提供接口的api如何保证幂等

    如银联提供的付款接口:需要接入商户提交付款请求时附带:source来源,seq序列号;source+seq在数据库里面做唯一索引,防止多次付款(并发时,只能处理一个请求) 。

    重点:对外提供接口为了支持幂等调用,接口有两个字段必须传,一个是来源source,一个是来源方序列号seq,这个两个字段在提供方系统里面做联合唯一索引,这样当第三方调用时,先在本方系统里面查询一下,是否已经处理过,返回相应处理结果;没有处理过,进行相应处理,返回结果。注意,为了幂等友好,一定要先查询一下,是否处理过该笔业务,不查询直接插入业务系统,会报错,但实际已经处理了。

    三、总结

    幂等与你是不是分布式高并发还有JavaEE都没有关系。关键是你的操作是不是幂等的。一个幂等的操作典型如:把编号为5的记录的A字段设置为0这种操作不管执行多少次都是幂等的。一个非幂等的操作典型如:把编号为5的记录的A字段增加1这种操作显然就不是幂等的。要做到幂等性,从接口设计上来说不设计任何非幂等的操作即可。譬如说需求是:当用户点击赞同时,将答案的赞同数量+1。改为:当用户点击赞同时,确保答案赞同表中存在一条记录,用户、答案。赞同数量由答案赞同表统计出来。总之幂等性应该是合格程序员的一个基因,在设计系统时,是首要考虑的问题,尤其是在像支付宝,银行,互联网金融公司等涉及的都是钱的系统,既要高效,数据也要准确,所以不能出现多扣款,多打款等问题,这样会很难处理,用户体验也不好。

    原文:https://www.cnblogs.com/linjiqin/p/9678022.html

    展开全文
  • 幂等性设计我们以对接支付宝充值为例,来分析支付回调接口如何设计?如果我们系统中对接过支付宝充值功能,我们需要给支付宝提供一个回调接口,支付宝回调信息中会携带(out_trade_no【商户订单号】,trade_no...
  • 1、分布式/微服务系统接口的幂等性如何设计?比如不能重复扣款;2、消息中间件如何解决消息的幂等性?消息怎么防止不被重复消费;幂等这个词本身源自数学,幂等性是数学中的一个概念,常见于抽象代数中,表达的是N次...
  • 什么是幂等性? 对于同一笔业务操作,不管调用多少次,得到结果都是一样幂等性设计 我们以对接支付宝充值为例,来分析支付回调接口如何设计? 如果我们系统中对接过支付宝充值功能,我们需要给支付宝提供一...
  • select是天然的幂等操作。 2. 删除操作删除操作也是幂等的,删除一次和多次删除都是把数据删除。(注意可能返回结果不一样,删除的数据不存在,返回0,删除的数据多条,返回结果多个) 3.唯一索引,防止新增脏数据...
  • 一个幂等操作特点是其任意多次执行所产生影响均与一次执行影响相同。幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果函数。 这些函数不会影响系统状态,也不用担心重复执行会对系统...
  • 一、幂等性概念 在编程中.一个幂等操作特点是其任意多次执行所产生影响均与一次执行影响相同。幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果函数。这些函数不会影响系统状态,也...
  • 接口幂等性这么重要,它是什么?怎么实现? 原创路人甲Java路人甲Java2019-09-20 什么是幂等性? 对于同一笔业务操作,不管调用多少次,得到结果都是一样幂等性设计 我们以对接支付宝充值为例,来分析...
  • 什么是幂等性 幂等性:就是用户对于同一操作...又可能用户不知道怎么得对一个订单发起了两次支付请求,但是这两个请求被负载均衡落在不同机器上,如果没有做分布式幂等性,那么也会扣款两次。 如何实现幂等性 实现
  • 什么是幂等性? 对于同一笔业务操作,不管调用多少次,得到结果都是一样幂等性设计 我们以对接支付宝充值为例,来分析支付回调接口如何设计? 如果我们系统中对接过支付宝充值功能,我们需要给支付宝...
  • 什么是幂等性? 对于同一笔业务操作,不管调用多少次,得到结果都是一样幂等性设计 我们以对接支付宝充值为例,来分析支付回调接口如何设计? 如果我们系统中对接过支付宝充值功能,我们需要给支付宝...
  • 作者:抽离心 链接:https://blog.csdn.net/u011635492/article/details/81058153 实际系统中有很多操作,是不管做多少次,都应该产生一样效果或返回一样结果。例如: 前端重复提交选中数据,应该...
  • 程序员成长之路互联网/程序员/成长/职场关注阅读本文大概需要 5 分钟。作者:抽离心来源:https://urlify.cn/NjEB3q实际系统中有很多操作,是不管做多少次,都应...
  • 幂等性设计我们以对接支付宝充值为例,来分析支付回调接口如何设计?如果我们系统中对接过支付宝充值功能,我们需要给支付宝提供一个回调接口,支付宝回调信息中会携带(out_trade_no【商户订单号】,trade_no...
  • 前段时间,我修改一个功能涉及的接口,经过测试小姐姐仔细盘查,出BUG了...而且是很严重BUG。 可以看到同样数据产生两条了,如果不注意,两条都审核通过...那就是白花花银子,会被祭天! 我一寻思...
  • 怎么理解幂等性[或者http幂等性]

    千次阅读 2018-01-10 22:17:41
    幂等性是系统的接口对外一种承诺(而不是实现), 承诺只要调用接口成功, 外部多次调用对系统影响是一致 . 声明为幂等的接口会认为外部调用失败是常态, 并且 失败之后必然会有重试. 声明为幂等性的API...
  • 之前接到过一个阿里电话面试,他问我知不知道幂等性怎么实现幂等,关于幂等我有过一点儿印象,不过当时突然一个电话过来问起我了,我还是有点儿懵懵,为了加深对次理解,我特意找了相关资料。...
  • 点击上方蓝色字体,选择...太烦人了SpringBoot+RabbitMQ (保证消息100%投递成功并被消费)工作流一目了然,看小姐姐用动图展示 10 大 Git 命令史上最便捷搭建RocketMQ服务器方法IDEA新特性:提前知道代码怎么走!在...
  • 面试官问了你一堆 dubbo 是怎么玩儿,你会玩儿 dubbo 就可以把单块系统弄成分布式系统,然后分布式之后接踵而来就是一堆问题,最大问题就是分布式事务、接口幂等性、分布式锁,还有最后一个就是分布式 session...
  • 幂等性

    2020-02-22 16:09:05
    幂等性在我们实际开发中是比较常见,例如转账提现、订单发货系统等。今天,我们就分这两种场景对幂等性进行讨论: 1.转账提现 假如让我们实现支付宝和银行转账提现需求,你会怎么做呢? 首先我们看一下示意...
  • 幂等性问题

    2020-06-15 00:17:18
    原因是接口幂等性问题没有处理,导致损失... 幂等性问题是从事多方面尤其涉及金融产品开发人员必备知识和必须考虑问题(此外还有金融数据加减乘除和比较问题,BigDecimal使用),幂等性那么重要,它是...
  • 在最近一次业务升级中,遇到这样一个问题,我们设计了新账户体系,需要在用户将应用...就算我们在客户端做了一些处理,在同步过程中,不能再次点击,但是经过我最近爬虫实践,要是别人抓到了我们的接口那...
  • 关于怎么实现承载更多用户量系统,一直是我重点关注一个技术方向。...在分布式系统学习途中也不断见识新知识点,今天要说就是软件开发时候对于接口服务幂等性”实现! 幂等性 效果:系统对

空空如也

空空如也

1 2 3 4 5
收藏数 81
精华内容 32
关键字:

怎么实现接口的幂等性