转载

浅谈分布式锁

为什么要有分布式锁

随着架构系统的演进，由纯真的单机架构到容器化编排的分布式架构，可以说是一个大型互联网企业发展的必然走向。在网站初创时，应用数量和用户较少，可以把Tomcat和Mysql部署在同一台机器上。随着用户数量增多，访问量增大，并发升高，Tomcat和MySQL竞争资源，此时，单机已经扛不住了，需要把Tomcat和MySQL分离在不同的机器上，用于提升单台机器的处理能力。业务从来没有减少，产品越做越大。应用也越来越复杂，原来的大应用，拆分成多个小应用，加入各级缓存，做了反向代理负责均衡，最后坠入分库分表的深渊。

微服务渐渐代替了庞大冗杂的服务，每个小服务，各司其职。这时候是不是就不存在资源竞争的问题了呢？答案毋庸置疑，在架构的演进过程中，无时无刻都存在着资源竞争的问题。

说起资源竞争的问题，是不是想起了在计算机科学中的一个经典问题——哲学家就餐，也就是在并行计算中多线程同步(Synchronization)时产生的问题？哲学家就餐问题用来解释死锁和资源耗尽的问题，我们不做详细的讨论，感兴趣的同学可以搜索资料了解。既然存在资源竞争的问题，解决的方案必然是对资源加锁，对于锁大家肯定不陌生，在Java中synchronized关键字和ReentrantLock可重入锁在我们的代码或者一些开源代码中随处可见的，一般用于在本地多线程环境中控制对资源的并发访问。但是随着微服务架构的蓬勃兴起，分布式的快速发展，本地加锁已经不能满足我们的业务需求，如果还通过本地加锁的方式锁定资源，在分布式环境中是无用的。于是人们为了在分布式环境中也能实现本地锁的效果，也是纷纷各出其招。

Martin Kleppmann是英国剑桥大学的分布式系统的研究员，之前和Redis之父Antirez进行过关于RedLock(红锁，后续有讲到)是否安全的激烈讨论。Martin认为一般我们使用分布式锁有两个场景:

效率:使用分布式锁可以避免不同节点重复相同的工作，这些工作会浪费资源。比如用户付了钱之后有可能不同节点会发出多封短信。
正确性:加分布式锁同样可以避免破坏正确性的发生，如果两个节点在同一条数据上面操作，比如多个节点机器对同一个订单操作不同的流程有可能会导致该笔订单最后状态出现错误，造成损失。

分布式锁的特点

在了解分布式锁之前，我们首先要了解操作系统级别的锁（特指Linux系统）和Java编发编程时遇到的锁。对Linux锁和Java锁有大概的了解后，我们深入分析分布式锁的实现机制。如果还想深入了解Linux的锁相关的信息，可查阅参考文章。

linux锁的特点

在现代操作系统里，同一时间可能有多个内核执行命令在执行，因此内核其实像多进程多线程编程一样也需要一些同步机制来同步各执行单元对共享数据的访问。尤其是在多核CPU系统上，更需要一些同步机制来同步不同处理器上的执行单元对共享的数据的访问。在主流的Linux内核中包含了几乎所有现代的操作系统具有的同步机制，这些同步机制包括：

Atomic(原子操作): 所谓原子操作，就是该操作绝不会在执行完毕前被任何其他任务或事件打断，也就说，它的最小的执行单位，不可能有比它更小的执行单位。
Mutex(互斥量): 互斥锁主要用于实现内核中的互斥访问功能。内核互斥锁是在原子API之上实现的，但这对于内核用户是不可见的。对它的访问必须遵循一些规则：同一时间只能有一个任务持有互斥锁，而且只有这个任务可以对互斥锁进行解锁。互斥锁不能进行递归锁定或解锁。一个互斥锁对象必须通过其API初始化，而不能使用memset或复制初始化。一个任务在持有互斥锁的时候是不能结束的。互斥锁所使用的内存区域是不能被释放的。使用中的互斥锁是不能被重新初始化的。并且互斥锁不能用于中断上下文。但是互斥锁比当前的内核信号量选项更快，并且更加紧凑，因此如果它们满足您的需求，那么它们将是您明智的选择。但是，对于互斥锁而言，如果资源已经被占用，其它的资源申请进程只能进入sleep状态。
Spinlock(自旋锁): 自旋锁与互斥锁有点类似，只是自旋锁不会引起调用者睡眠，如果自旋锁已经被别的执行单元保持，调用者就一直循环在那里看是否该自旋锁的保持者已经释放了锁，”自旋”一词就是因此而得名。由于自旋锁使用者一般保持锁时间非常短，因此选择自旋而不是睡眠是非常必要的，自旋锁的效率远高于互斥锁。
rwlock(读写锁): 读写锁实际是一种特殊的自旋锁，它把对共享资源的访问者划分成读者和写者，读者只对共享资源进行读访问，写者则需要对共享资源进行写操作。这种锁相对于自旋锁而言，能提高并发性，因为在多处理器系统中，它允许同时有多个读者来访问共享资源，最大可能的读者数为实际的逻辑CPU数。写者是排他性的，一个读写锁同时只能有一个写者或多个读者（与CPU数相关），但不能同时既有读者又有写者。
semaphore(信号量): 信号量在创建时需要设置一个初始值，表示同时可以有几个任务可以访问该信号量保护的共享资源，初始值为1就变成互斥锁（Mutex），即同时只能有一个任务可以访问信号量保护的共享资源。一个任务要想访问共享资源，首先必须得到信号量，获取信号量的操作将把信号量的值减1，若当前信号量的值为负数，表明无法获得信号量，该任务必须挂起在该信号量的等待队列等待该信号量可用；若当前信号量的值为非负数，表示可以获得信号量，因而可以立刻访问被该信号量保护的共享资源。当任务访问完被信号量保护的共享资源后，必须释放信号量，释放信号量通过把信号量的值加1实现，如果信号量的值为非正数，表明有任务等待当前信号量，因此它也唤醒所有等待该信号量的任务。
rw_semaphore(读写信号量): 读写信号量对访问者进行了细分，或者为读者，或者为写者，读者在保持读写信号量期间只能对该读写信号量保护的共享资源进行读访问，如果一个任务除了需要读，可能还需要写，那么它必须被归类为写者，它在对共享资源访问之前必须先获得写者身份，写者在发现自己不需要写访问的情况下可以降级为读者。
条件变量
seqlock(顺序锁): 顺序锁也是对读写锁的一种优化，对于顺序锁，读者绝不会被写者阻塞，也就说，读者可以在写者对被顺序锁保护的共享资源进行写操作时仍然可以继续读，而不必等待写者完成写操作，写者也不需要等待所有读者完成读操作才去进行写操作。但是，写者与写者之间仍然是互斥的，即如果有写者在进行写操作，其他写者必须自旋在那里，直到写者释放了顺序锁。
BKL(大内核锁): 大内核锁本质上也是自旋锁，但是它又不同于自旋锁，自旋锁是不可以递归获得锁的，因为那样会导致死锁。但大内核锁可以递归获得锁。大内核锁用于保护整个内核，而自旋锁用于保护非常特定的某一共享资源。进程保持大内核锁时可以发生调度，具体实现是：在执行schedule时，schedule将检查进程是否拥有大内核锁，如果有，它将被释放，以致于其它的进程能够获得该锁，而当轮到该进程运行时，再让它重新获得大内核锁。注意在保持自旋锁期间是不允许发生调度的。
brlock(大读者锁): 大读者锁是读写锁的高性能版，读者可以非常快地获得锁，但写者获得锁的开销比较大。大读者锁只存在于2.4内核中，在2.6中已经没有这种锁（提醒读者特别注意）。它们的使用与读写锁的使用类似，只是所有的大读者锁都是事先已经定义好的。这种锁适合于读多写少的情况，它在这种情况下远好于读写锁。
RCU(Read-Copy Update): 顾名思义就是读-拷贝修改，它是基于其原理命名的。对于被RCU保护的共享数据结构，读者不需要获得任何锁就可以访问它，但写者在访问它时首先拷贝一个副本，然后对副本进行修改，最后使用一个回调（callback）机制在适当的时机把指向原来数据的指针重新指向新的被修改的数据。这个时机就是所有引用该数据的CPU都退出对共享数据的操作。

Java锁的特点

在很多书写Java并发的文章中，我们经常看到有这些锁的概念。这些概念中，并不全指锁的状态，有的是指所得特性，有的是指所得设计。本文仅仅简要叙述锁的概念，不过多涉及Java锁的实现，这部分内容放在《Javaer不得不说的Java“锁”事》一文中。

公平锁 / 非公平锁：按照多线程申请资源是否按照顺序来获取锁。
可重入锁 / 不可重入锁：广义上的可重入锁指的是可重复可递归调用的锁，在外层使用锁之后，在内层仍然可以使用，并且不发生死锁（前提得是同一个对象或者class），这样的锁就叫做可重入锁，否则就叫不可重入锁。 ReentrantLock和 synchronized都是可重入锁。
独享锁 / 共享锁：
- 独享锁该锁每一次只能被一个线程所持有。
- 共享锁该锁可被多个线程共有，典型的就是ReentrantReadWriteLock里的读锁，它的读锁是可以被共享的，但是它的写锁确每次只能被独占。
互斥锁 / 读写锁：
- 在访问共享资源之前对进行加锁操作，在访问完成之后进行解锁操作。加锁后，任何其他试图再次加锁的线程会被阻塞，直到当前进程解锁。这是互斥锁。
- 读写锁既是互斥锁，又是共享锁，read模式是共享，write是互斥(排它锁)的。
乐观锁 / 悲观锁：
- 悲观锁 总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁， Java中 synchronized和 ReentrantLock等独占锁就是悲观锁思想的实现。
- 乐观锁 总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号机制和CAS算法实现。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库提供的类似于 write_condition机制，其实都是提供的乐观锁。在 Java中 java.util.concurrent.atomic包下面的原子变量类就是使用了乐观锁的一种实现方式CAS实现的。
分段锁：分段锁其实是一种锁的设计，并不是具体的一种锁，对于 ConcurrentHashMap而言，其并发的实现就是通过分段锁的形式来实现高效的并发操作。
偏向锁 / 轻量级锁 / 重量级锁：
- 偏向锁 是指一段同步代码一直被一个线程所访问，那么该线程会自动获取锁。降低获取锁的代价。
- 轻量级锁 是指当锁是偏向锁的时候，被另一个线程所访问，偏向锁就会升级为轻量级锁，其他线程会通过自旋的形式尝试获取锁，不会阻塞，提高性能。
- 重量级锁 是指当锁为轻量级锁的时候，另一个线程虽然是自旋，但自旋不会一直持续下去，当自旋一定次数的时候，还没有获取到锁，就会进入阻塞，该锁膨胀为重量级锁。重量级锁会让其他申请的线程进入阻塞，性能降低。
自旋锁：是指当一个线程在获取锁的时候，如果锁已经被其它线程获取，那么该线程将循环等待，然后不断的判断锁是否能够被成功获取，直到获取到锁才会退出循环。