分布式锁（数据库、ZK、Redis）拍了拍你

一个分布式锁能够具备上面的几种条件，应该来说是比较好的分布式锁了，但是现实中没有十全十美的锁，对于不同的分布式锁，没有最好，只能说那种场景更加适合。

下面我们详细的聊一聊上面说的三种分布式锁的实现原理，先来看看数据库的分布式锁。

数据库分布式锁

==========================================================================

在数据库的分布式锁的实现中，分为**「悲观锁和乐观锁」，「悲观锁的实现依赖于数据库自身的锁机制实现」**。

悲观锁方式实现

==========================================================================

若是要测试数据库的悲观的分布式锁，可以执行下面的sql：select … where … for update （排他锁），注意：where 后面的查询条件要走索引，若是没有走索引，会使用全表扫描，锁全表。

当一个数据库表被加上了排它锁，其它的客户端是不能够再对加锁的数据行加任何的锁，只能等待当前持有锁的释放锁。

全表扫描对于测试就没有太大意义了，where后面的条件是否走索引，要注意自己的索引的使用方式是否正确，并且还取决于**「mysql优化器」**。

排它锁是基于InnoDB存储引擎的，在执行操作的时候，在sql中加入for update，可以给数据行加上排它锁。

在代码的代码的层面上使用connection.commit();，便可以释放锁，但是数据库复杂的加锁和解锁、事务等一系列消耗性能的操作，终归是无法抗高并发。

乐观锁方式实现

==========================================================================

数据库乐观锁的方式实现分布式锁是基于**「版本号控制」的方式实现，类似于「CAS的思想」**，它认为操作的过程并不会存在并发的情况，只有在update version的时候才会去比较。

乐观锁的方式并没有锁的等待，不会因为所等待而消耗资源，下面来测试一下乐观锁的方式实现的分布式锁。

乐观锁的方式实现分布式锁要基于数据库表的方式进行实现，我们认为在数据库表中成功存储该某方法的线程获取到该方法的锁，才能操作该方法。

首先要创建一个表用于储存各个线程操作方法的对应该关系表LOCK：

CREATE TABLE LOCK (

ID int PRIMARY KEY NOT NULL AUTO_INCREMENT,

METHODNAME varchar(64) NOT NULL DEFAULT ‘’,

DESCRIPTION varchar(1024) NOT NULL DEFAULT ‘’,

TIME timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,

UNIQUE KEY UNIQUEMETHODNAME (METHODNAME) USING BTREE ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

复制代码

该表是存储某个方法的是否已经被锁定的信息，若是被锁定则无法获取到该方法的锁，这里注意的是使用UNIQUE KEY唯一约束，表示该方法布恩那个够被第二个线程同时持有。

当你要获取锁的时候，通过执行下面的sql来尝试获取锁：ins