接口幂等性测试

前言

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

我们在开发中主要操作也就是CURD,其中读取操作和删除操作是天然幂等的,我们所关心的就是创建操作、更新操作。

创建操作一定是非幂等的因为要涉及到新数据的产生,而更新操作有可能幂等有可能非幂等,这个要看具体业务场景。

一、幂等性的使用场景

1、前端重复提交

就好比有个新增商品的功能,有个保存按钮,如果前端连续多次点击保存,后端就会收到多次请求接口,如果没做好幂等就会重复创建了多条记录,
就会出现脏数据。

这个也就是我们所说的如何防止前端重复提交的问题。

2、接口超时重试

当我们调取第三方接口的时候,有可能会因为网络等原因导致调用失败,所以我们会对接口调用添加失败重试的机制,Spring可以通过@Retryable注解实现重试机制。

既然重试就可能出现重复调用接口。这时再次调用时如果没有做好幂等,就可能出现脏数据。

3、消息重复消费

这个是无法避免的,因为我们说MQ在生产端和消费端都有重试机制,也就是同一消息很可能会被重复消费。

如果业务保证多次消费的结果是一样的那没问题,但是如果业务无法满足那就需要通过其它方式来保证消费端的幂等。

 

二、初级方式来保证尽量幂等

1、插入前先判断数据是否存在

这种是最基础的,也是我们在开发中必须要做的。我们会在插入或者更新前先判断下,当前这个数据数据库中是否已经存在,如果不存在则不允许重复插入,不存在则可插入。

代码示例如下:

<span style="color:#4b4b4b"><code class="language-java">    <span style="color:#f92672">public</span> <span style="color:#f92672">void</span> <span style="color:#a6e22e">save</span><span style="color:#f8f8f2">(Goods goods)</span> {
        <span style="color:#75715e">// 1、先通过商品唯一code,查询数据库属否存在   </span>
        <span style="color:#e6db74">Goods</span> <span style="color:#e6db74">goods</span> <span style="color:#ab5656">=</span> findGoods(goods.getCode);
        <span style="color:#75715e">// 2、如果这条数据在db里已经存在了,此时就直接返回了   </span>
        <span style="color:#f92672">if</span> (goods != <span style="color:#ae81ff">null</span>) {
            <span style="color:#f92672">return</span>;
        }
        <span style="color:#75715e">// 3、如果要是这条数据在db里不存在,此时就会执行数据插入逻辑了   </span>
        insertGoods(goods);
    }
</code></span>

2、前端做一些交互控制

好比有个新增商品的功能,有个保存按钮,用户点击保存按钮后,立马按钮置灰,或者页面跳转到商品列表页面,这样可以防止很大部分的前端重复提交。

 

三、高并发下如何保证幂等?

上面两种初级方法,在高并发下显然是无法保证接口幂等的,所以在高并发下,我们来如何保证接口的幂等呢,这里整理几种常见的解决办法。

1、基于悲观锁

定义: 当要对数据库中的一条数据进行修改的时候,为了避免同时被其他人修改,最好的办法就是直接对该数据进行加锁以防止并发。

这里以更新商品订单状态来举例:一般订单有订单创建订单确认订单支付订单完成取消订单等订单流程。

当我更新订单状态为订单完成的时候,我们首先通过判断该订单的状态是否是订单支付,如果是不是则直接返回,否则更新状态为已完成。

伪代码示例如下

<span style="color:#4b4b4b"><code class="language-sql">  <span style="color:#f92672">begin</span>; <span style="color:#75715e">-- 1.开始事务</span>
  <span style="color:#75715e">-- 查询订单,判断状态</span>
  <span style="color:#f92672">select</span> order_no,status <span style="color:#f92672">from</span> <span style="color:#f92672">order</span> <span style="color:#f92672">where</span> order_no<span style="color:#ab5656">=</span><span style="color:#e6db74">'20200524-1'</span> 
  if(status <span style="color:#ab5656">!=</span>订单支付状态){
        <span style="color:#75715e">-- 非订单支付状态,不能更新为已完成;</span>
        <span style="color:#f92672">return</span> ;
    }
  <span style="color:#75715e">-- 更新完成</span>
  <span style="color:#f92672">update</span> <span style="color:#f92672">order</span> <span style="color:#f92672">set</span> status<span style="color:#ab5656">=</span><span style="color:#e6db74">'订单完成'</span> order_no<span style="color:#ab5656">=</span><span style="color:#e6db74">'20200524-1'</span> 
   <span style="color:#f92672">commit</span>; <span style="color:#75715e">-- 2.提交事务</span>
</code></span>

这是我们常见的一种写法,但这种写法在高并发环境下,可能会造成一个业务被执行两次的情况发生:

同时有两个请求过来,大家几乎同时查数据库订单状态,都是订单支付状态,然后就支持接下来一系列操作,这就导致一个业务被执行了两次,如果接下来一系列操作不是幂等的

那么就会出现脏数据。这里我们就可以通过悲观锁实现,也就是添加for update字段。

伪代码示例如下

<span style="color:#4b4b4b"><code class="language-sql">  <span style="color:#f92672">begin</span>;  <span style="color:#75715e">--  1.开始事务</span>
  <span style="color:#75715e">--  查询订单,判断状态</span>
  <span style="color:#f92672">select</span> order_no,status <span style="color:#f92672">from</span> <span style="color:#f92672">order</span> <span style="color:#f92672">where</span> order_no<span style="color:#ab5656">=</span><span style="color:#e6db74">'20200524-1'</span> <span style="color:#f92672">for</span> <span style="color:#f92672">update</span> 
  if(status <span style="color:#ab5656">!=</span>订单支付状态){
        <span style="color:#75715e">-- 非订单状态,不能更新为已完成;</span>
        <span style="color:#f92672">return</span> ;
    }
 <span style="color:#75715e">--  更新完成</span>
  <span style="color:#f92672">update</span> <span style="color:#f92672">order</span> <span style="color:#f92672">set</span> status<span style="color:#ab5656">=</span><span style="color:#e6db74">'完成'</span> order_no<span style="color:#ab5656">=</span><span style="color:#e6db74">'20200524-1'</span> 
   <span style="color:#f92672">commit</span>; <span style="color:#75715e">-- 2.提交事务</span>
</code></span>

1)这里order_no需要添加索引,否则会锁表

2) 悲观锁在同一事务操作过程中,锁住了一行数据。悲观锁性能不佳所以一般不建议用悲观锁做这个事情。

2、基于乐观锁

定义:乐观锁就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号机制

所谓的乐观锁就是在表中新增一个version(版本号)字段。

通过版本号的方式,来控制update的操作的幂等性,用户查询出要修改的数据,系统将数据返回给页面,将数据版本号放入隐藏域,用户修改数据,点击提交,将版本号一同提交

给后台,后台使用版本号作为更新条件。

<span style="color:#4b4b4b"><code class="language-sql"><span style="color:#f92672">update</span> <span style="color:#f92672">set</span> version <span style="color:#ab5656">=</span> version <span style="color:#ab5656">+</span><span style="color:#ae81ff">1</span> ,count<span style="color:#ab5656">=</span>count<span style="color:#ab5656">+</span><span style="color:#ae81ff">1</span> <span style="color:#f92672">where</span> id <span style="color:#ab5656">=</span>xxx <span style="color:#f92672">and</span> version <span style="color:#ab5656">=</span> ${version};
</code></span>

注意:乐观锁能够保证的是update的操作的幂等性,如果你的update本身就是幂等操作,或者install操作那就不能用乐观锁了。

3、基于状态码

很多业务表,都是有状态的,比如订单表,一般订单有1-订单创建2-订单确认3-订单支付、 4-订单完成5-取消订单等订单流程,当我们更新订单状态

<span style="color:#4b4b4b"><code class="language-sql"><span style="color:#f92672">update</span> order_table <span style="color:#f92672">set</span> status<span style="color:#ab5656">=</span><span style="color:#ae81ff">3</span> <span style="color:#f92672">where</span> order_no<span style="color:#ab5656">=</span><span style="color:#e6db74">'20200524-1'</span> <span style="color:#f92672">and</span> status<span style="color:#ab5656">=</span><span style="color:#ae81ff">2</span>;
</code></span>

第一个请求时,成功把 订单确认 状态修改成 订单支付,sql执行结果的影响行数是1。

第二个请求时,同样想把 订单确认 状态修改成 订单支付,但是sql执行结果的影响行数为0。如果是0,那么我们直接可以返回成功了。而不需要做接下来的业务操作,以此来保证保证

接口的幂等性。

4、基于唯一索引

一般来讲悲观锁、乐观锁、状态码作用于update操作来实现幂等,而唯一索引是针对install操作来保证幂等。

1) 创建订单时,前端先通过接口获取订单号,再请求后端时带入订单号,订单表中订单号添加唯一索引,如果存在插入相同订单号则直接报错。

2) 消费MQ消息时,messageId是唯一的,我们可以新添加一种消费记录表,将messageId作为主键,如果重复消费那么就会存在相同的messageId,插入直接报错。

5、基于分布式锁

分布式锁实现幂等性的逻辑就是,请求过来时,先去尝试获得分布式锁,如果获得成功,就执行业务逻辑,反之获取失败的话,就舍弃请求直接返回成功。

其实前面介绍过的悲观锁,本质是使用了数据库的分布式锁,都是将多个操作打包成一个原子操作,保证幂等。但由于数据库分布式锁的性能不太好,

我们可以改用:redis或zookeeper来实现分布式锁。

6、基于 Token

token方案的特点就是:需要两次请求才能完成一次业务的操作。

一般包括两个请求阶段:

1)客户端请求申请获取token,服务端生成token返回。

2)第二次请求带着这个token,服务端验证token,完成业务操作。

注意:,在验证token是否存在,不要用redis.get(token)之后,在用redis.del(token),这样不是原子操作在高并发情况下依然会存在幂等问题。

我们可以直接用redis.del(token)的方式:

<span style="color:#4b4b4b"><code class="language-sql">redis<span style="color:#ab5656">></span> <span style="color:#f92672">SET</span> key1 "Hello"
OK
redis<span style="color:#ab5656">></span> <span style="color:#f92672">SET</span> key2 "World"
OK
redis<span style="color:#ab5656">></span> DEL key1 key2 key3
(<span style="color:#e6db74">integer</span>) <span style="color:#ae81ff">2</span>
redis<span style="color:#ab5656">></span> 
</code></span>

我们看返回是否大于0,就知道是否有数据了,而且因为redis命令操作是单线程的,所以不会出现同时返回1,所以是能够保证幂等的。

这种方式最大的缺点需要两次请求,其实简单点我们可以进行一次请求,那就是前端生成唯一token,而不通过后端获取。

Setnx 命令

在指定的 key 不存在时,为 key 设置指定的值。设置成功,返回1。 设置失败,返回 0。

实例

<span style="color:#4b4b4b"><code class="language-sql">redis<span style="color:#ab5656">></span> <span style="color:#f92672">EXISTS</span> job      <span style="color:#75715e">--  job 不存在</span>
(<span style="color:#e6db74">integer</span>) <span style="color:#ae81ff">0</span>

redis<span style="color:#ab5656">></span> SETNX job "programmer"  <span style="color:#75715e">--  job 设置成功</span>
(<span style="color:#e6db74">integer</span>) <span style="color:#ae81ff">1</span>

redis<span style="color:#ab5656">></span> SETNX job "code-farmer" <span style="color:#75715e">--  尝试覆盖 job ,失败</span>
(<span style="color:#e6db74">integer</span>) <span style="color:#ae81ff">0</span>

redis<span style="color:#ab5656">></span> <span style="color:#f92672">GET</span> job                 <span style="color:#75715e">--  没有被覆盖</span>
"programmer"
</code></span>

如果返回1则说明第一次请求,如果返回0则说明不是第一次请求,直接返回。

这里需要注意的是Setnx命令key值不会自动过期的,所以不清除会一直占用内存,我们可以借助Expire命令来设置有效时间。

<span style="color:#4b4b4b"><code class="language-sql">redis<span style="color:#ab5656">></span> SETNX mykey "programmer"  <span style="color:#75715e">--  job 设置成功</span>
(<span style="color:#e6db74">integer</span>) <span style="color:#ae81ff">1</span>
<span style="color:#75715e">--  如果设置成功,那么设置将该键的超时设置为 10 秒</span>
redis<span style="color:#ab5656">></span> expire mykey <span style="color:#ae81ff">10</span> 
</code></span>

  • 0
    点赞
  • 15
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
使用JMeter实现接口幂等性测试,可以按照以下步骤进行: 1. 创建测试计划:在JMeter中创建一个新的测试计划,然后添加一个HTTP请求,用于调用需要测试接口。 2. 配置HTTP请求:在HTTP请求中,需要设置请求的URL、请求方法、请求头、请求参数等信息。 3. 添加断言:在HTTP请求中,可以添加断言来验证接口的响应结果是否正确。可以使用响应断言来验证接口返回的数据是否符合预期。 4. 配置JMeter的CSV数据文件:在测试计划中,可以使用CSV数据文件来存储测试数据,包括请求参数和预期结果。需要在CSV文件中添加一列用于存储幂等性Token。 5. 添加HTTP Header Manager:在测试计划中添加HTTP Header Manager,用于设置请求头中的幂等性Token。 6. 添加BeanShell前置处理器:在测试计划中添加BeanShell前置处理器,用于生成并设置幂等性Token。 7. 配置线程组:在测试计划中添加线程组,用于模拟并发请求。可以设置线程数、循环次数、启动延迟等参数。 8. 运行测试:运行测试计划,可以查看测试结果,检查接口幂等性是否符合预期。 需要注意的是,在使用JMeter测试接口幂等性时,需要特别关注幂等性Token的生成和设置,确保每次请求的Token都是唯一的,并且每次请求的Token都能被正确地传递到接口中。同时,需要同时考虑并发请求的情况,以确保接口在多线程环境下也具有幂等性
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值