首页 > 数据库 > Mysql数据库的分布式锁有哪几种?
2019
06-01

Mysql数据库的分布式锁有哪几种?



悲观锁

Mysql实现分布式悲观锁:直接创建一张锁表,然后通过操作该表中的数据来实现了。当我们要锁住某个方法或资源时,我们就在该表中增加一条记录,想要释放锁的时候就删除这条记录。

创建这样一张数据库表:

CREATE TABLE `methodLock` (   `id` int(11NOT NULL AUTO_INCREMENT COMMENT '主键',   `method_name` varchar(64NOT NULL DEFAULT '' COMMENT '锁定的方法名',   `desc` varchar(1024NOT 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='锁定中的方法';


当我们想要锁住某个方法时,执行以下SQL:

insert into methodLock(method_name,descvalues (‘method_name’,‘desc’)


因为我们对method_name做了唯一性约束,这里如果有多个请求同时提交到数据库的话,数据库会保证只有一个操作可以成功,那么我们就可以认为操作成功的那个线程获得了该方法的锁,可以执行方法体内容。

当方法执行完毕之后,想要释放锁的话,需要执行以下Sql:

delete from methodLock where method_name ='method_name'


上面这种简单的实现有以下几个问题:

①这把锁强依赖数据库的可用性,数据库是一个单点,一旦数据库挂掉,会导致业务系统不可用。 ②这把锁没有失效时间,一旦解锁操作失败,就会导致锁记录一直在数据库中,其他线程无法再获得到锁。 ③这把锁只能是非阻塞的,因为数据的insert操作,一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列,要想再次获得锁就要再次触发获得锁操作。 ④这把锁是非重入的,同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。


针对上面的问题,我们可以对症下药:

①数据库是单点?搞两个数据库,数据之前双向同步。一旦挂掉快速切换到备库上。 ②没有失效时间?只要做一个定时任务,每隔一定时间把数据库中的超时数据清理一遍。 ③非阻塞的?搞一个while循环,直到insert成功再返回成功。 ④非重入的?在数据库表中加个字段,记录当前获得锁的机器的主机信息和线程信息,那么下次再获取锁的时候先查询数据库,如果当前机器的主机信息和线程信息在数据库可以查到的话,直接把锁分配给他就可以了。


但无论如何,Mysql数据库的性能和效率大家心里都有点abcd数的,在高并发的情况下, 用Mysql做分布式锁,等着跑路吧


乐观锁

大多数是基于数据版本(version)的记录机制实现的.何谓数据版本号?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表添加一个 “version”字段来实现读取出数据时,将此版本号一同读出,之后更新时,对此版本号加1.在更新过程中,会对版本号进行比较,如果是一致的,没有发生改变,则会成功执行本次操作;如果版本号不一致,则会更新失败.


对乐观锁的含义有了一定的了解后,结合具体的例子,我们来推演下我们应该怎么处理:


假设我们有一张资源表,态(1未分配  2已分配)、资源创建时间、资源更新时间、资源数据版本号.



据进行分配,假设我们现在我们对id=5780这条数那么非分布式场景的情况下,我们一般先查询出来state=1(未分配)的数据,然后从其中选取一条数据可以通过以下语句进行,如果可以更新成功,那么就说明已经占用了这个资源

update t_resource set state=2 where state=1 and id=5780


如果在分布式场景中,由于数据库的update操作是原子是原子的,其实上边这条语句理论上也没有问题,但是这条语句如果在典型的“ABA”情况下,我们是无法感知的。有人可能会问什么是“ABA”问题呢?大家可以网上搜索一下,这里我说简单一点就是,如果在你第一次select和第二次update过程中,由于两次操作是非原子的,所以这过程中,如果有一个线程,先是占用了资源(state=2),然后又释放了资源(state=1),实际上最后你执行update操作的时候,是无法知道这个资源发生过变化的。也许你会说这个在你说的场景中应该也还好吧,但是在实际的使用过程中,比如银行账户存款或者扣款的过程中,这种情况是比较恐怖的.


那么如果使用乐观锁我们如何解决上边的问题呢?


a. 先执行select操作查询当前数据的数据版本号,比如当前数据版本号是26:

select idresource, state,version from t_resource  where state=1 and id=5780;


b. 执行更新操作:

update t_resoure set state=2version=27, update_time=now() where resource=xxxxxx and state=1 and version=26


c.如果上述update语句真正更新影响到了一行数据,那就说明占位成功。如果没有更新影响到一行数据,则说明这个资源已经被别人占位了。

通过上面的讲解,相信大家已经对如何基于数据库表做乐观锁有有了一定的了解了,但是这里还是需要说明一下基于数据库表做乐观锁的一些缺点:

①这种操作方式,使原本一次的update操作,必须变为2次操作: select版本号一次;update一次。增加了数据库操作的次数。 ②如果业务场景中的一次业务流程中,多个资源都需要用保证数据一致性,那么如果全部使用基于数据库资源表的乐观锁,就要让每个资源都有一张资源表,这个在实际使用场景中肯定是无法满足的。而且这些都基于数据库操作,在高并发的要求下,对数据库连接的开销一定是无法忍受的。 ③乐观锁机制往往基于系统中的数据存储逻辑,因此可能会造成脏数据被更新到数据库中。在系统设计阶段,我


扫码芷若 获取免费视频学习资料

编程学习

查 看2019高级编程视频教程免费获取