文章目录
- 一、幂等的概念
- 1.1 什么是幂等
- 1.2 举个例子
- 二、幂等问题的解决方案
- 2.1 准备：先添加2张表（账户表、充值订单表）
- 2.2 方案1：update时将status=0作为条件判断解决
- 原理
- 源码
- 2.3 方案2：乐观锁
- 原理
- 源码
- 2.4 方案3：唯一约束
- 需要添加一张唯一约束辅助表
- 原理
- 用这种方案来处理支付回调通知，伪代码如下
- 源码
- 2.5 方案四：分布式锁
- 2.6 总结
一、幂等的概念
1.1 什么是幂等
幂等指多次操作产生的影响只会跟一次执行的结果相同，通俗的说：某个行为重复的执行，最终获取的结果是相同的，不会因为重复执行对系统造成变化。
1.2 举个例子
比如说咱们有个网站，网站上支持购物，但只能用网站上自己的金币进行付款。
金币从哪里来呢？可通过支付宝充值来，1元对1金币，充值的过程如下
上图中的第7步，这个地方支付宝会给商家发送通知，商家收到支付宝的通知后会执行下面逻辑
step1、判断订单是否处理过
step2、若订单已处理，则直接返回SUCCESS，否则继续向下走
step3、将订单状态置为成功
step4、给用户在平台的账户加金币
step5、返回SUCCESS
由于网络存在不稳定的因素，这个通知可能会发送多次，极端情况下，同一笔订单的多次通知可能同时到达商户端，若商家这边不做幂等操作，那么同一笔订单就可能被处理多次。
比如2次通知同时走到step2，都会看到订单未处理，则会继续向下走，那么账户就会被加2次钱，这将出现严重的事故，搞不好公司就被干倒闭了。
二、幂等问题的解决方案
2.1 准备：先添加2张表（账户表、充值订单表）
-- 创建账户表
create table if not exists t_account
(
id varchar(50) primary key comment '账户id',
name varchar(50) not null comment '账户名称',
balance decimal(12, 2) not null default '0.00' comment '账户余额'
) comment '账户表';
-- 充值记录表
create table if not exists t_recharge
(
id varchar(50) primary key comment 'id，主键',
account_id varchar(50) not null comment '账户id，来源于表t_account.id',
price decimal(12, 2) not null comment '充值金额',
status smallint not null default 0 comment '充值记录状态，0：处理中，1：充值成功',
version bigint not null default 0 comment '系统版本号，默认为0，每次更新+1，用于乐观锁'
) comment '充值记录表';
-- 准备测试数据，
-- 账号数据来一条，
insert ignore into t_account values ('1', '路人', 0);
-- 充值记录来一条，状态为0，稍后我们模拟回调，会将状态置为充值成功
insert ignore into t_recharge values ('1', '1', 100.00, 0, 0);
下面我们将实现，业务方这边给支付宝提供的回调方法，在这个回调方法中会处理刚才上面sql中插入的那个订单，会将订单状态置为成功，成功也就是1，然后给用户的账户余额中添加100金币。
也就是，多个请求渴望对同一个订单进行处理，修改订单的状态，如何只让其中一个请求进行有效修改，不要出现用户只充值了1次，但是由于网络问题，支付宝回调了多次接口，给用户的余额进行了多次添加
这个回调方法，下面会提供4种实现，都可以确保这个回调方法的幂等性，余额只会加100。
2.2 方案1：update时将status=0作为条件判断解决
原理
逻辑如下，重点在于更新订单状态的时候要加上status = 0这个条件，如果有并发执行到这条sql的时候，数据库会对update的这条记录加锁，确保他们排队执行，只有一个会执行成功。
String rechargeId = "充值订单id";
// 根据rechargeId去找充值记录，如果已处理过，则直接返回成功
RechargePO rechargePo = select * from t_recharge where id = #{rechargeId};
// 充值记录已处理过，直接返回成功
if(rechargePo.status==1){
return "SUCCESS";
}
开启Spring事务
// 下面这个sql是重点，重点在where后面要加 status = 0 这个条件；count表示影响行数
int count = (update t_recharge set status = 1 where id = #{rechargeId} and status = 0);
// count = 1，表示上面sql执行成功
if(count!=1){
// 走到这里，说明有并发，直接抛出异常
throw new RuntimeException("系统繁忙，请重试")
}else{
//给账户加钱
update t_account set balance = balance + #{rechargePo.price} where id = #{rechargePo.accountId}
}
提交Spring事务
源码
2.3 方案2：乐观锁
原理
String rechargeId = "充值订单id";
// 根据rechargeId去找充值记录，如果已处理过，则直接返回成功
RechargePO rechargePo = select * from t_recharge where id = #{rechargeId};
// 充值记录已处理过，直接返回成功
if(rechargePo.status==1){
return "SUCCESS";
}
开启Spring事务
// 期望的版本号
Long expectVersion = rechargePo.version;
// 下面这个sql是重点，重点在set后面要有version = version + 1，where后面要加 status = 0 这个条件；count表示影响行数
int count = (update t_recharge set status = 1,version = version + 1 where id = #{rechargeId} and version = #{expectVersion});
// count = 1，表示上面sql执行成功
if(count!=1){
// 走到这里，说明有并发，直接抛出异常
throw new RuntimeException("系统繁忙，请重试")
}else{
//给账户加钱
update t_account set balance = balance + #{rechargePo.price} where id = #{rechargePo.accountId}
}
提交spring事务
重点在于update t_recharge set status = 1,version = version + 1 where id = #{rechargeId} and version = #{expectVersion}这条sql
- set 后面必须要有 version = version + 1
- where后面必须要有 version = #{expectVersion}
这样乐观锁才能起作用。
源码
2.4 方案3：唯一约束
需要添加一张唯一约束辅助表
如下，这个表重点关注第二个字段
idempotent_key，这个字段添加了唯一约束，说明同时向这个表中插入同样值的idempotent_key，则只有一条记录会执行成功，其他的请求会报异常，而失败，让事务回滚，这个知识点了解后，方案就容易看懂了。
-- 幂等辅助表
create table if not exists t_idempotent
(
id varchar(50) primary key comment 'id，主键',
idempotent_key varchar(200) not null comment '需要确保幂等的key',
unique key uq_idempotent_key (idempotent_key)
) comment '幂等辅助表';
原理
String idempotentKey = "幂等key";
// 幂等表是否存在记录，如果存在说明处理过，直接返回成功
IdempotentPO idempotentPO = select * from t_idempotent where idempotent_key = #{idempotentKey};
if(idempotentPO!=null){
return "SUCCESS";
}
开启Spring事务(这里千万不要漏掉，一定要有事务)
// 这里放入需要幂等的业务代码，最好是db操作的代码。。。。。
String idempotentId = "";
// 这里是关键一步，向 t_idempotent 插入记录，如果有并发过来，只会有一个成功，其他的会报异常导致事务回滚
insert into t_idempotent (id, idempotent_key) values (#{idempotentId}, #{idempotentKey});
提交spring事务
用这种方案来处理支付回调通知，伪代码如下
String rechargeId = "充值订单id";
// 根据rechargeId去找充值记录，如果已处理过，则直接返回成功
RechargePO rechargePo = select * from t_recharge where id = #{rechargeId};
// 充值记录已处理过，直接返回成功
if(rechargePo.status==1){
return "SUCCESS";
}
// 生成idempotentKey，这里可以使用，业务id:业务类型，那么我们这里可以使用rechargeId+":"+"RECHARGE_CALLBACK"
String idempotentKey = rechargeId+":"+"RECHARGE_CALLBACK";
// 幂等表是否存在记录，如果存在说明处理过，直接返回成功
IdempotentPO idempotentPO = select * from t_idempotent where idempotent_key = #{idempotentKey};
if(idempotentPO!=null){
return "SUCCESS";
}
开启Spring事务(这里千万不要漏掉，一定要有事务)
// count表示影响行数，这个sql比较特别，看起来并发会出现问题，实际上配合唯一约束辅助表，就不会有问题了
int count = update t_recharge set status = 1 where id = #{rechargeId};
// count != 1，表示未成功
if(count!=1){
// 走到这里，直接抛出异常，让事务回滚
throw new RuntimeException("系统繁忙，请重试")
}else{
//给账户加钱
update t_account set balance = balance + #{rechargePo.price} where id = #{rechargePo.accountId}
}
String idempotentId = "";
// 这里是关键一步，向 t_recharge 插入记录，如果有并发过来，只会有一个成功，其他的会报异常导致事务回滚，上面的
insert into t_recharge (id, idempotent_key) values (#{idempotentId}, #{idempotentKey});
提交spring事务
源码
2.5 方案四：分布式锁
上面三种方式都是依靠数据库的功能解决幂等性的问题，所以比较适合对数据库操作的业务。
若业务没有数据库操作，需要实现幂等，可用分布式锁解决，逻辑如下：
2.6 总结
- 数据库操作的幂等性，4种种方案都可以，第3种方案算是一种通用的方案，可以在项目框架搭建初期就提供此方案，然后在组内推广，让所有人都知晓，可避免很多幂等性问题。
- 方案4大家也要熟悉这个处理过程。
