在分析分布式锁的三种实现方式以前,先了解一下分布式锁应该具有哪些条件:redis
目前几乎不少大型网站及应用都是分布式部署的,分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉咱们“任何一个分布式系统都没法同时知足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance),最多只能同时知足两项。”因此,不少系统在设计之初就要对这三者作出取舍。在互联网领域的绝大多数的场景中,都须要牺牲强一致性来换取系统的高可用性,系统每每只须要保证“最终一致性”,只要这个最终时间是在用户能够接受的范围内便可。sql
在不少场景中,咱们为了保证数据的最终一致性,须要不少的技术方案来支持,好比分布式事务、分布式锁等。有的时候,咱们须要保证一个方法在同一时间内只能被同一个线程执行。数据库
基于数据库实现分布式锁; 基于缓存(Redis等)实现分布式锁; 基于Zookeeper实现分布式锁;
基于数据库的实现方式的核心思想是:在数据库中建立一个表,表中包含方法名等字段,并在方法名字段上建立惟一索引,想要执行某个方法,就使用这个方法名向表中插入数据,成功插入则获取锁,执行完成后删除对应的行数据释放锁。缓存
DROP TABLE IF EXISTS `method_lock`; CREATE TABLE `method_lock` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键', `method_name` varchar(64) NOT NULL COMMENT '锁定的方法名', `desc` varchar(255) NOT NULL COMMENT '备注信息', `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uidx_method_name` (`method_name`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';
INSERT INTO method_lock (method_name, desc) VALUES ('methodName', '测试的methodName');
由于咱们对method_name作了惟一性约束,这里若是有多个请求同时提交到数据库的话,数据库会保证只有一个操做能够成功,那么咱们就能够认为操做成功的那个线程得到了该方法的锁,能够执行方法体内容。服务器
delete from method_lock where method_name ='methodName';
注意:这只是使用基于数据库的一种方法,使用数据库实现分布式锁还有不少其余的玩法!微信
使用基于数据库的这种实现方式很简单,可是对于分布式锁应该具有的条件来讲,它有一些问题须要解决及优化:分布式
由于是基于数据库实现的,数据库的可用性和性能将直接影响分布式锁的可用性及性能,因此,数据库须要双机部署、数据同步、主备切换;微服务
不具有可重入的特性,由于同一个线程在释放锁以前,行数据一直存在,没法再次成功插入数据,因此,须要在表中新增一列,用于记录当前获取到锁的机器和线程信息,在再次获取锁的时候,先查询表中机器和线程信息是否和当前机器和线程相同,若相同则直接获取锁;性能
没有锁失效机制,由于有可能出现成功插入数据后,服务器宕机了,对应的数据没有被删除,当服务恢复后一直获取不到锁,因此,须要在表中新增一列,用于记录失效时间,而且须要有定时任务清除这些失效的数据;测试
不具有阻塞锁特性,获取不到锁直接返回失败,因此须要优化获取逻辑,循环屡次去获取。
在实施的过程当中会遇到各类不一样的问题,为了解决这些问题,实现方式将会愈来愈复杂;依赖数据库须要必定的资源开销,性能问题须要考虑。
SETNX key val:当且仅当key不存在时,set一个key为val的字符串,返回1;若key存在,则什么都不作,返回0。
expire key timeout:为key设置一个超时时间,单位为second,超过这个时间锁会自动释放,避免死锁。
delete key:删除key
在使用Redis实现分布式锁的时候,主要就会使用到这三个命令。
ZooKeeper是一个为分布式应用提供一致性服务的开源组件,它内部是一个分层的文件系统目录树结构,规定同一个目录下只能有一个惟一文件名。基于ZooKeeper实现分布式锁的步骤以下:
(1)建立一个目录mylock;
(2)线程A想获取锁就在mylock目录下建立临时顺序节点;
(3)获取mylock目录下全部的子节点,而后获取比本身小的兄弟节点,若是不存在,则说明当前线程顺序号最小,得到锁;
(4)线程B获取全部节点,判断本身不是最小节点,设置监听比本身次小的节点;
(5)线程A处理完,删除本身的节点,线程B监听到变动事件,判断本身是否是最小的节点,若是是则得到锁。
这里推荐一个Apache的开源库Curator,它是一个ZooKeeper客户端,Curator提供的InterProcessMutex是分布式锁的实现,acquire方法用于获取锁,release方法用于释放锁。
优势:具有高可用、可重入、阻塞锁特性,可解决失效死锁问题。
缺点:由于须要频繁的建立和删除节点,性能上不如Redis方式。
欢迎关注微信公众号『码仔zonE』,专一于分享Java、云计算相关内容,包括SpringBoot、SpringCloud、微服务、Docker、Kubernetes、Python等领域相关技术干货,期待与您相遇!