How to Prevent Duplicate Requests

http://mogu.io/prevent-duplicate-requests-4

####1）基于DB中退款订单状态的验证

这种方式简单直观，从DB查询出来的退款详情（包括状态）往往还可以用在后续逻辑中，没有花额外的工作专门应对重复请求的问题。

这种查询状态后进行验证的逻辑，从代码上线后就一直存在于所有含状态的业务逻辑处理中，必不可少。但对于防重复处理效果并不好：在前端添加防重复提交前，每周平均在25笔；前端优化后，每周降到7笔。这个数量占总退款申请数的3%%，一个仍然无法接受的比例。

理论上，任意次请求只要在数据状态更新之前都完成了查询操作，则业务逻辑的重复处理就会发生。如下图所示。优化的方向是减少查询到更新之间业务处理时间，可降低空档期的并发影响。极致情况下如果查询和更新变成了原子操作，则就不存在我们当前的问题。

---

####2）基于缓存数据状态的验证
Redis存储查询轻量快速。在request进来的时候，可以先记录在缓存中。后续进来的request每次进行验证。整个流程处理完成，清除缓存。以退款为例子：

    I.  每次退款发起申请，读取缓存中是否有以orderId为key的值
    II. 没有，则往缓存中写入以orderId为key的value
    III.有，则说明有该订单的退款正在进行。
    IV. 操作完清缓存，或者缓存存值的时候设置生命周期

与1）的发放相比，数据库换成响应更快的缓存。但是仍然不是原子操作。插入和读取缓存还是有时间间隔。在极致的情况下还是存在重复操作的情况。
此方法优化后，每周1笔重复操作。

---

####3）利用唯一索引机制的验证

需要原子性操作，想到了数据库的唯一索引。
新建一个TradeLock表：

CREATE TABLE `TradeLock` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`type` int(11) NOT NULL COMMENT '锁类型',
`lockId` int(11) NOT NULL DEFAULT '0' COMMENT '业务ID',
`status` int(11) NOT NULL DEFAULT '0' COMMENT '锁状态',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='Trade锁机制';

每次request进来则往表里面插入数据：

——成功,则可以继续操作（相当于获取锁）；
——失败,则说明有操作在进行。

操作完成后，删除此条记录。（相当于释放锁）
目前已经上线，等待下周的数据统计。

---

####4）基于缓存的计数器验证：

由于数据库的操作比较消耗性能，了解到redis的计数器也是原子性操作。果断采用计数器。既可以提高性能，还不用存储，而且能提升qps的峰值。

还是以订单退款为例子：

每次request进来则新建一个以orderId为key的计数器，然后＋1。

如果>1（不能获得锁）: 说明有操作在进行，删除。

如果=1（获得锁）: 可以操作。

操作结束（删除锁）：删除这个计数器。
要了解计数器，可以参考：

link