devbox
IT小白
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

Java开发大厂面试第31讲：什么是幂等性？如何保证接口的幂等性？常见的实现方案有哪些？

作者：IT小白 | 2024-06-10 09:39:08

赞

踩

Java开发大厂面试第31讲：什么是幂等性？如何保证接口的幂等性？常见的实现方案有哪些？

幂等性问题是面试中常见的面试问题，也是分布式系统最常遇到的问题之一。在说幂等性之前，我们先来看一种情况，假如老王在某电商平台进行购物，付款的时候不小心手抖了一下，连续点击了两次支付，但此时服务器没做任何验证，于是老王账户里面的钱被扣了两次，这显然对当事人造成了一定的经济损失，并且还会让用户丧失对平台的信任。而幂等性问题说的就是如何防止接口的重复无效请求。

我们今天分享的面试题是，什么是幂等性？如何保证接口的幂等性？

幂等性是指对同一个资源的多个请求，在业务逻辑上具有相同的结果。也就是说，不管对同一个资源发起多少次请求，结果都是一样的，与请求次数无关。在计算机网络领域，幂等性通常用于描述HTTP协议中的某些方法，如GET和PUT。

如何保证接口的幂等性是一个在分布式系统和微服务架构中尤为重要的问题。以下是一些常见的实现方案：

  1. 前端做拦截：对于直接和接口做交互的部分（如Web、App）做一层拦截，例如禁止表单重复提交、点击按钮后按钮置灰等操作。但这种方法只能针对普通用户的常规操作，不能覆盖全场景。
  2. 数据库层面解决：
    • insert语句前先select：在新增数据的时候先select一下关键的字段，如果存在就update，否则insert。但这种方法效率较低，不推荐使用。
    • 悲观锁：使用事务锁死，严格保证防重复，但效率低，后续大量接口会按序请求，积攒接口请求。不适合高并发。
    • 乐观锁：在对应的数据库表中增加版本号表示，每次更新都带上这个版本号表示作为条件。
    • 数据库唯一索引：使用分布式ID作为唯一索引，保证全局唯一性。
  3. 业务代码层面：
    • 状态机：通过状态机来控制业务逻辑的执行，确保重复请求不会导致不一致的结果。
    • 业务代码中使用唯一标识符：在业务代码中为每个请求生成一个唯一标识符，并在处理请求时检查该标识符是否已存在。
    • 接口的合理性设计：设计合理的接口，避免因为接口设计不当而导致的幂等性问题。
  4. 前后端间交互实现：
    • token机制：针对客户端连续点击或者调用方法的超时重试等情况，可以使用token的机制防止重复提交。在调用方进入某个页面时先向服务端申请一个全局ID（token），然后带上这个ID一起发送给服务端。后端在收到请求时检查这个ID是否已经处理过，如果是则返回相应的结果。
    • 传递唯一序列号：每次向服务端请求的时候通过一个短时间的唯一序列号进行验证。这个序列号可以使服务端生成，然后到缓存系统（如Redis）里查询是否存在对应key的键值对，根据其结果判断是否处理过该请求。

典型回答

幂等性最早是数学里面的一个概念，后来被用于计算机领域，用于表示任意多次请求均与一次请求执行的结果相同，也就是说对于一个接口而言，无论调用了多少次，最终得到的结果都是一样的。比如以下代码：

public class IdempotentExample {
    // 变量
    private static int count = 0;
    /**
     * 非幂等性方法
     */
    public static void addCount() {
        count++;
    }
    /**
     * 幂等性方法
     */
    public static void printCount() {
        System.out.println(count);
    }
}

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16

对于变量 count 来说，如果重复调用 addCount() 方法的话，会一直累加 count 的值，因为 addCount() 方法就是非幂等性方法；而 printCount() 方法只是用来打印控制台信息的。因此，它无论调用多少次结果都是一样的，所以它是幂等性方法。

知道了幂等性的概念，那如何保证幂等性呢？

幂等性的实现方案通常分为以下几类：

  • 前端拦截

  • 使用数据库实现幂等性

  • 使用 JVM 锁实现幂等性

  • 使用分布式锁实现幂等性

下面我们分别来看它们的具体实现过程。

1. 前端拦截

前端拦截是指通过 Web 站点的页面进行请求拦截，比如在用户点击完“提交”按钮后，我们可以把按钮设置为不可用或者隐藏状态，避免用户重复点击。

执行效果如下图所示：

11111111111111111111.gif
按钮点击效果图

核心的实现代码如下：

<script>
    function subCli(){
        // 按钮设置为不可用
        document.getElementById("btn_sub").disabled="disabled";
        document.getElementById("dv1").innerText = "按钮被点击了~";
    }
</script>
<body style="margin-top: 100px;margin-left: 100px;">
    <input id="btn_sub" type="button"  value=" 提 交 "  onclick="subCli()">
    <div id="dv1" style="margin-top: 80px;"></div>
</body>

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

但前端拦截有一个致命的问题，如果是懂行的程序员或者黑客可以直接绕过页面的 JS 执行，直接模拟请求后端的接口，这样的话，我们前端的这些拦截就不能生效了。因此除了前端拦截一部分正常的误操作之外，后端的验证必不可少。

2. 数据库实现

数据库实现幂等性的方案有三个：

  • 通过悲观锁来实现幂等性

  • 通过唯一索引来实现幂等性

  • 通过乐观锁来实现幂等性

3. JVM 锁实现

JVM 锁实现是指通过 JVM 提供的内置锁如 Lock 或者是 synchronized 来实现幂等性。使用 JVM 锁来实现幂等性的一般流程为：首先通过 Lock 对代码段进行加锁操作，然后再判断此订单是否已经被处理过，如果未处理则开启事务执行订单处理，处理完成之后提交事务并释放锁，执行流程如下图所示：

2.png
JVM 锁执行流程图

JVM 锁存在的最大问题在于，它只能应用于单机环境，因为 Lock 本身为单机锁，所以它就不适应于分布式多机环境。

4. 分布式锁实现

分布式锁实现幂等性的逻辑是，在每次执行方法之前先判断是否可以获取到分布式锁，如果可以，则表示为第一次执行方法，否则直接舍弃请求即可，执行流程如下图所示：

1.png
分布式锁执行流程图

需要注意的是分布式锁的 key 必须为业务的唯一标识，我们通常使用 Redis 或者 ZooKeeper 来实现分布式锁；如果使用 Redis 的话，则用 set 命令来创建和获取分布式锁，执行示例如下：

127.0.0.1:6379> set lock true ex 30 nx
OK # 创建锁成功

  • 1
  • 2

其中，ex 是用来设置超时时间的；而 nx 是 not exists 的意思，用来判断键是否存在。如果返回的结果为“OK”，则表示创建锁成功，否则表示重复请求，应该舍弃。更多关于 Reids 实现分布式的内容可以查看第 20 课时的内容。

考点分析

幂等性问题看似“高大上”其实说白了就是如何避免重复请求提交的问题，出于安全性的考虑，我们必须在前后端都进行幂等性验证，同时幂等性问题在日常工作中又特别常见，解决的方案也有很多，但考虑到分布式系统情况，我们应该优先使用分布式锁来实现。

和此知识点相关的面试题还有以下这些：

  • 幂等性需要注意什么问题？

  • 实现幂等性的关键步骤有哪些？

  • 说一说数据库实现幂等性的执行细节？

知识扩展

1. 幂等性注意事项

幂等性的实现与判断需要消耗一定的资源，因此不应该给每个接口都增加幂等性判断，要根据实际的业务情况和操作类型来进行区分。例如，我们在进行查询操作和删除操作时就无须进行幂等性判断。查询操作查一次和查多次的结果都是一致的，因此我们无须进行幂等性判断。删除操作也是一样，删除一次和删除多次都是把相关的数据进行删除（这里的删除指的是条件删除而不是删除所有数据），因此也无须进行幂等性判断。

2. 幂等性的关键步骤

实现幂等性的关键步骤分为以下三个：

  • 每个请求操作必须有唯一的 ID，而这个 ID 就是用来表示此业务是否被执行过的关键凭证，例如，订单支付业务的请求，就要使用订单的 ID 作为幂等性验证的 Key；

  • 每次执行业务之前必须要先判断此业务是否已经被处理过；

  • 第一次业务处理完成之后，要把此业务处理的状态进行保存，比如存储到 Redis 中或者是数据库中，这样才能防止业务被重复处理。

3. 数据库实现幂等性

使用数据库实现幂等性的方法有三种：

  • 通过悲观锁来实现幂等性

  • 通过唯一索引来实现幂等性

  • 通过乐观锁来实现幂等性

接下来我们分别来看这些实现方式的具体执行过程。

① 悲观锁

使用悲观锁实现幂等性，一般是配合事务一起来实现，在没有使用悲观锁时，我们通常的执行过程是这样的，首先来判断数据的状态，执行 SQL 如下：

select status from table_name where id='xxx';

  • 1
  • 1

然后再进行添加操作：

insert into table_name (id) values ('xxx');

  • 1
  • 1

最后再进行状态的修改：

update table_name set status='xxx';

  • 1
  • 1

但这种情况因为是非原子操作，所以在高并发环境下可能会造成一个业务被执行两次的问题，当一个程序在执行中时，而另一个程序也开始状态判断的操作。因为第一个程序还未来得及更改状态，所以第二个程序也能执行成功，这就导致一个业务被执行了两次。

在这种情况下我们就可以使用悲观锁来避免问题的产生，实现 SQL 如下所示：

begin;  # 1.开始事务
select * from table_name where id='xxx' for update; # 2.查询状态
insert into table_name (id) values ('xxx'); # 3.添加操作
update table_name set status='xxx'; # 4.更改操作
commit; # 5.提交事务

  • 1
  • 2
  • 3
  • 4
  • 5
  • 1
  • 2
  • 3
  • 4
  • 5

在实现的过程中需要注意以下两个问题：

  • 如果使用的是 MySQL 数据库，必须选用 innodb 存储引擎，因为 innodb 支持事务；

  • id 字段一定要是主键或者是唯一索引，不然会锁表，影响其他业务执行。

② 唯一索引

我们可以创建一个唯一索引的表来实现幂等性，在每次执行业务之前，先执行插入操作，因为唯一字段就是业务的 ID，因此如果重复插入的话会触发唯一约束而导致插入失败。在这种情况下（插入失败）我们就可以判定它为重复提交的请求。

唯一索引表的创建示例如下：

CREATE TABLE `table_name` (
  `id` int NOT NULL AUTO_INCREMENT,
  `orderid` varchar(32) NOT NULL DEFAULT '' COMMENT '唯一id',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uq_orderid` (`orderid`) COMMENT '唯一约束'
) ENGINE=InnoDB;

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6

③ 乐观锁

乐观锁是指在执行数据操作时（更改或添加）进行加锁操作，其他时间不加锁，因此相比于整个执行过程都加锁的悲观锁来说，它的执行效率要高很多。

乐观锁可以通过版本号来实现，例如以下 SQL：

update table_name set version=version+1 where version=0;

  • 1
  • 1

最后

幂等性不但可以保证程序正常执行，还可以杜绝一些垃圾数据以及无效请求对系统资源的消耗。今天我们分享了幂等性的 6 种实现方式，包括前端拦截、数据库悲观锁实现、数据唯一索引实现、数据库乐观锁实现、JVM 锁实现，以及分布式锁的实现等方案，其中前端拦截无法防止懂行的人直接绕过前端进行模拟请求的操作。因此后端一定要实现幂等性处理，推荐的做法是使用分布式锁来实现，这样的解决方案更加通用。

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/IT小白/article/detail/698184
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号