为什么Zookeeper天生就是一副分布式锁的胚子？

`description` varchar(1024) NOT NULL DEFAULT "" COMMENT '描写', 

PRIMARY KEY (`id`), 

UNIQUE KEY `uiq_idx_resource` (`resource`) 

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='数据库漫衍式锁表'; 

①得到锁

我们可以插入一条数据：

INSERT INTO database_lock(resource, description) VALUES (1, 'lock'); 

由于表 database_lock 中 resource 是独一索引，以是其他哀求提交到数据库，就会报错，并不会插入乐成，只有一个可以插入。插入乐成，我们就获取到锁。

②删除锁

INSERT INTO database_lock(resource, description) VALUES (1, 'lock'); 

这种实现方法很是的简朴，可是必要留意以下几点：

①这种锁没有失效时刻，一旦开释锁的操纵失败就会导致锁记录一向在数据库中，其他线程无法得到锁。这个缺陷也很好办理，好比可以做一个按时使命去按时整理。

②这种锁的靠得住性依靠于数据库。提议配置备库，停止单点，进一步进步靠得住性。

③这种锁长短阻塞的，由于插入数据失败之后会直接报错，想要得到锁就必要再次操纵。

假如必要阻塞式的，可以弄个 for 轮回、while 轮回之类的，直至 INSERT 乐成再返回。

④这种锁也长短可重入的，由于统一个线程在没有开释锁之前无法再次得到锁，由于数据库中已经存在统一份记录了。

想要实现可重入锁，可以在数据库中添加一些字段，好比得到锁的主机信息、线程信息等。

那么在再次得到锁的时辰可以先查询数据，假如当前的主机信息和线程信息等能被查到的话，可以直接把锁分派给它。

乐观锁

顾名思义，体系以为数据的更新在大大都环境下是不会发生斗嘴的，只在数据库更新操纵提交的时辰才对数据作斗嘴检测。假如检测的功效呈现了与预期数据纷歧致的环境，则返回失败信息。

乐观锁大大都是基于数据版本(version)的记录机制实现的。何谓数据版本号?

即为数据增进一个版本标识，在基于数据库表的版本办理方案中，一样平常是通过为数据库表添加一个 “version”字段来实现读取出数据时，将此版本号一同读出，之后更新时，对此版本号加 1。

在更新进程中，会对版本号举办较量，假如是同等的，没有产生改变，则会乐成执行本次操纵;假如版本号纷歧致，则会更新失败。

为了更好的领略数据库乐观锁在现实项目中的行使，这里也就举了业界老生常谈的库存例子。

一个电商平台城市存在商品的库存，当用户举办购置的时辰就会对库存举办操纵(库存减 1 代表已经卖出了一件)。

假如只是一个用户举办操纵数据库自己就能担保用户操纵的正确性，而在并发的环境下就会发生一些意想不到的题目。

好比两个用户同时购置一件商品，在数据库层面现实操纵应该是库存举办减 2 操纵。

可是因为高并发的环境，第一个用户购置完成举办数据读取当前库存并举办减 1 操纵，因为这个操纵没有完全执行完成。

第二个用户就进入购置沟通商品，此时查询出的库存也许是未减 1 操纵的库存导致了脏数据的呈现【线程不安详操纵】。

数据库乐观锁也能担保线程安详，凡是代码层面我们城市这样做：

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!