集群下分布式项目锁解决方案

1、基于数据库缓存(Redis使用Redission下的RLock对逻辑代码加锁)；

2、基于数据库实现原理与Redis的SETNX相似后面演变两种方案：

乐观锁：在数据库表中添加一个version字段，每次更新成功version+1，线程每次更新时需要比较版本号，如果不一致，则更新失败；

悲观锁(排他锁)：基于MySql InnoDB引擎来实现步骤如下：

先建表，代码如下：

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

然后通过数据库引擎，代码如下：

public boolean lock(){
    connection.setAutoCommit(false)
    while(true){
        try{
            result = select * from methodLock where method_name=xxx for update;
            if(result==null){
                return true;
            }
        }catch(Exception e){
 
        }
        sleep(1000);
    }
    return false;
}

最后释放锁，代码如下：

public void unlock(){
    connection.commit();
}

3、基于Zookeeper实现分布式锁(整合curator)

原理如下：

建立一个节点，假如名为 lock 。节点类型为持久节点（Persistent）

每当进程需要访问共享资源时，会调用分布式锁的 lock() 或 tryLock() 方法获得锁，这个时候会在第一步创建的 lock 节点下建立相应的顺序子节点，节点类型为临时顺序节点（EPHEMERAL_SEQUENTIAL），通过组成特定的名字 name+lock+顺序号。

在建立子节点后，对 lock 下面的所有以 name 开头的子节点进行排序，判断刚刚建立的子节点顺序号是否是最小的节点，假如是最小节点，则获得该锁对资源进行访问。

假如不是该节点，就获得该节点的上一顺序节点，并监测该节点是否存在注册监听事件。同时在这里阻塞。等待监听事件的发生，获得锁控制权。

当调用完共享资源后，调用 unlock() 方法，关闭 ZooKeeper，进而可以引发监听事件，释放该锁。

 

三种方案的比较
上面几种方式，哪种方式都无法做到完美。就像CAP一样，在复杂性、可靠性、性能等方面无法同时满足，所以，根据不同的应用场景选择最适合自己的才是王道。

从理解的难易程度角度（从低到高）
数据库 > 缓存 > Zookeeper

从实现的复杂性角度（从低到高）
Zookeeper >= 缓存 > 数据库

从性能角度（从高到低）
缓存 > Zookeeper >= 数据库

从可靠性角度（从高到低）
Zookeeper > 缓存 > 数据库