一、背景

描述需求的相关信息

现如今，几乎所有的互联网公司，都在将自己的应用架构服务化，将原来存在于一个大而全应用上的功能，拆分成多个小而多的应用，基于此，可以将一些公用的部分给拆出来，给大家来使用。

总结一下：

• 微服务的发展
• 架构的发展

技术发展的同时，也出现了几个不同的技术问题

• 如何保证多个相同作用的机器只对一份数据进行处理？
• 如何保证多台机器的处理如果因为发生错误而造成的统一是回滚？

• 如何在多个应用之间保证id的一致性

当然，下面的这个系列，我们讨论的还是分布式锁的相关内容，上面是对这个技术的一个引申。

二、历史信息

• 搜集了很久，没有找到分布式锁的缘由，是哪个公司或哪个论文中率先提出

三、progress review

描述需求的体验方式

我们先来看一下，如果没有分布式锁，会有一些什么样的问题出现

场景

描述体验需求的场景

• cluster1从公共资源池中取得key=1
• cluster2也从公共资源池中取得key=1

• 两个机器同时对取到的key进行处理，导致出现并发问题

三、解决的问题

从上面的问题中，可以看到，在没有锁的情况下，会出现并发脏数据问题，而分布式锁的出现，就是为了解决这样的一个问题

• 效率性。多个相同工作的机器不应该同时对同一份资源进行处理
• 正确性。多个机器同时对一份资源进行处理的时候，出现的错误性问题

概念性

实际上，分布式锁的各个功能特性都可以类比单机锁，只不过单机锁解决的是进程内线程间的问题，而分布式锁，则是解决的进程间的一个问题

定义

锁=资源+并发控制+锁能力

特点

• 互斥性
• 可重入性

• 锁超时
• 高效、高可用

• 支持阻塞和非阻塞
• 支持公平锁和非公平锁

四、常见的实现方式

描述功能的体验步骤

基于异步复制的分布式系统

• MySQL
• tair

• redis

存在数据丢失（丢锁）的风险，不够安全，往往通过TTL的机制承担细粒度的锁服务，适用于对时间很敏感，期望设置一个较短的有效期，执行短期任务，丢锁对业务影响相对可控的服务

基于paxos协议的分布式一致性系统

• zk
• consul

• etcd

通过分布式一致性保证数据的多副本，数据安全性高，往往会通过租约的机制承担粗粒度的锁服务，适用于对安全性很敏感，希望长期持有锁，不期望发生丢锁的现象的服务

四、重点机制

互斥性

可用性

高效率

可重入

锁超时

五、可选特性

阻塞与非阻塞

公平与非公平

六、总结

整个分布式锁其实和单机锁概念上是基本一致的，只是在不同的领域有着不同的挑战，后续会慢慢渗入到各个重点机制是如何实现的。