分布式锁实现与原理探究:介绍总结
文章目录
- 1. 分布式锁用来做什么？
- 2. 分布式锁的特征
- 3. 分布式锁的实现方案
本文参考：
- 分布式锁实现原理与最佳实践 - 阿里
- 聊聊分布式锁 - 字节
- Redis、ZooKeeper、Etcd，谁有最好用的分布式锁？ - 腾讯
- 分布式锁介绍
- https://juejin.cn/book/7018393458620497934
- How to do distributed locking
这系列文章我想聊下"分布式锁"这个老生常谈的话题，互联网项目的开发中也或多或少会用到，各类博客以及专题小册子看了也不少，但是总感觉最终自己留下的东西不多，或者说是还没有那么地自成体系。因此就想从实现原理、实现方案等多个角度，真的去把这个知识学透，即使一时半会达不到融汇贯通的效果，至少也能够先将知识体系搭建起来。
整体的文章结构我想采取和先前的文章《线程池源码解析》不同的格式，分子专题的将分布式锁的实现方式讲透，每个子专题一篇文章，而非一个汇总文章。整体大致会有如下几篇文章：分布式锁实现与原理探究：介绍总结、分布式锁 Redis 实现方式、分布式锁 Zookeeper 实现方式、分布式锁 MySQL 实现方式
1. 分布式锁用来做什么？
主要是看的 Martin 老爷子的文章《How to do distributed locking》，在分布式系统中，锁主要有两个用途：效率 efficiency 以及正确性 correctness，并且为了区分这两个用途，可以关注下加锁失败的场景下，各自会产生怎样的后果。
-
效率
协调各个客户端避免做重复的工作。即使锁失效了，只是把某些操作多做了一遍而已，不会产生其他的不良后果。比方说一个用户可能会重复收到两次邮箱提醒，可能会给用户带来不便，当然这取决于业务应用的容忍度。
-
正确性
避免并发的进程或线程互相干扰。在这种场景下，任何场景下都不允许锁失效的情况发生，因为一旦发生，就意味着文件损坏、数据丢失、永久性的数据不一致，最终导致非常严重的后果。
总结理解下来，分布式锁本质是为了让代码块“串行化”，那么在串行化的代码块中加入定制的逻辑，就可以实现效率上的“做一次”或者是正确性上的”避免并发问题“。
2. 分布式锁的特征
汇总了阿里、字节、腾讯、Guide 的文章，带上一点自己的思考，总结出来分布式锁具有如下特性，才算是一把“好的分布式锁”：
- 互斥：任意时刻，锁只能被一个线程、进程持有。
- 防死锁：引入锁自动超时机制，避免客户端线程暂停或者宕机，导致锁无法释放。同时在业务上，也得保证业务逻辑异常执行的场景下，会去兜底释放锁，比方 Java 的 finally 块无论如何执行锁释放。
- 可重入：一个节点获取锁以后，还能继续获取锁，也能够避免死锁
- 高性能：获取锁和释放锁应该在短时间内完成，不影响系统 RT
- 高可用：锁服务具有容错性，能避免单点故障。一种是锁服务本身就是个集群，能够自动进行故障切换，类似 Redis、Zookeeper 主从集群。一种是客户端向多个独立的锁服务发起请求（RedLock），其中一个锁服务出现故障，仍然可以从其他锁服务上读取到锁信息。除此以外，还应该对客户端提出要求，即使客户端释放锁的逻辑出问题，锁最终还是应该被释放，不会影响其他线程对共享资源的访问，这通常是客户端加锁的时候，通过设定 TTL 超时时间实现的。
一般来说，一把分布式锁的高可用要求越高，性能表现就会更低，因此这需要我们实际业务中去取舍，也是符合 CAP 理论的。
3. 分布式锁的实现方案
常见分布式锁实现如下：
- 基于关系型数据库比如 MySQL
- 基于分布式协调任务比如 Zookeeper
- 基于分布式键值系统比如 Redis、Etcd
后面会继续出文章分别实现三种分布式锁方案，并且对比不同方案之间的优缺点。