幂等问题以及可行的解决方案

已于 2022-10-28 16:33:52 修改
阅读量468 收藏 3
点赞数 2
文章标签： java
于 2022-10-28 16:32:10 首次发布

概述

如今很多的服务都会基于分布式或微服务思想完成对系统的架构设计。那么在一个系统就会存在若干个微服务，而且服务间也会产生通信从而相互调用。那么既然产生了服务调用，就会存在服务调用延迟或失败的问题。当出现这种问题，服务端会进行重试等操作或客户端有可能会进行多次点击提交。如果这样请求多次的话，那最终处理的数据结果就一定要保证统一，如支付场景。此时就需要通过保证业务幂等性方案来完成。

什么是幂等

幂等本身是一个数学概念。即 f(n) = 1n ，无论n为多少，f(n)的值永远为1。在编程开发中，对于幂等的定义为：无论对某一个资源操作了多少次，其影响都应是相同的。 换句话说就是：在接口重复调用的情况下，对系统产生的影响是一样的，但是返回值允许不同，如查询。
幂等性不仅仅只是一次或多次操作对资源没有产生影响，还包括第一次操作产生影响后，以后多次操作不会再产生影响。并且幂等关注的是是否对资源产生影响，而不关注结果。

以sql为例

#此SQL无论执行多少次，虽然结果有可能出现不同，都不会对数据产生改变，具备幂等性。
select * from table where id=1 

#此SQL如果id或name有唯一性约束，多次操作只允许插入一条记录，则具备幂等性。如果不是，则不具备幂等性，多次操作会产生多条数据。
insert into table(id,name) values(1,'heima')

#此SQL无论执行多少次，对数据产生的影响都是相同的。具备幂等性。
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

幂等性设计主要从两个维度进行考虑：空间、时间。
空间：定义了幂等的范围，如生成订单的话，不允许出现重复下单。
时间：定义幂等的有效期。有些业务需要永久性保证幂等，如下单、支付等。而部分业务只要保证一段时间幂等即可。
同时对于幂等的使用一般都会伴随着出现锁的概念，用于解决并发安全问题。

接口幂等

解决方案

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

前端防重

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

PRG模式

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

token机制

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

token机制解决幂等问题

  • 服务端提供获取token接口，供客户端进行使用。服务端生成token后，如果当前为分布式架构，将token存放于redis中，如果是单体架构，可以保存在jvm缓存中。

  • 当客户端获取到token后，会携带着token发起请求。

  • 服务端接收到客户端请求后，首先会判断该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性能好，但是这也是一种资源的浪费。

服务幂等

防重表

对于防止数据重复提交，还有一种解决方案就是通过防重表实现。防重表的实现思路也非常简单。首先创建一张表
作为防重表，同时在该表中建立一个或多个字段的唯一索引作为防重字段，用于保证并发情况下，数据只有一条。
在向业务表中插入数据之前先向防重表插入，如果插入失败则表示是重复数据。

对于防重表的解决方案，可能有人会说为什么不使用悲观锁。悲观锁在使用的过程中也是会发生死锁的。悲观锁是
通过锁表的方式实现的。 假设现在一个用户A访问表A（锁住了表A），然后试图访问表B； 另一个用户B访问表
B（锁住了表B），然后试图访问表A。 这时对于用户A来说，由于表B已经被用户B锁住了，所以用户A必须等到用
户B释放表B才能访问。 同时对于用户B来说，由于表A已经被用户A锁住了，所以用户B必须等到用户A释放表A才
能访问。此时死锁就已经产生了。

Mysql乐观锁

MySQL乐观锁是基于数据库完成分布式锁的一种实现，实现的方式有两种：基于版本号、基于条件。但是实现思
想都是基于MySQL的行锁思想来实现的。

image-20221028155824866

通过版本号控制是一种非常常见的方式，适合于大多数场景。但现在库存扣减的场景来说，通过版本号控制就是多
人并发访问购买时，查询时显示可以购买，但最终只有一个人能成功，这也是不可以的。其实最终只要商品库存不
发生超卖就可以。那此时就可以通过条件来进行控制。

mysql乐观锁更适用于一些需要计数的表上，而且在竞争不激烈，出现并发冲突几率较小时，推荐使用乐观锁。虽
然通过MySQL乐观锁可以完成并发控制，但锁的操作是直接作用于数据库上，这样就会在一定程度上对数据库性能产生影响。并且mysql的连接数量是有限的，如果出现大量锁操作占用连接时，也会造成MySQL的性能瓶颈。

Zookeeper分布式锁

实现思想

对于分布式锁的实现，zookeeper天然携带的一些特性能够很完美的实现分布式锁。其内部主要是利用znode节点
特性和watch机制完成。

在zookeeper中节点会分为四类，分别是：
**持久节点：**一旦创建，则永久存在于zookeeper中，除非手动删除。
**持久有序节点：**一旦创建，则永久存在于zookeeper中，除非手动删除。同时每个节点都会默认存在节点序号，每个节点的序号都是有序递增的。如demo000001、demo000002…demo00000N。
**临时节点：**当节点创建后，一旦服务器重启或宕机，则被自动删除。
**临时有序节点：**当节点创建后，一旦服务器重启或宕机，则被自动删除。同时每个节点都会默认存在节点序号，每个节点的序号都是有序递增的。如demo000001、demo000002…demo00000N。

watch监听机制

watch监听机制主要用于监听节点状态变更，用于后续事件触发，假设当B节点监听A节点时，一旦A节点发生修
改、删除、子节点列表发生变更等事件，B节点则会收到A节点改变的通知，接着完成其他额外事情。

image-20221028160508321
实现原理

其实现思想是当某个线程要对方法加锁时，首先会在zookeeper中创建一个与当前方法对应的父节点，接着每个要
获取当前方法的锁的线程，都会在父节点下创建一个临时有序节点，因为节点序号是递增的，所以后续要获取锁的
线程在zookeeper中的序号也是逐次递增的。根据这个特性，当前序号最小的节点一定是首先要获取锁的线程，因
此可以规定序号最小的节点获得锁。所以，每个线程再要获取锁时，可以判断自己的节点序号是否是最小的，如果
是则获取到锁。当释放锁时，只需将自己的临时有序节点删除即可。

image-20221028160716910

在并发下，每个线程都会在对应方法节点下创建属于自己的临时节点，且每个节点都是临时且有序的。
那么zookeeper又是如何有序的将锁分配给不同线程呢？ 这里就应用到了watch监听机制。每当添加一个新的临时
节点时，其都会基于watcher机制监听着它本身的前一个节点等待前一个节点的通知，当前一个节点删除时，就轮
到它来持有锁了。然后依次类推。

优缺点

  • zookeeper是基于cp模式，能够保证数据强一致性。

  • 基于watch机制实现锁释放的自动监听，锁操作性能较好。

  • 频繁创建节点，对于zk服务器压力较大，吞吐量没有redis强。

Redis分布式锁

分布式锁的一个很重要的特性就是互斥性，同一时间内多个调用方加锁竞争，只能有一个调用方加锁成功。而redis是基于单线程模型的，可以利用这个特性让调用方的请求排队，对于并发请求，只会有一个请求能获取到锁。
redis实现分布式锁也很简单，基于客户端的几个API就可以完成，主要涉及三个核心API：
setNx()：向redis中存key-value，只有当key不存在时才会设置成功，否则返回0。用于体现互斥性。
expire()：设置key的过期时间，用于避免死锁出现。
delete()：删除key，用于释放锁。

编写工具类实现加锁

通过jedis.set进行加锁，如果返回值是OK，代表加锁成功
如果加锁失败，则自旋不断尝试获取锁，同时在一定时间内如果仍没有获取到锁，则退出自旋，不再尝试获取锁。
requestId：用于标识当前每个线程自己持有的锁标记

public class SingleRedisLock {
 
    JedisPool jedisPool = new JedisPool("192.168.200.128",6379);
 
    //锁过期时间
    protected long internalLockLeaseTime = 30000;
 
    //获取锁的超时时间
    private long timeout = 999999;
 
    /**
     * 加锁
     * @param lockKey 锁键
     * @param requestId 请求唯一标识
     * @return
     */
    SetParams setParams = SetParams.setParams().nx().px(internalLockLeaseTime);
 
    public boolean tryLock(String lockKey, String requestId){
 
        String threadName = Thread.currentThread().getName();
 
        Jedis jedis = this.jedisPool.getResource();
 
        Long start = System.currentTimeMillis();
 
        try{
            for (;;){
                String lockResult = jedis.set(lockKey, requestId, setParams);
                if ("OK".equals(lockResult)){
                    System.out.println(threadName+":   获取锁成功");
                    return true;
                }
                //否则循环等待，在timeout时间内仍未获取到锁，则获取失败
                System.out.println(threadName+":   获取锁失败，等待中");
                long l = System.currentTimeMillis() ‐ start;
                if (l>=timeout) {
                    return false;
                }
                try {
                    Thread.sleep(100);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }finally {
            jedis.close();
        }
 
    }
}

解锁时，要避免当前线程将别人的锁释放掉。假设线程A加锁成功，当过了一段时间线程A来解锁，但线程A的锁已
经过期了，在这个时间节点，线程B也来加锁，因为线程A的锁已经过期，所以线程B时可以加锁成功的。此时，就
会出现问题，线程A将线程B的锁给释放了。
对于这个问题，就需要使用到加锁时的requestId。当解锁时要判断当前锁键的value与传入的value是否相同，相
同的话，则代表是同一个人，可以解锁。否则不能解锁。
但是对于这个操作，有非常多的人，会先查询做对比，接着相同则删除。虽然思路是对的，但是忽略了一个问题，
原子性。判断与删除分成两步执行，则无法保证原子性，一样会出现问题。所以解锁时不仅要保证加锁和解锁是同
一个人还要保证解锁的原子性。因此结合lua脚本完成查询&删除操作。

/**
     * 解锁
     * @param lockKey 锁键
     * @param requestId 请求唯一标识
     * @return
     */
public boolean releaseLock(String lockKey,String requestId){
 
    String threadName = Thread.currentThread().getName();
    System.out.println(threadName+"：释放锁");
    Jedis jedis = this.jedisPool.getResource();
 
    String lua =
        "if redis.call('get',KEYS[1]) == ARGV[1] then" +
        "   return redis.call('del',KEYS[1]) " +
        "else" +
        "   return 0 " +
        "end";
 
    try {
        Object result = jedis.eval(lua, Collections.singletonList(lockKey),
                                   Collections.singletonList(requestId));
        if("1".equals(result.toString())){
            return true;
        }
        return false;
    }finally {
        jedis.close();
    }
 
}

测试类

public class LoclTest {
 
    public static void main(String[] args) {
 
        //模拟多个5个客户端
        for (int i=0;i<5;i++) {
            Thread thread = new Thread(new LockRunnable());
            thread.start();
        }
    }
 
    private static class LockRunnable implements Runnable {
        @Override
        public void run() {
 
            SingleRedisLock singleRedisLock = new SingleRedisLock();
 
            String requestId = UUID.randomUUID().toString();
            boolean lockResult = singleRedisLock.tryLock("lock", requestId);
            if (lockResult){
 
                try {
                    TimeUnit.SECONDS.sleep(5);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
 
            singleRedisLock.releaseLock("lock",requestId);
        }
    }
}

此时可以发现，多线程会竞争同一把锁，且没有获取获取到锁的线程会自旋不断尝试去获取锁。每当一个线程将锁
释放后，则会有另外一个线程持有锁。依次类推。

存在的问题

锁续期

当对业务进行加锁时，锁的过期时间，绝对不能想当然的设置一个值。假设线程A在执行某个业务时加锁成功
并设置锁过期时间。但该业务执行时间过长，业务的执行时间超过了锁过期时间，那么在业务还没执行完
时，锁就自动释放了。接着后续线程就可以获取到锁，又来执行该业务。就会造成线程A还没执行完，后续线
程又来执行，导致同一个业务逻辑被重复执行。因此对于锁的超时时间，需要结合着业务执行时间来判断，
让锁的过期时间大于业务执行时间。
上面的方案是一个基础解决方案，但是仍然是有问题的。
业务执行时间的影响因素太多了，无法确定一个准确值，只能是一个估值。无法百分百保证业务执行期间，
锁只能被一个线程占有。
如想保证的话，可以在创建锁的同时创建一个守护线程，同时定义一个定时任务每隔一段时间去为未释放的
锁增加过期时间。当业务执行完，释放锁后，再关闭守护线程。 这种实现思想可以用来解决锁续期。

服务单点&集群问题

在单点redis虽然可以完成锁操作，可一旦redis服务节点挂掉了，则无法提供锁操作。
在生产环境下，为了保证redis高可用，会采用异步复制方法进行主从部署。当主节点写入数据成功，会异步的将
数据复制给从节点，并且当主节点宕机，从节点会被提升为主节点继续工作。假设主节点写入数据成功，在没有将
数据复制给从节点时，主节点宕机。则会造成提升为主节点的从节点中是没有锁信息的，其他线程则又可以继续加
锁，导致互斥失效

Redisson分布式锁

redisson是redis官网推荐实现分布式锁的一个第三方类库。其内部完成的功能非常强大，对各种锁都有实现，同
时对于使用者来说非常简单，让使用者能够将更多的关注点放在业务逻辑上。此处重点利用Redisson解决单机
Redis锁产生的两个问题。

单机Redisson实现

依赖
<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons‐pool2</artifactId>
</dependency>
<!‐‐Redis分布式锁‐‐>
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson‐spring‐boot‐starter</artifactId>
    <version>3.13.1</version>
</dependency>
配置文件
server:
  redis:
    host: 192.168.200.150
    port: 6379
    database: 0
    jedis:
      pool:
        max‐active: 500
        max‐idle: 1000
        min‐idle: 4

启动类

@Value("${spring.redis.host}")
private String host;
 
@Value("${spring.redis.port}")
private String port;
 
@Bean
public RedissonClient redissonClient(){
    RedissonClient redissonClient;
 
    Config config = new Config();
    String url = "redis://" + host + ":" + port;
    config.useSingleServer().setAddress(url);
 
    try {
        redissonClient = Redisson.create(config);
        return redissonClient;
    } catch (Exception e) {
        e.printStackTrace();
        return null;
    }
}

锁工具

 @Component
public class RedissonLock {
 
    @Autowired
    private RedissonClient redissonClient;
 
    /**
     * 加锁
     * @param lockKey
     * @return
     */
    public boolean addLock(String lockKey){
 
        try {
            if (redissonClient == null){
                System.out.println("redisson client is null");
                return false;
            }
 
            RLock lock = redissonClient.getLock(lockKey);
 
            //设置锁超时时间为5秒，到期自动释放
            lock.lock(5, TimeUnit.SECONDS);
 
            System.out.println(Thread.currentThread().getName()+":  获取到锁");
 
            //加锁成功
            return true;
        } catch (Exception e) {
            e.printStackTrace();
            return false;
        }
    }
 
    public boolean releaseLock(String lockKey){
 
        try{
            if (redissonClient == null){
                System.out.println("redisson client is null");
                return false;
            }
 
            RLock lock = redissonClient.getLock(lockKey);
            lock.unlock();
            System.out.println(Thread.currentThread().getName()+":  释放锁");
            return true;
        }catch (Exception e){
            e.printStackTrace();
            return false;
        }
    }
}

测试类

@SpringBootTest
@RunWith(SpringRunner.class)
public class RedissonLockTest {
 
    @Autowired
    private RedissonLock redissonLock;
 
    @Test
    public void easyLock(){
        //模拟多个10个客户端
        for (int i=0;i<10;i++) {
            Thread thread = new Thread(new LockRunnable());
            thread.start();
        }
 
        try {
            System.in.read();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
 
    private class LockRunnable implements Runnable {
        @Override
        public void run() {
            redissonLock.addLock("demo");
            try {
                TimeUnit.SECONDS.sleep(3);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            redissonLock.releaseLock("demo");
        }
    }
}

根据执行效果可知，多线程并发获取所时，当一个线程获取到锁，其他线程则获取不到，并且其内部会不断尝试获
取锁，当持有锁的线程将锁释放后，其他线程则会继续去竞争锁。

参考

原文链接

huijia_
关注
  • 2
    点赞
  • 踩
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Java架构师之路：优雅设计与实现接口幂等性
01-03
我们先看两道互联网大厂的面试题？1、分布式/微服务系统接口的幂等性如何设计？比如不能重复扣款；2、消息中间件如何解决消息的幂等性？消息怎么防止不被重复消费；幂等这个词本身源自数学，幂等性是数学中的一个概念，常见于抽象代数中，表达的是N次变换与1次变换的结果相同，在计算机的各个领域都借用了该概念。本课程带你聊聊接口幂等性的那些事。
幂等问题解决方案
六六的小帅的博客
09-01 715
数学中幂等就是多次运算结果一致，对应到实际工作的软件或者网络环境中就是同一个操作不管你操作多少次结果是一样的。select查询操作delete删除操作其中的根据某个key值删除update更新某个字段值。
幂等性问题与解决方案
m0_46836425的博客
04-18 404
幂等概念来自数学，表示N次变换和1次变换的结果是相同的。这里讨论在某些场景下，客户端在调用服务没有达到预期结果时，会进行多次调用，为避免多次重复的调用对服务资源产生副作用，服务提供者会承诺满足幂等。HTTP/1.1中对幂等性的定义是：一次和多次请求某一个资源对于资源本身应该具有同样的副作用（网络超时等问题除外）。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。幂等多次请求对资源没有副作用（比如查询数据库操作，没有增删改，因此没有对数据库有任何影响）。
五种方案解决幂等问题
tom和cat的博客
08-11 7145
方案一：数据库唯一主键实现幂等性 缺点：无法使用change buffer，InnoDB为了进行唯一性检查，必须有一次磁盘IO读页 方案二：业务状态校验 业务上根据业务ID的唯一性和业务处理的结果去做判断，但是这部分判断的逻辑需要考虑原子性。否则会因为并发问题导致幂等失效。解决途径一就是加锁，根据当前的服务环境选择单机或分布式锁。二是可采用现成方案Tomato，通过滑动窗口或者固定窗口拦截控制时间内的请求 方案三：数据库乐观锁实现幂等性 缺点：操作业务前，需要先查询出当前的versio
幂等性是什么？
热门推荐
陈先生的博客
08-19 2万+
4.session机制(后台服务端)在服务器端，生成一个唯一的标识符，将它存入session，同时将它写入表单的隐藏字段中，然后将表单页面发给浏览器，用户录入信息后点击提交。另外在服务器端，获取表单中隐藏字段的值，与session中的唯一标识符比较，如果相等说明是首次提交，就处理本次请求，然后将session中的唯一标识符移除，如果不相等即重复提交。所谓的幂等性，是分布式环境下的一个常见问题，一般是指我们在进行多次操作时，所得到的结果是一样的，即多次运算结果是一致的。使用浏览器历史记录重复提交表单；...
SpringBoot 接口幂等性实现的4种方案！这个我真的服气了！
公众号-老炮说Java
01-30 3148
点击上方蓝色字体，选择“标星公众号”优质文章，第一时间送达关注公众号后台回复pay或mall获取实战项目资料+视频作者：超级小豆丁http://www.mydlq.club/articl...
什么是幂等性？
HRX98的博客
03-07 1万+
什么是幂等性？如何解决幂等性？
接口幂等性解决方案完整代码
最新发布
03-23
接口幂等性解决方案完整代码，基于token的方式解决幂等性问题，代码可以直接运行，只需要修改下数据库配置连接即可
高并发系统数据幂等的解决方案
09-10
本文主要介绍高并发系统数据幂等解决方案,这里整理了几种方案供大家参考，有需要的小伙伴可以参考下
消息幂等通用解决方案汇总整理
03-03
消息幂等通用解决方案汇总整理
RabbitMQ消费端幂等性概念及解决方案.docx
10-26
RabbitMQ消费端幂等性概念及解决方案.docx
高并发下接口幂等性解决方案
lucky的专栏
12-20 792
一、幂等性概念 在编程中.一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“getUsername()和setTrue()”函数就是一个幂等函数. 更复杂的操作幂等保证是利用唯一交易号(流水号)实现. 我的理解：幂等就是一个操作，...
【面试】幂等性问题的思考和总结，防重、幂等，常用解决方案，解决方式
做技术，贵在学习与坚持！
11-02 5585
1、幂等性 幂等性：多次调用方法或者接口不会改变业务状态，可以保证重复调用的结果和单次调用的结果一致。 幂等性接口：是指可以使用相同参数重复执行，并能获得相同结果的接口。 数学中：在一次元运算为幂等时，其作用在任一元素两次后会和其作用一次的结果相同；在二次元运算为幂等时，自己重复运算的结果等于它自己的元素。 计算机学中：幂等指多次操作产生的影响只会跟一次执行的结果相同，通俗的说：某个行为重复的执行，最终获取的结果是相同的，不会因为重复执行对系统造成变化。 防重和幂等的区别： 防重设计主要为了避免产生重复数据
幂等性 详解
suge大帝的博客
04-26 9739
文章介绍了幂等的数学概念、业务概念和概述，然后从应用场景出发，提出5种解决方案。
幂等性问题和解决方法
liang
04-11 1万+
在实际的开发项目中,一个对外暴露的接口往往会面临很多次请求。这就需要考虑到一个幂等性问题。 幂等性 幂等性的概念是：任意多次执行所产生的影响均与一次执行的影响相同，即无论你请求了多少次，对数据库的影响都只能有一次，不能重复处理。 所以，按照上面的理解，每次执行的结果都会发生变化，就是非幂等的。如下面三条sql，只有第三条是非幂等的。 SELECT col1 FROM tab1 WHER col2=...
幂等性及常见的解决方案
weixin_42272869的博客
01-02 1319
幂等性 1、幂等性是什么？ 幂等性的含义是指的是多次操作，但是结果是一致的，换句话说，就是一个操作，你无论重复点击多少次，发送请求的数量有多少，最终要保证操作指执行了一次，不会因为多点产生了副作用。 例如：在支付接口，重复支付导致了多扣钱。 在正常的请求方法中，获取数据的请求是满足幂等性的，因为仅仅涉及到了数据的获取，而涉及到数据新增/删除的请求，我们需要做到接口的幂等性 2、为什么会产生幂等性问题？ 网络的波动。请求可能被重复发送 用户重复操作。用户无意多次触发同一请求，或者相应速度慢的时候有意多次触发
分布式系统中的幂等性的理解
alin1215的博客
07-31 7338
最近在看公司接口文档，里面提到了一个幂等性，今查询相关知识后，对幂等性有所了解。现将参考的博文粘贴于此。 我们的系统大多拆分为分布式SOA或者微服务，一套系统中包含了多个子系统服务。而一个子系统服务往往会去调用另一个服务，而服务调用服务无非就是使用RPC通信或者restful。既然是通信，那么就有可能再服务器处理完毕后返回结果的时候挂掉，这个时候用户端发现很久没有反应，那么就会多次点击按钮，这样...
四种幂等性解决方案
这个人很懒，什么都没有留下。
02-10 2288
四种幂等性解决方案
什么是幂等性？如何解决？
lovoo的博客
05-05 1347
就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。在增删改查4个操作中，尤为注意就是增加或者修改，查询对于结果是不会有改变的，删除只会进行一次，用户多次点击产生的结果一样，修改在大多场景下结果一样，增加在重复提交的场景下会出现。
rabbitmq幂等性解决方案
04-21
RabbitMQ 幂等性解决方案可以使用消息在消费端实现幂等性，也可以使用业务特性来保证幂等性。例如，使用消息唯一ID或者对消费端进行幂等操作来保证幂等性。同时，还可以使用 RabbitMQ 提供的插件 rabbitmq_message_...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值