分布式锁三种方案

本文主要是介绍分布式锁三种方案，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

基于数据库的分布式锁（基于主键id和唯一索引）

1基于主键实现分布式锁

2基于唯一索引实现分布式锁

其实原理一致，都是采用一个唯一的标识进行判断是否加锁。

原理：通过主键或者唯一索性两者都是唯一的特性，如果多个服务器同时请求到数据库，数据库只会允许同一时间只有一个服务器的请求在对数据库进行操作，其他服务器的请求就需要进行阻塞等待或者进行自旋。如何实现的呢？可以理解为同一时间只有一个请求能够拿到锁，当方式执行完成过后，对锁进行释放过后，其他请求就可以拿到锁再对数据库进行操作，这样就避免了数据不安全问题。

阻塞：线程等待锁释放的一种方式

自旋：自旋包括了递归自旋，while自旋。意思就是不断地去尝试获取锁，只有获取锁才会停止自旋过程，没有拿到就会一直尝试获取锁。

以下是一个基于MySQL实现分布式锁的示例代码：

import java.sql.*;
import java.util.Properties;public class DatabaseLock {private Connection conn;private static final String dbUrl = "jdbc:mysql://localhost:3306/test";private static final String username = "xxxx";private static final String password = "xxxxx";// 构造函数，建立数据库连接public DatabaseLock() throws SQLException {Properties props = new Properties();props.setProperty("user", username);props.setProperty("password", password);conn = DriverManager.getConnection(dbUrl, props);}// 尝试获取锁public boolean tryLock(String lockId) throws SQLException {PreparedStatement stmt = conn.prepareStatement("INSERT INTO locks (id) VALUES (?)");stmt.setString(1, lockId);try {stmt.executeUpdate();return true;} catch (SQLException e) {if (e.getErrorCode() == 1062) { // 锁已存在return false;} else {throw e;}}}// 释放锁public void releaseLock(String lockId) throws SQLException {PreparedStatement stmt = conn.prepareStatement("DELETE FROM locks WHERE id=?");stmt.setString(1, lockId);stmt.executeUpdate();}
}

在使用时，通过创建一个DatabaseLock实例来获取和释放锁：

DatabaseLock databaseLock = new DatabaseLock();// 尝试获取锁，获取成功返回true，获取失败返回false
if (databaseLock.tryLock("lockId")) {try {// do something} finally {databaseLock.releaseLock("lockId"); // 释放锁}
} else {// get lock failed
}

基于Redis的分布式锁

下面就来介绍基于Redis的分布式锁，直接上图；

虚拟机A和虚拟机B两个虚拟机都想对可变的共享资源（广义的概念，可以是数据库的某一张表和数据库中的某一行数据），就会出现线程安全问题，就需要基于锁模型实现同步互斥的手段，保证只有一个虚拟机中的线程进而实现这个线程的相对安全。现在虚拟机要对共享资源上锁，锁对象是Redis，操作的对象就是这个共享资源（假如数据库的一行数据）。

基于Redis实现分布式锁执行流程：

1虚拟机实例A根据Hash算法选择Redis节点（Redis采用的是集群部署，每个服务器都是一个节点），执行Lua脚本加锁（就是通过setnx方法，即set一个key（主键id）到Redis当中，判断Redis中是否有当前key，没有，就返回1，表示加锁成功，有就返回0，表示加锁失败）,并且设置锁的过期时间。当虚拟机A对共享资源上锁成功过后，就拥有了对共享数据的操作权限，然后就可以对共享数据的操作处理，执行事务处理。

问题：在从Redis获取锁的过程和进行设置锁的过期时间过程中出现宕机，就会出现锁一辈子不会被释放？出现死锁问题？

这时候就需要保证获取锁和设置锁的过期时间两行代码的原子性，就是要么同时成功，要么同时失败，如何实现呢？

这时候只要保证将两行代码变成一行代码即可。

原本的setnx和expire是两行代码

if（jedis.setnx（lock_stock，1） == 1）{	//获取锁
//=========在这里出现宕机了=====死锁问题出现了=========expire（lock_stock，5）		 //设置锁超时try {业务代码} finally {jedis.del（lock_stock）			 //释放锁}
}

通过set变成一行代码过后，解决了死锁问题。

if（set(lock_stock,1,"NX","EX",5) == 1）{	//获取锁并设置超时try {业务代码} finally {del（lock_stock）			 		//释放锁}
}

2这时候如果虚拟机B也需要对共享资源进行操作，也去执行lua脚本进行加锁（就是采用setnx的方式--通过set一个key到redis，判断redis中是否已经存储了这个key（行数据的主键id）），如果查询到redis中没有，就会返回1表示加锁成功，如果有就会返回0表示加锁失败，这就能保证共享资源同一时间不会被多个虚拟机同时操作。

3当虚拟机A执行完对自己已经加锁的共享资源执行操作完成之后，必须要执行DEL释放锁，不然其他虚拟机包括虚拟机A都不能再对当前共享资源进行加锁操作，

问题：虚拟机A能保证会执行完成过后一定执行DEL释放锁吗？答案是：不一定的

4当虚拟机A执行对共享资源事务操作完成之后，在执行DEL释放锁之前，代码出现问题，抛出异常就会出现这种问题，虚拟机A就永远不能执行DEL释放锁了,就会导致后续上锁都会失败。

问题：所以就出现上面这个执行流程，如何解决呢？

5这时候起初指执行lua脚本加锁的时候，存储一个过期时间，当不能主动进行DEL释放锁时，到达Redis设置的过期时间，锁就会过期。

这个时候又会出现另一个问题? 就是虚拟机A在设置的过期时间以内还没有执行完对共享资源的操作，锁就过期了，如何解决呢？

6这时候就会执行最后一个流程，后台守护线程（类似于Redission内部提供一个监控锁的看门狗），来定期的检查锁是否存在，如果存在，延长key的过期时间，还需要判断事务是否还在正常执行，如果是异常已经抛出异常，就不用进行后台守护线程了，然后等待锁自动过期。

说这么多？其实就是明白其执行原理，而实际开发过程中，大佬们已经使用Redission封装好了上面的具体实现细节。
Redission实现分布式锁【封装了基于Redis的分布式锁】

什么是Redission?
简单理解为就是操作Redis的一个工具包，让我们使用Redis更加简单，让使用者能够将精力更集中地放在处理业务逻辑上。

Redisson实现分布式锁

Redisson官方文档对分布式锁的解释总结下来有两点

1Redisson加锁自动有过期时间30s，监控锁的看门狗发现业务没执行完，会自动进行锁的续期(重回30s)，这样做的好处是防止在程序还没有执行结束，锁自动过期被删除问题
2当业务执行完成不再给锁续期，即使没有手动释放锁，锁的过期时间到了也会自动释放锁。

 // 获取锁RLock lock = redisson.getLock(LOCK_KEY);try {// 加锁lock.lock();int s = Integer.parseInt(Objects.requireNonNull(stringRedisTemplate.opsForValue().get(REDIS_KEY)));if (s > 0) {// 扣库存s--;System.out.printf("秒杀商品个数剩余：" + s + "\n");// 更新库存stringRedisTemplate.opsForValue().set(REDIS_KEY, String.valueOf(s));} else {System.out.println("活动太火爆了，商品已经被抢购一空了！");}} catch (Exception e) {System.out.println(Thread.currentThread().getName() + "异常：");e.printStackTrace();} finally {// 释放锁lock.unlock();}