锁是操作系统的基本原语，它是用于并发控制的，能够确保在多CPU、多个线程的环境中，某一个时间点上，只能有一个现成进入临界区代码，从而保证临界区中操作数据的一致性。
为什么需要分布式锁？
在我们日常的研发工作中，经常会在进程内部缓存一些状态信息，通过锁可以很方便地控制、修改这些内部状态信息的临界区代码，确保不会出现多个线程同时修改临界区的资源这种情况，防止异常问题的发生。所以，锁是我们研发工作中一个非常重要的工具。
我们将锁的定义推广到分布式系统的场景中，也是依然成立的。只不过锁控制的对象从一个进程内部的多个线程，变成了分布式场景下的多个进程，同时，临界区的资源也从进程内多个线程共享的资源，变成了分布式系统内部共享的中心存储上的资源。但是，锁的定义在本质上没有任何的改变，只有持有锁的线程或进程才能执行临界区的代码。
分布式锁是一个跨进程的锁，是一个更高维度的锁。我们在进程内部碰到的临界区问题，在分布式系统中依然存在，我们需要通过分布式锁，来解决分布式系统中的多进程的临界区问题。
怎么实现分布式锁？
在分布式系统中，锁可以分为三类：
- 进程内部的锁
- 跨进程、跨机器之间的分布式锁
- 同一台机器上多进程之间的锁
进程内的锁，是操作系统直接提供的，它本质上是内存中的一个整数，用不同的数值表示不同的状态，比如用 0 表示空闲状态。加锁时，判断锁是否空闲，如果空闲，修改为加锁态 1，并且返回成功，如果已经是加锁状态，则返回失败，而解锁时，则将锁状态修改为空闲状态 0。整个加锁或者解锁的过程，操作系统保证它的原子性。
对于同一台机器上的多进程之间，我们可以直接通过操作系统的锁来实现，只不过由于协调的是多个进程，需要将锁存放在所有进程都可以访问的共享内存中，所有进程通过共享内存中的锁来进行加锁和解锁。
跨进程、跨机器之间的分布式锁的实现也是同样的思路，通过一个状态来表示加锁和解锁，只不过要让所有需要锁的服务，都能访问到状态存放的位置。在分布式系统中，一个非常自然的方案就是，将锁的状态信息存放在一个存储服务，即锁服务中，其他的服务再通过网络去访问锁服务来修改状态信息，最后进行加锁和解锁。
一个完备的分布式锁，需要具备以下几个特性：
- 互斥
- 超时机制
- 完备的锁接口
- 可重入性
- 公平性
分布式锁的挑战
在分布式系统中，由于部分失败和异步网络的问题，分布式锁会面临正确性、高可用和高性能这三点的权衡问题的挑战。
分布式锁的正确性
对于进程内的锁，如果一个线程持有锁，只要它不释放，就只有它能操作临界区的资源。同时，因为进程内锁的场景中，不会出现部分失败的情况，所以在它崩溃时，虽然没有去做解锁操作，但是整个进程都会崩溃，不会出现死锁的情况。
进程内锁的解锁操作是进程内部的函数调用，这个过程是同步的。不论是硬件或者其他方面的原因，只要发起解锁操作就一定会成功，如果出现失败的情况，整个进程或者机器都会挂掉。所以，因为整体失败和同步通信这两点，我们可以保证进程内的锁有绝对的正确性。
我们再来用同样的思路，讨论一下同一台机器上多进程锁的正确性问题。在这个情况下，由于锁是存放在多进程的共享内存中，所以进程和锁之间的通信，依然是同步的函数调用，不会出现解锁后信息丢失，导致死锁的情况。但是，因为是多个进程来使用锁，所以会出现一个进程获取锁后崩溃，导致死锁的情况，这个就是部分失败导致的。
锁服务在进程加锁成功后，会设置一个超时时间，如果进程持有锁超时后，将锁再颁发给其他的进程，就会导致一把锁被两个进程持有的情况出现，使锁的互斥语义被破坏。那么出现这个问题的根本原因是超时后，锁的服务自动释放锁的操作
分布式锁的权衡
一般来说，一个分布式锁服务，它的正确性要求越高，性能可能就会越低。我们可以在成本可接受的范围内，提供性能最好的分布式锁服务。
此文章为极客时间4月份Day07学习笔记，内容来自《深入浅出分布式技术原理》课程。
