精华内容
下载资源
问答
  • 修改幂等
    2022-03-25 15:26:58

    幂等性名词解释

    什么是幂等呢?一个幂等操作的特点是,1次和任意N次执行所产生的影响均与一次执行的影响相同。

    理论上讲,正常的接口都是具有幂等性的,但所有的问题都发生在网络抖动和异常的情况下。

    比如:一条新增的请求被反复执行?或者是多个请求同时修改一条的数据?比如刚刚好是fullGC,是这样了…你怎么解决?

    在这里插入图片描述

    定位问题

    这个接口是接收离线消息服务的接口,验证了用户身份,产生情况可能的原因:

    • 系统或者框架不稳定,造成的重试
    • 代码写的有问题,循环中有重试的情况
    • 正好赶上内存溢出,服务崩溃,Tcp进行的重试

    解决问题

    ++解决新增数据的幂等性如下:++

    可以利用数据库的这种“主键唯一约束”特性,在插入数据的时候带上主键,来解决创建订单服务的幂等性问题。

    我们给订单系统增加一个“生成订单号”的服务,这个服务没有参数,返回值就是一个新的、全局唯一的订单号。在用户进入创建订单的页面时,前端页面先调用这个生成订单号服务得到一个订单号,在用户提交订单的时候,在创建订单的请求中带着这个订单号。

    ++解决更新数据的幂等性(ABA问题)如下:++

    ABA 问题怎么解决?这里给你提供一个比较通用的解决方法。给你的订单主表增加一列,列名可以叫 version,也即是“版本号”的意思。每次查询订单的时候,版本号需要随着订单数据返回给页面。页面在更新数据的请求中,需要把这个版本号作为更新请求的参数,再带回给订单更新服务。

    订单服务在更新数据的时候,需要比较订单当前数据的版本号,是否和消息中的版本号一致,如果不一致就拒绝更新数据。如果版本号一致,还需要再更新数据的同时,把版本号 +1。“比较版本号、更新数据和版本号 +1”,这个过程必须在同一个事务里面执行。

    具体Sql可以这样写:

    UPDATE orders set tracking_number = 666, version = version + 1
    WHERE version = 8;
    

    你想到了什么好办法?

    更多相关内容
  • 微服务与幂等性 随着应用架构由单体架构到微服务架构进行演变,现如今市面上超过50%的应用都会基于分布式或微服务完成系统架构设计。在微服务架构体系内,就会存在若干个微服务,这些服务可能基于RPC或者HTTPS等协议...

    微服务与幂等性

    随着应用架构由单体架构到微服务架构进行演变,现如今市面上超过50%的应用都会基于分布式或微服务完成系统架构设计。在微服务架构体系内,就会存在若干个微服务,这些服务可能基于RPC或者HTTPS等协议进行通讯。那么既然服务之间存在相互调用,那么必然存在服务调用延迟或者失败的情况,当出现这种问题,服务端会进行重试等操作或客户端有可能会进行多次点击提交。如果这样请求多次的话,那最终处理的数据结果就一定要保证统一,如支付场景。此时就需要通过保证业务幂等性方案来完成。

    幂等性简介

    幂等本身是一个数学概念。即 f(n) = 1^n ,无论n为多少,f(n)的值永远为1。在编程开发中,对于幂等的定义为:无论对某一个资源操作了多少次,其影响都应是相同的。 换句话说就是:在接口重复调用的情况下,对系统产生的影响是一样的,但是返回值允许不同,如查询。
    幂等性包括数据幂等、接口幂等、服务幂等、消息幂等。

    以SQL为例:

    • select * from table where id=1。此SQL无论执行多少次,虽然结果有可能出现不同,都不会对数据产生 改变,具备幂等性。
    • insert into table(id,name) values(1,'小莫') 。此SQL如果id或name有唯一性约束,多次操作只允许插 入一条记录,则具备幂等性。如果不是,则不具备幂等性,多次操作会产生多条数据。
    • update table set score=100 where id = 1 。此SQL无论执行多少次,对数据产生的影响都是相同的。具备幂等性。
    • update table set score=50+score where id = 1 。此SQL涉及到了计算,每次操作对数据都会产生影响。 不具备幂等性。
    • delete from table where id = 1 。此SQL多次操作,产生的结果相同,具备幂等性。
      幂等性设计主要从两个维度进行考虑:空间、时间。
    • 空间:定义了幂等的范围,如生成订单的话,不允许出现重复下单。
    • 时间:定义幂等的有效期。有些业务需要永久性保证幂等,如下单、支付等。而部分业务只要保证一段时间幂等即可。
      同时对于幂等的使用一般都会伴随着出现锁的概念,用于解决并发安全问题。

    业务与幂等性

    在业务开发与分布式系统设计中,幂等性是一个非常重要的概念,有非常多的场景需要考虑幂等性的问题,尤其对于现在的分布式系统,经常性的考虑重试、重发等操作,一旦产生这些操作,则必须要考虑幂等性问题。以交易系统、支付系统等尤其明显,如:

    • 当用户购物进行下单操作,用户操作多次,但订单系统对于本次操作只能产生一个订单。
    • 当用户对订单进行付款,支付系统不管出现什么问题,应该只对用户扣一次款。
    • 当支付成功对库存扣减时,库存系统对订单中商品的库存数量也只能扣减一次。
    • 当对商品进行发货时,也需保证物流系统有且只能发一次货。
      在电商系统中还有非常多的场景需要保证幂等性。但是一旦考虑幂等后,服务逻辑务必会变的更加复杂。因此是否要考虑幂等,需要根据具体业务场景具体分析。而且在实现幂等时,还会把并行执行的功能改为串行化,降低了执行效率。
      此处以下单减库存为例,当用户生成订单成功后,会对订单中商品进行扣减库存。 订单服务会调用库存服务 进行库存扣减。库存服务会完成具体扣减实现。
      现在对于功能调用的设计,有可能出现调用超时,因为出现如网络抖动,虽然库存服务执行成功了,但结果并没有在超时时间内返回,则订单服务也会进行重试。那就会出现问题,stock对于之前的执行已经成功了, 只是结果没有按时返回。而订单服务又重新发起请求对商品进行库存扣减。 此时出现库存扣减两次的问题。 对于这种问题,就需要通过幂等性进行结果。

    接口幂等

    对于幂等的考虑,主要解决两点前后端交互与服务间交互。这两点有时都要考虑幂等性的实现。从前端的思路解决 的话,主要有三种:前端防重、PRG模式、Token机制。

    前端防重

    通过前端防重保证幂等是最简单的实现方式,前端相关属性和JS代码即可完成设置。可靠性并不好,有经验的人员 可以通过工具跳过页面仍能重复提交。主要适用于表单重复提交或按钮重复点击。

    PRG模式

    PRG模式即POST-REDIRECT-GET。当用户进行表单提交时,会重定向到另外一个提交成功页面,而不是停留在原先的表单页面。这样就避免了用户刷新导致重复提交。同时防止了通过浏览器按钮前进/后退导致表单重复提交。 是一种比较常见的前端防重策略。

    Token机制

    方案介绍

    通过token机制来保证幂等是一种非常常见的解决方案,同时也适合绝大部分场景。该方案需要前后端进行一定程 度的交互来完成。

    1)服务端提供获取token接口,供客户端进行使用。服务端生成token后,如果当前为分布式架构,将token存放 于redis中,如果是单体架构,可以保存在jvm缓存中。
    2)当客户端获取到token后,会携带着token发起请求。
    3)服务端接收到客户端请求后,首先会判断该token在redis中是否存在。如果存在,则完成进行业务处理,业务 处理完成后,再删除token。如果不存在,代表当前请求是重复请求,直接向客户端返回对应标识。
    但是现在有一个问题,当前是先执行业务再删除token。在高并发下,很有可能出现第一次访问时token存在,完 成具体业务操作。但在还没有删除token时,客户端又携带token发起请求,此时,因为token还存在,第二次请求 也会验证通过,执行具体业务操作。
    对于这个问题的解决方案的思想就是并行变串行。会造成一定性能损耗与吞吐量降低。
    第一种方案:对于业务代码执行和删除token整体加线程锁。当后续线程再来访问时,则阻塞排队。
    第二种方案:借助redis单线程和incr是原子性的特点。当第一次获取token时,以token作为key,对其进行自增。 然后将token进行返回,当客户端携带token访问执行业务代码时,对于判断token是否存在不用删除,而是对其继续incr。如果incr后的返回值为2。则是一个合法请求允许执行,如果是其他值,则代表是非法请求,直接返回。

    那如果先删除token再执行业务呢?其实也会存在问题,假设具体业务代码执行超时或失败,没有向客户端返回明确结果,那客户端就很有可能会进行重试,但此时之前的token已经被删除了,则会被认为是重复请求,不再进行业务处理。

    这种方案无需进行额外处理,一个token只能代表一次请求。一旦业务执行出现异常,则让客户端重新获取令牌, 重新发起一次访问即可。推荐使用先删除token方案
    但是无论先删token还是后删token,都会有一个相同的问题。每次业务请求都回产生一个额外的请求去获取 token。但是,业务失败或超时,在生产环境下,一万个里最多也就十个左右会失败,那为了这十来个请求,让其他九千九百多个请求都产生额外请求,就有一些得不偿失了。虽然redis性能好,但是这也是一种资源的浪费。

    实现

    基于自定义业务流程实现


    这种实现方式省略,与传统实现无异。

    基于自定义注解实现

    直接把token实现嵌入到方法中会造成大量重复代码的出现。因此可以通过自定义注解将上述代码进行改造。在需 要保证幂等的方法上,添加自定义注解即可。

    1. 在token_common中新建自定义注解Idemptent
    public class IdemptentInterceptor implements HandlerInterceptor {
    
        @Override
        public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
            
            if (!(handler instanceof HandlerMethod)) {
                return true;
            }
    
            HandlerMethod handlerMethod = (HandlerMethod) handler;
            Method method = handlerMethod.getMethod();
    
            Idemptent annotation = method.getAnnotation(Idemptent.class);
            if (annotation != null){
                //进行幂等性校验
                checkToken(request);
            }
    
            return true;
        }
    
    
        @Autowired
        private RedisTemplate redisTemplate;
    
        //幂等性校验
        private void checkToken(HttpServletRequest request) {
            String token = request.getHeader("token");
            if (StringUtils.isEmpty(token)){
                throw new RuntimeException("非法参数");
            }
    
            boolean delResult = redisTemplate.delete(token);
            if (!delResult){
                //删除失败
                throw new RuntimeException("重复请求");
            }
        }
    
        @Override
        public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) throws Exception {
    
        }
    
        @Override
        public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) throws Exception {
    
        }
    }
    
    1. 修改token_service_order启动类,让其继承WebMvcConfigurerAdapter
    @Bean
    public IdemptentInterceptor idemptentInterceptor() {
        return new IdemptentInterceptor();
    }
    
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        //幂等拦截器
        registry.addInterceptor(idemptentInterceptor());
        super.addInterceptors(registry);
    }
    
    1. 更新token_service_order与token_service_order_api,新增添加订单方法,并且方法添加自定义幂等注解
    @Idemptent
    @PostMapping("/genOrder2")
    public String genOrder2(@RequestBody Order order){
    
        order.setId(String.valueOf(idWorker.nextId()));
        order.setCreateTime(new Date());
        order.setUpdateTime(new Date());
        int result = orderService.addOrder(order);
    
        if (result == 1){
            System.out.println("success");
            return "success";
        }else {
            System.out.println("fail");
            return "fail";
        }
    }
    
    展开全文
  • JavaScript 数组和对象的幂等操作默认情况下,JavaScript 中的大多数操作都会修改特定值(对象)的内部结构。 无论是通过调用sort 、 push / pop / shift / unshift 、 reverse 、修改内部结构的自定义方法,还是...
  • 什么是幂等

    千次阅读 2021-05-25 00:23:09
    幂等性是 API 接口设计中必须要关注的话题,抽空总结了一下,这也是面试官比较爱问的问题。一、什么是幂等?看一下维基百科怎么说的:幂等性:多次调用方法或者接口不会改变业务状态,可以保证重复...


    幂等性是 API 接口设计中必须要关注的话题,抽空总结了一下,这也是面试官比较爱问的问题。

    一、什么是幂等?

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

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

    二、使用幂等的场景

    1、前端重复提交

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

    2、接口超时重试

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

    3、消息重复消费

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

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

    三、解决方案

    1、token 机制实现

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

    示意图如下:

    具体流程步骤:

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

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

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

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

    注意:

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

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

    2、基于 mysql 实现

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

    示意图如下:

    具体流程步骤:

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

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

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

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

    3、基于 redis 实现

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

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

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

    示意图如下:

    具体流程步骤:

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

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

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

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

    总结

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

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

    - END -

    ????「点击关注」更多惊喜等待你的发现????

    展开全文
  • 【引言】今天被问到一个问题,数据库中哪些操作具有幂等性。恩?当时听了很迷瞪,平时管理数据库,一些操作也没碰到幂等性这个说法啊。鉴于此,今天学习下幂等性是个嘛?!【大纲】1.幂等性是个啥?2.幂等性有什么用...

    【引言】

    今天被问到一个问题,数据库中哪些操作具有幂等性。恩?当时听了很迷瞪,平时管理数据库,一些操作也没碰到幂等性这个说法啊。鉴于此,今天学习下幂等性是个嘛?!

    【大纲】

    1.幂等性是个啥?

    2.幂等性有什么用?

    3.怎样保证幂等性?

    4.幂等性有啥不足?

    一、嘛是幂等性?

    幂等(idempotent)是一个数学与计算机学概念,常见于抽象代数中。

    幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果的函数。这些函数不会影响系统状态,也不用担心重复执行会对系统造成改变。

    幂等性衍生到软件工程中, 它的语义是指:函数/接口可以使用相同的参数重复执行,不应该影响系统状态,也不会对系统造成改变。

    在编程中,一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。第一次请求的时候对资源产生了副作用,但是以后的多次请求都不会再对资源产生副作用。这里的副作用是不会对结果产生破坏或者产生不可预料的结果。

    HTTP/1.1中对幂等性的定义是:一次和多次请求某一个资源对于资源本身应该具有同样的结果(网络超时等问题除外)。

    总的来说,幂等性是指:

    任意多次执行对资源本身所产生的影响均与一次执行的影响相同。

    Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request.

    幂等性:就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击(调用)而产生了副作用。即幂等性=多次执行结果一致+无副作用。

    举例:

    数据库DML操作:

    查询(select)方法本身就是幂等性的,虽然多次执行可能返回结果不一致,但是没有任何副作用。

    插入(insert)和修改(update)方法是非幂等性的,需要通过机制在需要的场景处理以确保多次执行无副作用。

    删除(delete)执行一次或多次都是结果为空(即结果一致),并且无副作用,所以在根据主键ID删除可以认为是(伪)幂等性的,根据非主键删除的如果多次执行无副作用(都是把数据删除),也可以认为是(伪)幂等性。

    dbdfe97d206d7f9d238465e6cef496f8.png

    幂等性需关注几个重点:

    1.幂等不仅仅只是一次(或多次)请求对资源没有副作用(比如查询数据库操作,没有增删改,因此没有对数据库有任何影响)。

    2.幂等还包括第一次请求的时候对资源产生了副作用,但是以后的多次请求都不会再对资源产生副作用。

    3.幂等关注的是以后的多次请求是否对资源产生的副作用,而不关注结果。

    4.网络超时等问题,不是幂等的讨论范围。

    注意:

    幂等性是系统服务对外一种承诺(而不是实现),承诺只要调用接口成功,外部多次调用对系统的影响是一致的。声明为幂等的服务会认为外部调用失败是常态,并且失败之后必然会有重试。

    二、幂等性有什么用?

    什么情况下需要保证幂等性?

    业务开发中,经常会遇到重复提交的情况,无论是由于网络问题无法收到请求结果而重新发起请求,或是前端的操作抖动而造成重复提交情况。在交易系统,支付系统这种重复提交造成的问题有尤其明显,比如:

    1.用户在APP上连续点击了多次提交订单,后台应该只产生一个订单;

    2.向支付宝发起支付请求,由于网络问题或系统BUG重发,支付宝应该只扣一次钱。

    很显然,声明幂等的服务认为,外部调用者会存在多次调用的情况,为了防止外部多次调用对系统数据状态的发生多次改变,将服务设计成幂等。

    为什么要设计幂等性的服务

    幂等可以使得客户端逻辑处理变得简单,但是却以服务逻辑变得复杂为代价。满足幂等服务的需要在逻辑中至少包含两点:

    1.首先去查询上一次的执行状态,如果没有则认为是第一次请求

    2.在服务改变状态的业务逻辑前,保证防重复提交的逻辑

    三、怎样保证幂等性?

    1. 建立唯一索引,防止新增脏数据

    可限制重复插入数据,当重复时,数据库会抛异常,保证不会出现脏数据。但体验不好,并且实用场景有限制。使用全局唯一ID,就是根据业务的操作(业务类型)和内容生成一个全局ID,在执行操作前先根据这个全局唯一ID是否存在,来判断这个操作是否已经执行。如果不存在则把全局ID,存储到存储系统中,比如数据库、redis等。如果存在则表示该方法已经执行,这个全局ID有时效性。

    2. 利用 token 机制,防止页面重复提交

    核心思想是为每一次操作生成一个唯一性的凭证,也就是token。一个token在操作的每一个阶段只有一次执行权,一旦执行成功则保存执行结果。对重复的请求,返回同一个结果。

    3. 状态机幂等

    在有状态的数据中可以使用,如状态机已经处于下一个状态,这时候来了一个上一个状态的变更,理论上是不能够变更的,这样的话,保证了有限状态机的幂等。如果状态是顺序的,不可逆,那么就不会出现 ABA 问题,否则会出现ABA问题。

    4. 乐观锁

    如果只是更新已有的数据,没有必要对业务进行加锁,设计表结构时使用乐观锁,一般通过version来做乐观锁,这样既能保证执行效率,又能保证幂等。乐观锁存在失效的情况,就是常说的ABA问题,不过如果version版本一直是自增的就不会出现ABA的情况。

    5. 对外提供幂等的接口

    通过 source来源+seq序列号来判断请求是否重复, 在并发时只能处理一个请求。其它相同并发请求要么返回请求重复,要么等待前面请求执行完成在执行。

    6. 防重表

    使用订单号orderNo做为去重表的唯一索引,每次请求都根据订单号向去重表中插入一条数据。第一次请求查询订单支付状态,当然订单没有支付,进行支付操作,无论成功与否,执行完后更新订单状态为成功或失败,删除去重表中的数据。后续的订单因为表中唯一索引而插入失败,则返回操作失败,直到第一次的请求完成(成功或失败)。可以看出防重表作用是加锁的功能。

    7. select + insert

    这种情况在没有并发的系统中可以解决幂等问题,在单JVM有并发的时候可以加锁来保证幂等性,在分布式环境它是无法保证幂等的,这时候需要用到分布式锁来保证。

    8. 分布式锁

    在进入方法时,先去获取锁,假如获取到锁,就继续后面的流程。假如没有获取到锁,就等待锁的释放直到获取到锁。当执行完方法时,释放锁。当然,锁要设个超时时间,防止意外没有释放到锁。它用来解决分布式系统的幂等性,常用的实现方案是 redis 和zookeeper等工具。比如Redis。订单发起支付请求,支付系统会去Redis缓存中查询是否存在该订单号的Key,如果不存在,则向Redis增加Key为订单号。查询订单支付已经支付,如果没有则进行支付,支付完成后删除该订单号的Key。通过Redis做到了分布式锁,只有这次订单订单支付请求完成,下次请求才能进来。相比去重表,将放并发做到了缓存中,较为高效。思路相同,同一时间只能完成一次支付请求。

    9. 支付缓冲区

    把订单的支付请求都快速地接下来,一个快速接单的缓冲管道。后续使用异步任务处理管道中的数据,过滤掉重复的待支付订单。优点是同步转异步,高吞吐。不足是不能及时地返回支付结果,需要后续监听支付结果的异步返回。

    四、 幂等性有啥缺点?

    幂等是为了简化客户端逻辑处理,却增加了服务提供者的逻辑和成本,是否有必要,需要根据具体场景具体分析,因此除了业务上的特殊要求外,尽量不提供幂等的接口。

    1.增加了额外控制幂等的业务逻辑,复杂化了业务功能。2.把并行执行的功能改为串行执行,降低了执行效率。

    最后,幂等性虽然复杂化了业务功能和降低了执行效率,但为了保证系统的正确性,是必要的。就上面更新 X 的例子,在单台服务器上,给那段代码加上锁,并给X设为volatile,就保证来数据的正确性了。在分布式环境下并且X是从数据库或者文件里查询出来的,用上面加锁的方式实现就不能保证数据的正确性了,这时候就需要用到分布式锁了。所以,保证方法或接口的幂等性是非常有必要的,因为数据是不能出现任何问题的。

    五、幂等VS防重

    重复提交是在第一次请求已经成功的情况下,人为的进行多次操作,导致不满足幂等要求的服务多次改变状态。而幂等更多使用的情况是第一次请求不知道结果(比如超时)或者失败的异常情况下,发起多次请求,目的是多次确认第一次请求成功,却不会因多次请求而出现多次的状态变化。

    可见,幂等性和重复提交的共同点是均发生了多次提交;不同是幂等性的请求改变只有一次,重复提交的状态会发生变化。

    【参考】

    https://www.cnblogs.com/javalyy/p/8882144.html

    【参考】

    https://www.jianshu.com/p/9d46a730284e

    【参考】

    https://blog.csdn.net/mulinsen77/article/details/89051765

    【参考】

    https://blog.csdn.net/suchahaerkang/article/details/83623764

    【参考】

    https://segmentfault.com/a/1190000019529787

    【参考】

    https://blog.csdn.net/rentuo53/article/details/84919526

    往期精彩文章

    ========================================

    展开全文
  • 深入浅出业务幂等性---4、消息幂等

    千次阅读 2022-03-22 19:50:59
    消息幂等 在系统中当使用消息队列时,无论做哪种技术选型,有很多问题是无论如何也不能忽视的,如:消息必达、消息幂 等等。本章节以典型的RabbitMQ为例,讲解如何保证消息幂等的可实施解决方案,其他MQ选型均可参考...
  • 服务幂等 防重表 对于防止数据重复提交,还有一种解决方案就是通过防重表实现。防重表的实现思路也非常简单。首先创建一张表作为防重表,同时在该表中建立一个或多个字段的唯一索引作为防重字段,用于保证并发情况下...
  • 线上故障之-redis锁处理幂等性失效和幂等性问题解决方案redis锁处理幂等性失效幂等性设计方法1. insert前先select2. 加悲观锁 redis锁处理幂等性失效 @Override @Transactional(rollbackFor = Exception.class) ...
  • 2、什么是接口的幂等性 3、不做接口的幂等性会产生什么影响 4、什么情况下需要保证接口的幂等性 4.1 select:查询操作 4.2 insert:新增操作 4.3 delete:删除操作 4.3.1 绝对删除 具有幂等性 4.3.2 相对删除...
  • 接口的幂等性原则

    千次阅读 2019-10-27 23:29:05
    修改在大多场景下结果一样,但是如果是增量修改是需要保证幂等性的,如下例子: 把表中id为XXX的记录的A字段值设置为1,这种操作不管执行多少次都是幂等的 把表中id为XXX的记录的A字段值增加1,这种操作就不是幂等的 ...
  • rabbitmq实现幂等性操作

    千次阅读 2022-04-15 09:18:16
    消息中间件是分布式系统常用的组件,无论是异步化、解耦、削峰都有广泛的应用价值。我们通常会认为,消息中间件是一个可靠的组件——这里所谓的可靠是指,只要我把消息成功投递到了消息中间件,消息就不会丢失,即...
  • 实战,实现幂等的8种方案!

    千次阅读 2022-01-06 00:55:39
    前言 大家好,我是程序员田螺。今天我们一起来聊聊幂等设计。什么是幂等为什么需要幂等接口超时,如何处理呢?如何设计幂等?实现幂等的8种方案HTTP的幂等1. 什么是幂等? 幂等是一个数学与计...
  • 数据库--幂等--方案

    2021-11-09 21:14:46
    包括:SQL幂等语句有哪些,幂等的方案, SQL幂等语句 操作 是否幂等 实例 查询 幂等 select * from user where xxx //不对数据产生任何变化 ...
  • 幂等性 详解

    千次阅读 2022-04-25 17:42:53
    文章介绍了幂等的数学概念、业务概念和概述,然后从应用场景出发,提出5种解决方案。
  • 数据幂等

    千次阅读 2018-06-14 21:41:21
    在系统设计的时候,操作幂等设计是一点需要考虑的点。 幂等(idempotent、idempotence)是一个数学与计算机学概念,常见于抽象代数中。在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的...
  • 目录1 幂等性介绍2 restful风格调用产生的问题3 接口幂等性问题解决3.1 前端防重3.2 PRG模式防止表单重复提交4 常用Token机制解决服务幂等性4.1 方案介绍5 服务幂等性5.1 并发不高和高并发的情况加锁解决 ...
  • 1、幂等幂等性:多次调用方法或者接口不会改变业务状态,可以保证重复调用的结果和单次调用的结果一致。 幂等性接口:是指可以使用相同参数重复执行,并能获得相同结果的接口。 数学中:在一次元运算为幂等时,其...
  • 前端请求头存放幂等性ID,自定义注解ApiIdempotent,在需要幂等性controller访问前拦截获取幂等性ID作为Redis的Key,值为N(正在执行),设置一定的过期时间。 controller执行后拦截设置Redis中key幂等性ID的值为Y...
  • 幂等和非幂等的关系与区别

    千次阅读 2018-07-31 17:04:26
    此时,我们服务端对方法的处理是,当调用一次方法,更新部分字段,将这条ticket记录的操作记录加一,这次,每次调用的资源是不是变了呢,所以它是有可能是非幂等的操作。 HTTP DELETE方法 HTTP DELETE方法...
  • 接口幂等性常见的解决方案

    千次阅读 2021-03-16 19:29:27
    一、什么是接口幂等性? 接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击而产生了副作用。 举个最简单的例子,那就是支付,用户购买商品后支付,支付扣款成功,但是...
  • 这里的效果一样和返回结果一样的区别,比如我们都知道查询接口具有天然的幂等性,但是多次调用查询接口的过程中,如果有其他操作对查询的数据进行了新增、修改、删除操作,那么查询接口的返回结果就会不一直,但是这...
  • 接口幂等性设计

    2020-11-22 20:58:35
    接口幂等性 在系统中,一个接口运行多次,与运行一次的效果是一致的 什么情况下需要幂等性 重复提交、接口重试、前端操作抖动等 业务场景:用户多次点击提交订单,后台应只生成一个订单 业务场景:支付时,由于网络...
  • 接口幂等性问题产生的原因:假如有个服务提供一个接口(服务部署在多个服务机器),接着有个接口是付款接口。用户在前端上操作的时候,一个订单不小心发起了两次支付请求,然后这两个请求分散在了这个服务部署的不同的...
  • JavaWeb - 接口幂等

    2021-01-22 15:53:00
    接口调用存在的问题 现如今我们的系统大多拆分为分布式SOA,或者微服务,一套系统中包含了多个子系统服务,而一个子...接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点..
  • 幂等性的解决方案

    千次阅读 2021-12-03 17:55:40
    1.幂等性概念 顾名思义,所谓幂等就是对于数据的操作不论多少次,但始终操作的结果是一致的。也就是说,无论相同的查询操作多少次,得到结果始终只是一次的结果和影响。 2.幂等性场景 1、查询操作:查询一次和查询多...
  • 彻底理解接口幂等

    2021-12-31 17:23:05
    1. 幂等性的概念 2.什么情况需要处理接口幂等性问题? 2.1 select 天然自带幂等性。 2.2 insert 当我们重复插入数据的时候,会出现什么情况 ? 2.3 delete 是否具有幂等性? 2.4 update 猜一猜是否具有天热幂等...
  • 微服务:幂等机制和解决方案

    万次阅读 2019-08-23 14:10:13
    1.1 幂等性定义 数学定义 在数学里,幂等有两种主要的定义: 在某二元运算下,幂等元素是指被自己重复运算(或对于函数是为复合)的结果等于它自己的元素。例如,乘法下唯一两个幂等实数为0和1,即s*s=s 某...
  • 幂等性原理

    2021-02-12 11:46:56
    一、幂等 (idempotence) 的概念 幂等的数学概念 幂等是源于一种数学概念。其主要有两个定义如果在一元运算中,x 为某集合中的任意数,如果满足 f(x) = f(f(x)) ,那么该 f 运算具有幂等性,比如绝对值运算 abs(a) =...
  • 幂等性处理就是这类。举两个数据处理时,非幂等性常见的场景:1.在创建订单时,偶有因网络抖动,痴呆,掉线等因素,造成客户端与服务器之间通讯不畅。比如,客户端发起请求后,在约定时间内(通常 30秒),没有得到...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 101,778
精华内容 40,711
关键字:

修改幂等