接口幂等性

学习缘由

幂等性这个词很高大上，但是又不明白其中含义，因此查资料进行理解学习。
参考原文：路人甲java

什么是幂等性

对于同一笔业务操作，不管调用多少次，得到的结果都一样。
这个在支付业务中是否的重要。

幂等性设计

我们以对接支付宝充值为例，来分析支付回调接口如何设计？

如果我们系统中对接过支付宝充值功能的，我们需要给支付宝提供一个回调接口，支付宝回调信息中会携带（out_trade_no【商户订单号】，trade_no【支付宝交易号】），trade_no在支付宝中是唯一的，out_trade_no在商户系统中是唯一的。

回调接口实现有以下实现方式。

方式1（普通写着玩）

过程如下：

接收到支付宝支付成功请求
根据trade_no 查询当前订单是否处理过
如果订单已处理直接返回，若未处理，继续向下执行
开启本地事务
本地系统给用户加钱
将订单状态置为成功
提交本地事务

上面的过程，对于同一笔订单，如果支付宝同时通知多次，会出现什么问题？当多次通知同时到达第2步时候，查询订单都是未处理的，会继续向下执行，最终本地会给用户加两次钱。

方式2 （jvm加锁）

过程：

接收到支付宝支付成功请求
调用java中Lock加锁
根据trade_no 查询当前订单是否处理过
如果订单已处理直接返回，若未处理继续向下执行
开启本地事务
本地系统给用户加钱
将订单状态置为成功
提交本地事务
释放Lock锁

分析问题：
Lock只能在一个jvm中起效，如果多个请求都被同一套系统处理，上面这种使用Lock的方式是没有问题的，不过如果是集群方式部署系统，同一套代码后面会部署多套，如果支付宝同时发来多个通知经过负载均衡转发到不同的机器上，上面的锁就不起效了。此时对于多个请求相当于无锁处理了，又会出现方式1中的结果。此时我们需要分布式锁来做处理。

方式3（悲观锁）

使用数据库中悲观锁实现。悲观锁类似于方式2中的Lock，只不过是依靠数据库来实现的。数据中悲观锁使用for update来实现，过程如下：

接收到支付宝支付成功请求
打开本地事物
查询订单信息并加悲观锁
select * from t_order where order_id = trade_no for update;
判断订单是否被处理
如果订单已处理直接返回，若未处理，继续向下执行
给本地系统给用户加钱
将订单状态置为成功
提交本地事物

重点在于 for update，读锁升级为互斥锁。

当线程A执行for update，数据会对当前记录加锁，其他线程执行到此行代码的时候，会等待线程A释放锁之后，才可以获取锁，继续后续操作。
事物提交时，for update获取的锁会自动释放。

方式3可以正常实现我们需要的效果，能保证接口的幂等性，不过存在一些缺点：
1.如果业务处理比较耗时，并发情况下，后面线程会长期处于等待状态，占用了很多线程，让这些线程处于无效等待状态，我们的web服务中的线程数量一般都是有限的，如果大量线程由于获取for update锁处于等待状态，不利于系统并发操作。

方式4（乐观锁方式）

接收到支付宝支付成功的请求
查询订单信息
select * from t_order where order_id = trade_no;
判断订单是否已处理
如果订单已处理则返回，若未处理，继续向下执行
打开本地事务
给本地系统给用户价钱
将订单状态置为成功，注意这块重点伪代码：

int num = mysql.exec(UPDATE t_order set status = 1 WHERE order_id = trade_no AND status = 0;)
//上面的update操作会返回影响的行数num
if(num==1){
 //表示更新成功
 提交事务;
}else{
 //表示更新失败
 回滚事务;
}

注意：
update t_order set status = 1 where order_id = trade_no and status = 0; 是依靠乐观锁来实现的，status=0作为条件去更新，类似于java中的cas操作；关于什么是cas操作，可以移步：什么是 CAS 机制 ( http://www.itsoku.com/article/63 )?
执行这条sql的时候，如果有多个线程同时到达这条代码，数据内部会保证update同一条记录会排队执行，最终最有一条update会执行成功，其他未成功的，他们的num为0，然后根据num来进行提交或者回滚操作。

方式5（唯一约束方式）

依赖数据库中唯一约束来实现。

我们可以创建一个表：

CREATE TABLE `t_uq_dipose` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `ref_type` varchar(32) NOT NULL DEFAULT '' COMMENT '关联对象类型',
  `ref_id` varchar(64) NOT NULL DEFAULT '' COMMENT '关联对象id',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uq_1` (`ref_type`,`ref_id`) COMMENT '【保证业务唯一性】'
);

对于任何一个业务，有一个业务类型(ref_type)，业务有一个全局唯一的订单号，业务来的时候，先查询t_uq_dipose表中是否存在相关记录，若不存在，继续放行。