项目中如何保证幂等、Redis分布式锁

问题背景

假如我们一个支付项目中，用户购买了商品A，用户点击支付的时候瞬间点击了两次，就可能导致后端进行了两次的扣费处理，这个时候肯定是有问题的，怎么解决这个问题？这就涉及到幂等方案的设计了。

什么是幂等？

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

解决方案

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

但是要注意这种只是前端的拦截是非常不安全的，因为行家可以直接绕过前端的验证直接访问后端的接口，所以后端的验证是必不可少的。

• 数据库层面：数据库中添加版本列，每次处理的时候版本加一，对比用户传过来的版本是否一致，不一致就不执行，也就是这个数据库只会被操作一次，因此一次之后版本号就变了，而重发请求的请求参数是不变的，所以请求只会被执行一次。这就是乐观锁的解决方式。
• 使用分布式锁：分布式锁的 key 必须为业务的唯一标识.

Redis如何实现分布式锁？

参考文章

要求：同一个时刻只能由有一个线程获取到锁。
不能死锁：如果持有锁的客户端崩溃，其他的客户端仍然能够获取到锁而不是死锁。

实现方式：

set key value px milliseconds nx

//获取锁（unique_value可以是UUID等）
SET resource_name unique_value NX PX  30000

//释放锁（lua脚本中，一定要比较value，防止误解锁）
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

• set 命令要用 set key value px milliseconds nx，替代 setnx + expire 需要分两次执行命令的方式，保证了原子性，
• value 要具有唯一性，可以使用UUID.randomUUID().toString()方法生成，用来标识这把锁是属于哪个请求加的，在解锁的时候就可以有依据；
• 释放锁时要验证 value 值，防止误解锁；
  通过 Lua 脚本来避免 Check And Set 模型的并发问题，因为在释放锁的时候因为涉及到多个Redis操作 （利用了eval命令执行Lua脚本的原子性）；

加锁代码分析
首先，set()加入了NX参数，可以保证如果已有key存在，则函数不会调用成功，也就是只有一个客户端能持有锁，满足互斥性。其次，由于我们对锁设置了过期时间，即使锁的持有者后续发生崩溃而没有解锁，锁也会因为到了过期时间而自动解锁（即key被删除），不会发生死锁。最后，因为我们将value赋值为requestId，用来标识这把锁是属于哪个请求加的，那么在客户端在解锁的时候就可以进行校验是否是同一个客户端。

解锁代码分析
将Lua代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。在执行的时候，首先会获取锁对应的value值，检查是否与requestId相等，如果相等则解锁（删除key）。

存在的风险

如果存储锁对应key的那个节点挂了的话，就可能存在丢失锁的风险，导致出现多个客户端持有锁的情况，这样就不能实现资源的独享了。
客户端A从master获取到锁
在master将锁同步到slave之前，master宕掉了（Redis的主从同步通常是异步的）。
主从切换，slave节点被晋级为master节点
客户端B取得了同一个资源被客户端A已经获取到的另外一个锁。导致存在同一时刻存不止一个线程获取到锁的情况。