分布式锁目前比较常用的几种方案：
基于数据库实现分布式锁
基于缓存（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已分配)、资源创建时间、资源更新时间、资源数据版本号。
(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.
2.
CREATE TABLE `methodLock` (
3.
`id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
4.
`method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的方法名',
5.
`desc` varchar(1024) NOT NULL DEFAULT '备注信息',
6.
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间，自动生成',
7.
PRIMARY KEY (`id`),
8.
UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE
9.
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';
10.
通过数据库的排他锁来实现分布式锁。 基于MySQL的InnoDB引擎，可以使用以下方法来实现加锁操作：
1.
2.
public boolean lock(){
3.
connection.setAutoCommit(false)
4.
while(true){
5.
try{
6.
result = select * from methodLock where method_name=xxx for update;
7.
if(result==null){
8.
return true;
9.
}
10.
}catch(Exception e){
11.
12.
}
13.
sleep(1000);
14.
}
15.
return false;
16.
}
17.
在查询语句后面增加for update
，数据库会在查询过程中给数据库表增加排他锁（这里再多提一句，InnoDB引擎在加锁的时候，只有通过索引进行检索的时候才会使用行级锁，否则会使用表级锁。这里我们希望使用行级锁，就要给method_name添加索引，值得注意的是，这个索引一定要创建成唯一索引，否则会出现多个重载方法之间无法同时被访问的问题。重载方法的话建议把参数类型也加上。）。当某条记录被加上排他锁之后，其他线程无法再在该行记录上增加排他锁。
我们可以认为获得排它锁的线程即可获得分布式锁，当获取到锁之后，可以执行方法的业务逻辑，执行完方法之后，再通过以下方法解锁：
1.
2.
public void unlock(){
3.
connection.commit();
4.
}
5.
通过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会获取这一行数据的排它锁，需要等到前一个事务释放该排它锁才可以继续进行
