每秒上千订单场景下，如何对分布式锁的并发能力进行优化？

起因

这一次的话题来源于我朋友的一次面试经历，在面试国内某个不错的电商公司时，面试官给他出了一个场景题：假如下单时，用分布式锁来防止库存超卖，但是是每秒上千订单的高并发场景，如何对分布式锁进行高并发优化来应对这样一个场景？

他说因为没做过什么思路，所以没有答上来;我听到后觉得还是蛮有意思的,因为如果是我作为面试官来问,我应该给的范围会更大些.

例如,让面试候选人们讲一下在同样场景下,给出解决库存超卖的各种方案,讲出优缺点以及实践,再才去聊到分布式锁这个话题.

解决库存超卖问题还是有很多技术解决方案的,比如分布式锁、悲观锁、乐观锁、Redis 原子操作等等

既然面试官限定了解决方法，那就是使用分布式锁来解决，那么他的目的就是为了问一个点：在高并发场景下如何优化分布式锁的并发性能。

分布式锁这个东西保证了数据的准确性，所以面试官从这个角度问是可以接受的。

所以今天我将带大家了解面试官经常问的分布式锁等高频面试问题。

什么是分布式锁

在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。那具体什么是分布式锁，分布式锁应用在哪些业务场景、如何来实现分布式锁呢？

为什么要使用它

我们在开发应用的时候，如果需要对某一个共享变量进行多线程同步访问的时候，可以使用我们学到的锁进行处理，并且可以完美的运行，毫无 Bug！注意这是单机应用，后来业务发展，需要做集群，一个应用需要部署到几台机器上然后做负载均衡，大致如下图：

上图可以看到，变量 A 存在三个服务器内存中（这个变量 A 主要体现是在一个类中的一个成员变量，是一个有状态的对象），如果不加任何控制的话，变量 A 同时都会在分配一块内存，三个请求发过来同时对这个变量操作，显然结果是不对的！即使不是同时发过来，三个请求分别操作三个不同内存区域的数据，变量 A 之间不存在共享，也不具有可见性，处理的结果也是不对的！如果我们业务中确实存在这个场景的话，我们就需要一种方法解决这个问题！为了保证一个方法或属性在高并发情况下的同一时间只能被同一个线程执行，在传统单体应用单机部署的情况下，可以使用并发处理相关的功能进行互斥控制。但是，随着业务发展的需要，原单体单机部署的系统被演化成分布式集群系统后，由于分布式系统多线程、多进程并且分布在不同机器上，这将使原单机部署情况下的并发控制锁策略失效，单纯的应用并不能提供分布式锁的能力。为了解决这个问题就需要一种跨机器的互斥机制来控制共享资源的访问，这就是分布式锁要解决的问题！

面试现状

现在面试，一般都会聊聊分布式系统这块的东西。通常面试官都会从服务框架（Spring Cloud、Dubbo）聊起，一路聊到分布式事务、分布式锁、ZooKeeper 等知识。

说实话，如果在公司里落地生产环境用分布式锁的时候，一定是会用开源类库的，比如 Redis 分布式锁，一般就是用 Redisson 框架就好了，非常的简便易用。

有话说

了解到有很多人对于面试官问的这个分布式很感兴趣，没有一个正确的指导去学习，那么我就把我深藏已久的学习秘籍告诉给大家！希望大家能够彻底解决这个难题。

接下来我将分享这一份关于《分布式核心原理解析》的笔记，如果你感兴趣的话就接着往下看吧！

分布式的起源

与其直接用些抽象、晦涩的技术名词去给分布式下一个定义，还不如从理解分布式的发展驱

动因素开始，我们一起去探寻它的本质，自然而然地也就清楚它的定义了

分布式的系统指标

从分布式技术的起源可以看出，分布式系统的出现就是为了用廉价的、普通的机器解决单个

计算机处理复杂、大规模数据和任务时存在的性能问题、资源瓶颈问题，以及可用性和可扩

展性问题。换句话说，分布式的目的是用更多的机器，处理更多的数据和更复杂的任务。

由此可以看出，性能、资源、可用性和可扩展性是分布式系统的重要指标。没错，它们就是

分布式系统的“三围”。

分布式的协调与同步

想象一下，你正在一家餐厅使用自助咖啡机泡制咖啡，突然有个人过来挪走了你的杯子，开

始泡制他自己的咖啡。你耐着性子等他操作完，继续泡制自己的咖啡。结果你开始没多久，

他又回来中断了你泡制咖啡的过程。相信要不了几个回合，你和他就会上演一场“有你没

我，有我没你”的格斗了。

这样现实的问题也同样存在于分布式世界。就像我们使用自助咖啡机时不希望被打扰一样，

对于同一共享资源，一个程序正在使用的时候也不希望被其他程序打扰。这，就要求同一时

刻只能有一个程序能够访问这种资源。

分布式资源管理与负载调度

云这个话题对我们来说已经非常熟悉了。可以说，云在我们的生活中无处不在，比如我们平

时看的视频通常就是放在云上的。当我们要播放一段视频时，请求会先转发到云上，从云上

下载数据到本地，然后播放。在这里，你肯定会疑惑，云上资源那么丰富吗，可以存放这么

多东西吗？

云上的资源确实丰富，因为它可以尽可能地把更多的服务器组织起来，作为一个统一的资

源，为多个用户提供服务。这里的重点是，把多个服务器管理起来，作为一个统一的资源提

供服务。而如何组织，就是分布式体系结构的范畴了。

分布式系统中的集中式架构

Borg 是 Google 公司内部使用的集群管理系统，既可以执行长服务，也可以执行批处理任

务，是一个具有强大功能的、复杂的集群管理系统。

Kubernetes 是 Borg 的简化开源版，是一个正在兴起的集群管理系统。Mesos 和

Kubernetes 都是为帮助应用程序在群集环境中运行而创建的，Kubernetes 更加专注于运

行容器群集，具有更多功能。

Mesos 是非常典型的开源集群管理系统。在 Mesos 之上，可以搭载诸如 Spark、Hadoop

等框架，甚至可以在 Mesos 上集成 Kubernetes，扩展性强。

可以发现，这三种集群管理系统虽然具有不同的功能组件，但整体框架采用的都是集中式架

构。因此，你只要理解了一个集群管理系统的架构，再去理解其他集中式的集群管理架构就

会很容易了。

分布式计算技术

所谓分而治之，就是将一个复杂的、难以直接解决的大问题，分割成一些规模较小的、可以

直接求解的子问题，这些子问题互相独立且与原问题形式相同，递归地解这些子问题，然后

将子问题的解合并以后就是原问题的解。

Stream 工作原理

在介绍流计算的工作原理时，我首先通过一个流程图，与你介绍了它的 3 个步骤，即提交

流式计算作业、加载流式数据进行流计算和持续输出计算结果。

然后，我以流计算开源框架中的 Storm 为例，与你讲述了 Storm 的核心组件以及通过

Spout 和 Bolt 构建有向无环图代表流计算逻辑，以实现流计算，以加深你对流计算原理的

理解。

总结

看完这篇文章，你是否对分布式有了一个大致的了解呢？

希望简单的解说能够帮助到大家！

由于篇幅有限，笔记内容无法全部写出，如想要我这份《分布式核心原理解析》笔记的全部内容

免费获取，需要的小伙伴可以+ VX: mxk6072