网站开发的内容和特点,黄村网站建设,网站开发规划方案,温州做网络推广的公司转自#xff1a; https://blog.csdn.net/mingwulipo/article/details/91443355 1、接口调用存在的问题 现如今我们的系统大多拆分为分布式SOA#xff0c;或者微服务#xff0c;一套系统中包含了多个子系统服务#xff0c;而一个子系统服务往往会去调用另一个服务#x…转自 https://blog.csdn.net/mingwulipo/article/details/91443355 1、接口调用存在的问题 现如今我们的系统大多拆分为分布式SOA或者微服务一套系统中包含了多个子系统服务而一个子系统服务往往会去调用另一个服务而服务调用服务无非就是使用RPC通信或者restful既然是通信那么就有可能在服务器处理完毕后返回结果的时候挂掉这个时候用户端发现很久没有反应那么就会多次点击按钮这样请求有多次那么处理数据的结果是否要统一呢那是肯定的尤其在支付场景。
2、什么是接口幂等性
接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的不会因为多次点击而产生了副作用。举个最简单的例子那就是支付用户购买商品后支付支付扣款成功但是返回结果的时候网络异常此时钱已经扣了用户再次点击按钮此时会进行第二次扣款返回结果成功用户查询余额返发现多扣钱了流水记录也变成了两条,这就没有保证接口的幂等性
3、什么情况下需要保证接口的幂等性
在增删改查4个操作中尤为注意就是增加或者修改
A: 查询操作 查询对于结果是不会有改变的查询一次和查询多次在数据不变的情况下查询结果是一样的。select是天然的幂等操作 B: 删除操作
删除一次和多次删除都是把数据删除。(注意可能返回结果不一样删除的数据不存在返回0删除的数据多条返回结果多个,在不考虑返回结果的情况下,删除操作也是具有幂等性的)
C: 更新操作
修改在大多场景下结果一样,但是如果是增量修改是需要保证幂等性的,如下例子:
把表中id为XXX的记录的A字段值设置为1,这种操作不管执行多少次都是幂等的 把表中id为XXX的记录的A字段值增加1,这种操作就不是幂等的
D: 新增操作
增加在重复提交的场景下会出现幂等性问题,如以上的支付问题 4、那么如何设计接口才能做到幂等呢
常见的两种实现方案: 1. 通过代码逻辑判断实现 2. 使用token机制实现
下面以支付系统为例,分别对接口的幂等性进行说明与实现
A: 通过代码逻辑判断实现接口幂等性,只能针对一些满足判断的逻辑实现,具有一定局限性
用户购买商品的订单系统与支付系统订单系统负责记录用户的购买记录已经订单的流转状态orderStatus),支付系统用于付款提供如下接口订单系统与支付系统通过分布式网络交互。
boolean pay(int accountid,BigDecimal amount) //用于付款扣除用户的 这种情况下支付系统已经扣款但是订单系统因为网络原因没有获取到确切的结果因此订单系统需要重试。由上图可见支付系统并没有做到接口的幂等性订单系统第一次调用和第二次调用用户分别被扣了两次钱不符合幂等性原则同一个订单无论是调用了多少次用户都只会扣款一次。如果需要支持幂等性付款接口需要修改为以下接口
boolean pay(int orderId,int accountId,BigDecimal amount) 通过orderId来标定订单的唯一性付款系统只要检测到订单已经支付过则第二次调用不会扣款而会直接返回结果
在不同的业务中不同接口需要有不同的幂等性特别是在分布式系统中因为网络原因而未能得到确定的结果往往需要支持接口幂等性。 随着分布式系统及微服务的普及因为网络原因而导致调用系统未能获取到确切的结果从而导致重试这就需要被调用系统具有幂等性。
例如上文所阐述的支付系统针对同一个订单保证支付的幂等性一旦订单的支付状态确定之后以后的操作都会返回相同的结果对用户的扣款也只会有一次。这种接口的幂等性简化到数据层面的操作
update userAmount set amount amount - ‘value’ ,paystatus ‘paid’ where orderId ‘orderid’ and paystatus ‘unpay’
其中value是用户要减少的订单paystatus代表支付状态paid代表已经支付unpay代表未支付orderid是订单号。 在上文中提到的订单系统订单具有自己的状态orderStatus),订单状态存在一定的流转。订单首先有提交0付款中1付款成功2付款失败3简化之后其流转路径如图 当orderStatus 1 时其前置状态只能是0也就是说将orderStatus由0-1 是需要幂等性的 update Order set orderStatus 1 where OrderId ‘orderid’ and orderStatus 0 当orderStatus 处于01两种状态时对订单执行0-1 的状态流转操作应该是具有幂等性的。这时候需要在执行update操作之前检测orderStatus是否已经1如果已经1则直接返回true即可。 但是如果此时orderStatus 2,再进行订单状态0-1 时操作就无法成功但是幂等性是针对同一个请求的也就是针对同一个requestid保持幂等。这时候再执行 update Order set orderStatus 1 where OrderId ‘orderid’ and orderStatus 0 接口会返回失败系统没有产生修改如果再发一次requestid是相同的对系统同样没有产生修改。 B: 使用token机制实现接口幂等性,通用性强的实现方法 token机制实现步骤: 1. 生成全局唯一的token,token放到redis或jvm内存,token会在页面跳转时获取.存放到pageScope中,支付请求提交先获取token 2. 提交后后台校验token执行提交逻辑,提交成功同时删除token生成新的token更新redis ,这样当第一次提交后token更新了,页面再次提交携带的token是已删除的token后台验证会失败不让提交 token特点 要申请一次有效性可以限流 注意 redis要用删除操作来判断token删除成功代表token校验通过如果用selectdelete来校验token存在并发问题不建议使用。。
