分布式锁的三种实现方式-数据库,redis,Zookeeper

分布式锁的三种实现方式:

1.基于数据库实现分布式锁

2.基于缓存(redis等)实现分布式锁

3.基于Zookeeper实现分布式锁

一:基于数据库实现分布式锁

1.悲观锁

利用select ... where ...for update  排他锁

需要注意的是,其他附加功能与实现基本一致,这里需要注意的是"where name = lock" name字段必须走索引,否则会锁表,这些情况下,比如表不大,mysql优化器会不走这个索引,导致锁表的问题

2.乐观锁

所谓乐观所与前边最大区别在于CAS思想(Compare And Swap 比较并且交换),是不具有互斥的,不会产生所等待而消耗资源,操作过程中认为不存在并发冲突,只有在update version 失败后才能察觉到,我们的抢购,秒杀就是这种实现以防止超卖,通过增加递增版本号字段来实现乐观锁

二:基于缓存(Redis等)实现分布式锁

之前文章我也写过关于setnx的相关介,这里是传送门

1.使用命令介绍:

 (1):SETNEX--SETNX key val:当key不存在时候,set一个key为val的字符串,返回1,若K存在,则什么都不做,返回0

 (2):expir   expire key timeout:为K设置一个超时时间,单位为secound,超过这个时间锁会释放,避免死锁.

(3) delete delete key:删除Key

在使用Redis实现分布式锁的时候,主要会使用到这三个命令

实现思想:

1.获取锁的时候,使用setnx加锁,并且使用expire命令为锁添加一个超时时间,超过这个时间则自动释放,锁的Value值为一个随机的UUID通过uuid在释放锁的时候进行判断

2.获取锁的时候还设置一个锁的超时时间,若超过这个时间放弃获取锁

3.释放锁的时候,通过uuid判断是不是该锁,若是该锁,则执行delete释放锁

下面是分布式锁的简单代码实现

package com.itcorey.thirdAuth.lock;

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.Transaction;
import redis.clients.jedis.exceptions.JedisException;

import java.util.List;
import java.util.UUID;

/**
 * 简单的分布式锁代码实现
 * by corey
 */
public class DistributedLock {

    private final JedisPool jedisPool;

    public DistributedLock(JedisPool jedisPool) {

        this.jedisPool = jedisPool;
    }

    /**
     * 加锁
     *
     * @param lockName       锁的key
     * @param acquireTimeout 获取超时时间
     * @param timeout        锁的超时时间
     * @return
     */
    public String lockWithTimeout(String lockName, long acquireTimeout, long timeout) {
        Jedis conn = null;
        String retIdentifier = null;
        //获取连接
        conn = jedisPool.getResource();
        //随机生成一个value
        String identifier = UUID.randomUUID().toString();
        //锁明,即Key值
        String lockKey = "lock" + lockName;
        //超时时间,上锁后超过此时间自动释放锁
        int lockExpire = (int) (timeout / 1000);

        //获取锁的超时时间,超过这个时间则自动释放锁
        long end = System.currentTimeMillis() + acquireTimeout;
        while (System.currentTimeMillis() < end) {
            if (conn.setnx(lockKey, identifier) == 1) {
                conn.expire(lockKey, lockExpire);
                // 返回value值，用于释放锁时间确认
                retIdentifier = identifier;
                return retIdentifier;

            }
            //返回-1代表key没有设置超时时间，为key设置一个超时时间
            if (conn.ttl(lockKey) == -1) {
                conn.expire(lockKey, lockExpire);
            }
            try {
                Thread.sleep(10);
            } catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        }
        if (conn != null) {
            conn.close();
        }
        return retIdentifier;
    }


    /**
     * 释放锁
     *
     * @param lockName
     * @param identifier
     * @return
     */
    public boolean releaseLock(String lockName, String identifier) {
        Jedis conn = null;
        String lockKey = "lock:" + lockName;
        boolean retFlag = false;
        try {
            conn = jedisPool.getResource();
            while (true) {
                // 监视lock，准备开始事务
                conn.watch(lockKey);
                // 通过前面返回的value值判断是不是该锁，若是该锁，则删除，释放锁
                if (identifier.equals(conn.get(lockKey))) {
                    Transaction transaction = conn.multi();
                    transaction.del(lockKey);
                    List<Object> results = transaction.exec();
                    if (results == null) {
                        continue;
                    }
                    retFlag = true;
                }
                conn.unwatch();
                break;
            }
        } catch (JedisException e) {
            e.printStackTrace();
        } finally {
            if (conn != null) {
                conn.close();
            }
        }
        return retFlag;
    }

}

4.测试刚才实现的分布式锁,例子中使用50个线程去秒杀一个商品,使用-运算符来实现减少商品,从结果有序性就可以看出来是否加锁状态,模拟秒杀服务,其中配置了jedis线程池,在初始化的时候传给分布式

package com.itcorey.thirdAuth.lock;

import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;

/**
 * 分布式锁测试服务
 */
public class Service {

    private static JedisPool pool = null;
    private DistributedLock lock = new DistributedLock(pool);
    int n = 500;
    static {
        JedisPoolConfig config = new JedisPoolConfig();
        // 设置最大连接数
        config.setMaxTotal(200);
        // 设置最大空闲数
        config.setMaxIdle(8);
        // 设置最大等待时间
        config.setMaxWaitMillis(1000 * 100);
        // 在borrow一个jedis实例时，是否需要验证，若为true，则所有jedis实例均是可用的
        config.setTestOnBorrow(true);
        pool = new JedisPool(config, "127.0.0.1", 6379, 3000);

    }
    public void seckill() {
        // 返回锁的value值，供释放锁时候进行判断
        String identifier = lock.lockWithTimeout("resource", 5000, 1000);
        System.out.println(Thread.currentThread().getName() + "获得了锁");
        System.out.println(--n);
        lock.releaseLock("resource", identifier);
    }


}

模拟线程进行秒杀服务;

package com.itcorey.thirdAuth.lock;

/**
 * 模拟线程进行秒杀服务;
 */
public class ThreadA extends Thread {
    private Service service;

    public ThreadA(Service service) {
        this.service = service;
    }

    @Override
    public void run() {
        service.seckill();
    }
}

class Test {
    public static void main(String[] args) {
        Service service = new Service();
        for (int i = 0; i < 50; i++) {
            ThreadA threadA = new ThreadA(service);
            threadA.start();
        }
    }
}

执行结果为

若注释掉使用锁的部分获得的结果：

执行结果为:

三:基于Zookeeper实现分布式锁

zk是一个为分布式提供一致性服务的开源组件,他的内部是一个分层的文件系统目录结构,规定同一个目录下只有一个唯一文件名,基于zookeeper 实现分布式锁的的步骤如下

1）创建一个目录mylock；

2) 线程A想获取锁就在mylock目录下创建临时顺序节点；

3) 获取mylock目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁

4) 线程B获取所有节点，判断自己不是最小节点，设置监听比自己次小的节点；

5）线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是不是最小的节点，如果是则获得锁。

这里推荐一个Apache的开源库Curator，它是一个ZooKeeper客户端，Curator提供的InterProcessMutex是分布式锁的实现，acquire方法用于获取锁，release方法用于释放锁。

优点:具备高可用,可重入,阻塞锁的特性,可解决失效死锁的问题

缺点:因为需要频繁的创建和删除节点，性能上不如Redis方式。

 

总结下上面三种分布式锁的比较:

数据库分布式锁实现

db的操作性能差,并且有锁的风险.并且非阻塞操作失败后,需要轮询,占用cpu资源,长时间不commit或者长时间轮询,会占用较多的链接资源

Redis(缓存)分布式锁实现

锁删除失败 过期时间不好控制,.非阻塞，操作失败后，需要轮询，占用cpu资源;

ZK分布式锁实现

性能不如redis实现,主要原因是写操作（获取锁释放锁）都需要在Leader上执行,然后同步到follower。ZooKeeper有较好的性能和可靠性。

参考:https://www.cnblogs.com/barrywxx/p/11644803.html

如果有什么更加好的实现方式或者有什么建议欢迎一起交流一起学习