浅谈Java中的分布式锁（通俗易懂）

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

在一个进程中，也就是一个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了~

简化结构图如下：

图片

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