通俗讲解分布式锁，这次你一定能懂！

首先分布式锁和我们平常讲到的锁原理基本一样，目的就是确保，在多个线程并发时，只有一个线程在同一刻操作这个业务或者说方法、变量。

在一个进程中，也就是一个jvm 或者说应用中，我们很容易去处理控制，在jdk java.util 并发包中已经为我们提供了这些方法去加锁， 比如synchronized 关键字 或者Lock 锁，都可以处理。

但是我们现在的应用程序如果只部署一台服务器，那并发量是很差的，如果同时有上万的请求那么很有可能造成服务器压力过大，而瘫痪。

想想双十一 和 三十晚上十点分支付宝红包等业务场景，自然需要用到多台服务器去同时处理这些业务，那么这些服务可能会有上百台同时处理，

但是请我们大家想一想，如果有100台服务器 要处理分红包的业务，现在假设有1亿的红包，1千万个人分，金额随机，那么这个业务场景下是不是必须确保这1千万个人最后分的红包金额总和等于1亿。

如果处理不好，每人分到100万，那马云爸爸估计大年初一，就得宣布破产了~~

一、常规锁会造成什么情况？

首先说一下我们为什么要搞集群，简单理解就是，需求量（请求并发量）变大了，一个工人处理能力有限，那就多招一些工人来一起处理。

假设1千万个请求平均分配到100台服务器上，每个服务器 接收10w的请求（这10w个请求并不是在同一秒中来的，可能是在1,2个小时内，可以联想下我们三十晚上开红包，等到10.20开始，有的人立马开了，有的人是不是等到12点了才想起来~）

那这样的话，平均到每一秒上的请求也就不到1千个，这种压力一般的服务器还是可以承受的。

第一个请求到来后，是不是需要在1亿里面给他分一部分钱，金额随机，假设第一个人分到了100，那是不是要在这1亿中减去100块，剩下99999900 块~

第二个用户再来分，金额随机，这次分200块，那是不是就需要在剩下的99999900块中再减去200块，剩下99999700 块。

等到第10w个用户来，一看还有1000w，那这1000w全成他的了。

等于是在每个服务器中去分1亿，也就是10w个用户分了一个亿，最后总计有100个服务器，要分100亿。

如果真这样了，虽说马云爸爸不会破产（据最新统计马云有2300亿人民币），那分红包的开发项目组，以及产品经理，可以GG了~

简化结构图如下：

二、分布式锁怎么去处理？

那么为了解决这个问题，让1000万用户只分1亿，而不是100亿，