分布式锁的实现-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_57780057/article/details/136185498

👽System.out.println(“👋🏼嗨，大家好，我是代码不会敲的小符，双非大四，Java实习中…”);
📚System.out.println(“🎈如果文章中有错误的地方，恳请大家指正！共同进步，共同成长✊”);
🌟System.out.println(“💡如果文章对您有所帮助，希望您可以三连支持一下博主噢🔥”);
🌈System.out.println("🚀正在完成计划中：接下来的三个月里，对梦想的追逐 ");

文章目录

最后

基于 Redis 实现分布式锁

Redis实现分布式锁
 Redis分布式锁案例

基于数据库实现分布式锁

和Redis 的 setnx 类似，创建一个分布式锁表，加锁后，我们就在表增加一条记录，释放锁即把该数据删掉。
问题：

没有失效时间，容易导致死锁；
依赖数据库的可用性，一旦数据库挂掉，锁就马上不可用；
这把锁只能是非阻塞的，因为数据的 insert 操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作；
这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据库中数据已经存在了。

乐观锁

基本原理为：乐观锁一般通过 version 来实现，也就是在数据库表创建一个 version 字段，每次更新成功，则 version+1，读取数据时，将 version 字段一并读出，每次更新时将会对版本号进行比较，如果一致则执行此操作，否则更新失败！

悲观锁

数据库表

CREATE TABLE `methodLock` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的方法名',
  `desc` varchar(1024) NOT NULL DEFAULT '备注信息',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间，自动生成',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';

实现分布式锁的加锁和解锁

	public boolean lock(){
	    connection.setAutoCommit(false)
	    while(true){
	        try{
	            result = select * from methodLock where method_name=xxx for update;
	            if(result==null){
	                return true;
	            }
	        }catch(Exception e){
	
	        }
	        sleep(1000);
	    }
	    return false;
	}
	
	public void unlock(){
	    connection.commit();
	}

基于 Zookeeper 实现分布式锁

ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google Chubby 的一个开源实现，是 Hadoop 和 Hbase 的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。ZooKeeper 分布式锁是基于临时顺序节点和 Watcher（事件监听器）实现的。
实现原理为：

建立一个节点，假如名为 lock 。节点类型为持久节点（Persistent）
每当进程需要访问共享资源时，会调用分布式锁的 lock() 或 tryLock() 方法获得锁，这个时候会在第一步创建的 lock 节点下建立相应的顺序子节点，节点类型为临时顺序节点（EPHEMERAL_SEQUENTIAL），通过组成特定的名字 name+lock+顺序号。
在建立子节点后，对 lock 下面的所有以 name 开头的子节点进行排序，判断刚刚建立的子节点顺序号是否是最小的节点，假如是最小节点，则获得该锁对资源进行访问。
假如不是该节点，就获得该节点的上一顺序节点，并监测该节点是否存在注册监听事件。同时在这里阻塞。等待监听事件的发生，获得锁控制权。
当调用完共享资源后，调用 unlock() 方法，关闭 ZooKeeper，进而可以引发监听事件，释放该锁。
实现的分布式锁是严格的按照顺序访问的并发锁。

总结

如果对性能要求比较高的话，建议使用 Redis 实现分布式锁（优先选择 Redisson 提供的现成的分布式锁，而不是自己实现）。
如果对可靠性要求比较高的话，建议使用 ZooKeeper 实现分布式锁（推荐基于 Curator 框架实现）。不过，现在很多项目都不会用到 ZooKeeper，如果单纯是因为分布式锁而引入 ZooKeeper 的话，那是不太可取的，不建议这样做，为了一个小小的功能增加了系统的复杂度

从性能角度（从高到低）