聊聊Redis分布式锁

一、基于Redis分布式锁方案

1、Redis天然适合做分布式锁，因为它是单进程单线程的，你所有的请求到Redis里面，它都会进行串行化处理；

2、实现方式

Redis Setnx (SET if Not exists)命令在指定的key不存在时，为key設置指定的值

① SETNX KEY_NAME VALUE Expire_Time --这是它获取锁的一个命令格式

設置一个KEY值，成功返回1说明成功获得锁，設置失败返回0说明获取锁失败

②存在问题

* 锁时间不可控制，它无法续租期，因为如果一个线程获得锁，它在它的Expire_Time时间内还未执行完业务，另外一个线程就可以获取它的锁，这就会导致数据的错乱；

* 单点问题

（1）单实例存在进程一旦死掉，会彻底阻塞业务流程，还有存在一个线程获得锁，这个时候redis挂掉了，后来又马上重启，但是redis里面的锁已经失效，所以另外一个线程就能继续获得锁，导致数据错乱；

（2）主从方式，主从数据异步，也会存在锁失效的问题；

注：所以redis无法保证高可用，那么基于Redis分布式锁到底能不能用，这个时候取由业务场景决定，例如这个锁是交易相关的，那这个锁就要严格要求它的一致性，那Redis是无法满足的。但如果是社交场景发消息，redis分布式锁是能够满足的，顶多我们让消息多重复一遍。Redis分布式锁本身是一个AP模型，所以用它做分布式锁要取决于应用场景，AP模型无法保证数据的一致性，一般我们做分布式锁的时候都需要CP模式，也就是数据要保持一致性；

③ 官方建议

* Redis本身建议使用Redlock算法来保证，但是问题是需要至少三个Redis主从实例来完成，维护成本相对较高。Redlock等同于自己实现简单的一致性协议，细节繁琐，且容易出错。

问题本质：分布式锁是CP模型，Redis集群是AP模型，通过CP模型解决分布式锁问题

二、高可用分布式锁设计目标应该要包含以下几点

1、强一致性；

2、服务高可用，系统稳健；

3、锁自动续约及自动释放；

4、代码高度抽象业务接入极简；

5、可视化管理后台、监控及管理；