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

来自公众号：非科班的科班
作者：黎杜

前言

标题使用最近异常火热的微信拍一拍的方式命名，最近拍一拍的玩法被各位网友玩坏了，出现了各种版本的拍一拍。

比如：下面的这个版本是不是似曾相识的感觉，曾几何时你也曾有这种冲动的想法，但是奈于生活，你不得不把这股冲动埋在心底，毕竟冲动是魔鬼。

image

还有比较重口味的，有点哭笑不得，这网友的脑洞真大，要是能把这些心思放在学习和事业上，必是成大事之人，不得不佩服，假如你在吃饭，千万别打我。

image

不得不说拍一拍有点东西，好了，水话就说那么一两句，在开始真正的分布式锁讲解之前，先来个人的分析一下拍一拍的战略动机。

对于老板和一个公司来说，公司付出的每一个商品都是有商用价值的，老板不会把没有商用的价值功能和产品创造出来。

对于拍一拍这个功能，我想是一个引导性的战略思维，对于这个拍一拍新功能，很多网友都会跃跃欲试，不经意间就会尝试，双击别人的头像进行拍一拍。

那么这个双击的动作可能将来微信服务于某项功能而做的准备，待微信的用户习惯了双击操作，微信对于后面的这类操作的功能的推广会变得更加容易。

好了，不能再深究下去了，要是被小马哥看到，估计小马哥就要拍一拍我了，这个纯属个人观点，不代表官方的观点，下面开始我们的分布式锁的讲解。

分布式锁简介

分布式锁的实现方式有以下三种方式：「数据库分布式锁、Redis实现分布式锁、ZooKeeper实现分布式锁」。

为什么需要分布式锁呢？在很久以前，用户全体不大的时候，单体应用就可以足够满足用户的所有请求，当用户增加的时候，出现了一定的并发度，可以使用简单的锁机制来协调并发的共享资源的获取。

但是，随着业务的增大，用户数量的增加，为了满足业务的高效性，集群的出现，简单的锁机制已经不能够满足协调多个应用之间的共享资源了，于是就出现了分布式锁。

分布式锁是协调集群中多应用之间的共享资源的获取的一种方式，可以说它是一种约束、规则。

那么对于一个分布式系统中分布式锁应该满足什么条件呢？也就是它应该具备怎样的约束、规则，下面是我总结的分布式锁至少拥有的几个规则。

1.「锁的互斥性」：在分布式集群应用中，共享资源的锁在同一时间只能被一个对象获取。2. 「可重入」：为了避免死锁，这把锁是可以重入的，并且可以设置超时。3. 「高效的加锁和解锁」：能够高效的加锁和解锁，获取锁和释放锁的性能也好。4. 「阻塞、公平」：可以根据业务的需要，考虑是使用阻塞、还是非阻塞，公平还是非公平的锁。

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

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

数据库分布式锁

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

若是要测试数据库的悲观的分布式锁，可以执行下面的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来尝试获取锁：insert into LOCK(METHODNAME,DESCRIPTION) values (‘getLock’,‘获取锁’) ;来获取锁。

这条sql执行的结果有两种成功和失败，成功说明该方法还没有被某个线程所持有，失败则表明数据库中已经存在该条数据，该方法的锁已经被某个线程所持有。

当你需要释放锁的时候，可以通过执行这条sql：delete from LOCK where METHODNAME='getLock';来释放锁。

乐观锁实现方式还是存在很多问题的，一个是「并发性能问题」，再者「不可重入」以及「没有自动失效的功能」、「非公平锁」，只要当前的库表中已经存在该信息，执行插入就会失败。

其实，对于上面的问题基于数据库也可以解决，比如：不可重复，你可以「增加字段保存当前线程的信息以及可重复的次数」，只要是再判断是当前线程，可重复的次数就会+1，每次执行释放锁就会-1，直到为0。

「没有失效的功能，可以增加一个字段存储最后的失效时间」，根据这个字段判断当前时间是否大于存储的失效时间，若是大于则表明，该方法的索索已经可以被释放。

「非公平锁可以增加一个中间表的形式，作为一个排队队列」，竞争的线程都会按照时间存储于这个中间表，当要某个线程尝试获取某个方法的锁的时候，检查中间表中是否已经存在等待的队列。

每次都只要获取中间表中最小的时间的锁，也实现公平的排队等候的效果，所有的问题总是有解决的思路。

上面就是两种基于数据库实现分布式锁的方式，但是，数据库实现分布式锁的方式只作为学习的例子，实际中不会使用它作为实现分布式锁，重要的是学习解决问题的思路和思想。

Redis实现的分布式锁

之前讲了一篇Redis事务的文章，很多读者Redis事务有啥用，主要是因为Redis的事务并没有Mysql的事务那么强大，所以一般的公司一般确实是用不到。

这里就来说一说Redis事务的一个实际用途，它可以用来实现一个简单的秒杀系统的库存扣减，下面我们就来进行代码的实现。

（1）首先使用线程池初始化5000个客户端。

public static void intitClients() {
 ExecutorService threadPool= Executors.newCachedThreadPool();
 for (int i = 0; i < 5000; i++) {
  threadPool.execute(new Client(i));
 }
 threadPool.shutdown();

 while(true){ 
         if(threadPool.isTerminated()){  
             break;  
         }  
     }  
}

（2）接着初始化商品的库存数为1000。

public static void initPrductNum() {
  Jedis jedis = RedisUtil.getInstance().getJedis();
  jedisUtils.set("produce", "1000");// 初始化商品库存数
  RedisUtil.returnResource(jedis);// 返还数据库连接
 }
}

（3）最后是库存扣减的每条线程的处理逻辑。

/**
 * 顾客线程
 * 
 *
 */
class client implements Runnable {
 Jedis jedis = null;
 String key = "produce"; // 商品数量的主键
 String name;

 public ClientThread(int num) {
  name= "编号=" + num;
 }

 public void run() {

  while (true) {
   jedis = RedisUtil.getInstance().getJedis();
   try {
    jedis.watch(key);
    int num= Integer.parseInt(jedis.get(key));// 当前商品个数
    if (num> 0) {
     Transaction ts= jedis.multi(); // 开始事务
     ts.set(key, String.valueOf(num - 1)); // 库存扣减
     List