分布式锁方式（一、基于数据库的分布式锁）

╰+哭是因爲堅強的太久メ 2022-04-23 00:02 353阅读 0赞

分布式锁目前比较常用的几种方案：

基于数据库实现分布式锁

基于缓存（redis , memcached）实现分布式锁

基于zookeeper实现分布式锁

三种方案比较

从理解的难易程度角度（从低到高）

数据库 > 缓存 > Zookeeper

从实现的复杂性角度（从低到高）

Zookeeper >= 缓存 > 数据库

从性能角度（从高到低）

缓存 > Zookeeper >= 数据库

从可靠性角度（从高到低）

Zookeeper > 缓存 > 数据库

**正文：**

所谓分布式锁，是分布式系统或者集群的时候使用的锁，来锁定共享的资源，例如项目的进度，每一笔订单都是修改同一个项目进度，所以项目进度必须加上锁。

**1、乐观锁**

基于数据库资源表做乐观锁，用于分布式锁:

1. 首先说明乐观锁的含义:

大多数是基于数据版本(version)的记录机制实现的。何谓数据版本号？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表添加一个 “version”字段来实现读取出数据时，将此版本号一同读出，之后更新时，对此版本号加1。

在更新过程中，会对版本号进行比较，如果是一致的，没有发生改变，则会成功执行本次操作；如果版本号不一致，则会更新失败。

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

(1). 假设我们有一张资源表，如下图所示: t\_resource , 其中有6个字段id, resoource,  state, add\_time, update\_time, version,分别表示表主键、资源、分配状态(1未分配  2已分配)、资源创建时间、资源更新时间、资源数据版本号。

![437162-20160604181422055-1240923233.jpg][]

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

update t\_resource set state=2 where state=1 and id=5780。

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

(6). 那么如果使用乐观锁我们如何解决上边的问题呢？

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

select id, resource, state,version from t\_resource  where state=1 and id=5780;

b. 执行更新操作：

update t\_resoure set state=2, version=27, update\_time=now() where resource=xxxxxx and state=1 and version=26

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

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

(1). 这种操作方式，使原本一次的update操作，必须变为2次操作: select版本号一次；update一次。增加了数据库操作的次数。

(2). 如果业务场景中的一次业务流程中，多个资源都需要用保证数据一致性，那么如果全部使用基于数据库资源表的乐观锁，就要让每个资源都有一张资源表，这个在实际使用场景中肯定是无法满足的。而且这些都基于数据库操作，在高并发的要求下，对数据库连接的开销一定是无法忍受的。

(3). 乐观锁机制往往基于系统中的数据存储逻辑，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整，如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开。

4. 讲了乐观锁的实现方式和缺点，是不是会觉得不敢使用乐观锁了呢？？？当然不是，在文章开头我自己的业务场景中，场景1和场景2的一部分都使用了基于数据库资源表的乐观锁，已经很好的解决了线上问题。所以大家要根据的具体业务场景选择技术方案，并不是随便找一个足够复杂、足够新潮的技术方案来解决业务问题就是好方案？！比如，如果在我的场景一中，我使用zookeeper做锁，可以这么做，但是真的有必要吗？？？答案觉得是没有必要的！！！

**2、排他锁（悲观锁）**

创建一张数据库表：

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

通过数据库的排他锁来实现分布式锁。 基于[MySQL][]的InnoDB引擎，可以使用以下方法来实现加锁操作：

1.  `public boolean lock(){`
2.  `connection.setAutoCommit(false)`
3.  `while(true){`
4.  `try{`
5.  `result = select * from methodLock where method_name=xxx for update;`
6.  `if(result==null){`
7.  `return true;`
8.  `}`
9.  `}catch(Exception e){`
10.  
11. `}`
12. `sleep(1000);`
13. `}`
14. `return false;`
15. `}`

在查询语句后面增加`for update`，数据库会在查询过程中给数据库表增加排他锁（这里再多提一句，InnoDB引擎在加锁的时候，只有通过索引进行检索的时候才会使用行级锁，否则会使用表级锁。这里我们希望使用行级锁，就要给method\_name添加索引，值得注意的是，这个索引一定要创建成唯一索引，否则会出现多个重载方法之间无法同时被访问的问题。重载方法的话建议把参数类型也加上。）。当某条记录被加上排他锁之后，其他线程无法再在该行记录上增加排他锁。

我们可以认为获得排它锁的线程即可获得分布式锁，当获取到锁之后，可以执行方法的业务逻辑，执行完方法之后，再通过以下方法解锁：

1.  `public void unlock(){`
2.  `connection.commit();`
3.  `}`

通过`connection.commit()`操作来释放锁

*  阻塞锁？ `for update`语句会在执行成功后立即返回，在执行失败时一直处于阻塞状态，直到成功。
 *  锁定之后服务宕机，无法释放？使用这种方式，服务宕机之后数据库会自己把锁释放掉。

但是还是无法直接解决数据库单点和可重入问题。

这里还可能存在另外一个问题，虽然我们对`method_name` 使用了唯一索引，并且显示使用`for update`来使用行级锁。但是，MySql会对查询进行优化，即便在条件中使用了索引字段，但是否使用索引来检索数据是由 MySQL 通过判断不同执行计划的代价来决定的，如果 MySQL 认为全表扫效率更高，比如对一些很小的表，它就不会使用索引，这种情况下 InnoDB 将使用表锁，而不是行锁。如果发生这种情况就悲剧了。。。

**还有一个问题，就是我们要使用排他锁来进行分布式锁的lock，那么一个排他锁长时间不提交，就会占用数据库连接。一旦类似的连接变得多了，就可能把数据库连接池撑爆**

数据库实现分布式锁的缺点

会有各种各样的问题，在解决问题的过程中会使整个方案变得越来越复杂。

操作数据库需要一定的开销，性能问题需要考虑。

使用数据库的行级锁并不一定靠谱，尤其是当我们的锁表并不大的时候。

**3、数据库隔离级别**

以上我们分析了mysql数据库基础上分布式锁，那其实还需要理解一下mysql的事物隔离级别才能更好的理解通过存储过程实现分布式锁。

SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。

**Read Uncommitted（读取未提交内容）**

在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为**脏读（Dirty Read）：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。**

**Read Committed（读取提交内容）**

这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的**不可重复读（Nonrepeatable Read）：在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据**，因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。

**Repeatable Read（可重读）**

这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：**幻读 （Phantom Read）：在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的**。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。

**Serializable（可串行化） **  
       这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

mysql有一个autocommit参数，默认是on，他的作用是每一条单独的查询都是一个事务，并且自动开始，自动提交（执行完以后就自动结束了，如果你要适用select for update，而不手动调用 start transaction，这个for update的行锁机制等于没用，因为行锁在自动提交后就释放了），所以事务隔离级别和锁机制即使你不显式调用start transaction，这种机制在单独的一条查询语句中也是适用的，分析锁的运作的时候一定要注意这一点。

再来说说锁机制：  
**共享锁**：由读表操作加上的锁，加锁后其他用户只能获取该表或行的共享锁，不能获取排它锁，也就是说只能读不能写

**排它锁**：由写表操作加上的锁，加锁后其他用户不能获取该表或行的任何锁，典型是mysql事务中

> start transaction;
> 
> select \* from user where userId = 1 for update;

执行完这句以后

1）当其他事务想要获取共享锁，比如事务隔离级别为SERIALIZABLE的事务，执行

> 　　select \* from user;

将会被挂起，因为SERIALIZABLE的select语句需要获取共享锁

2）当其他事务执行

> 　　select \* from user where userId = 1 for update;
> 
> 　　update user set userAge = 100 where userId = 1;

也会被挂起，**因为for update会获取这一行数据的排它锁，需要等到前一个事务释放该排它锁才可以继续进行**

资料来源：

http://xm-king.iteye.com/blog/770721