Redis分布式锁

关于分布式锁，可能绝大部分人都会或多或少涉及到。
举例说明：
从前端界面发起一笔支付请求，如果前端没有做防重处理，那么可能在某一个时刻会有二笔一样的单子同时到达系统后台。

分布式锁的实现

随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

分布式锁主流的实现方案：

基于数据库实现分布式锁

基于缓存（Redis等）

基于Zookeeper

每一种分布式锁解决方案都有各自的优缺点：

性能：redis最高

可靠性：zookeeper最高

这里，我们就基于redis实现分布式锁。

基本实现

借助于redis中的命令setnx(key, value)，key不存在就新增，存在就什么都不做。同时有多个客户端发送setnx命令，只有一个客户端可以成功，返回1（true）；其他的客户端返回0（false）。

主要使用Redis Setnx 命令

在指定的 key 不存在时，为 key 设置指定的值

设置成功，返回 1 。 设置失败，返回 0

redis> EXISTS job                # job 不存在

(integer) 0

 

redis> SETNX job "programmer"    # job 设置成功

(integer) 1

 

redis> SETNX job "code-farmer"   # 尝试覆盖 job ，失败

(integer) 0

 

redis> GET job                   # 没有被覆盖

"programmer”

为了确保分布式锁可用，我们至少要确保锁的实现同时满足以下四个条件：

1、互斥性：任意时刻，只能有一个客户端获取锁，不能同时有两个客户端获取到锁。

2、安全性：锁只能被持有该锁的客户端删除，不能由其它客户端删除。

3、死锁：获取锁的客户端因为某些原因（如down机等）而未能释放锁，其它客户端再也无法获取到该锁。

4、容错：当部分节点（redis节点等）down机时，客户端仍然能够获取锁和释放锁。