史上最通俗分布式锁解读 _分布式锁

首先，分布式锁和我们平常讲到的锁原理基本一样，目的就是确保在多个线程并发时，只有一个线程在同一刻操作这个业务或者说方法、变量。
在一个进程中，也就是一个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亿，这个时候分布式锁就派上用处了。
【史上最通俗分布式锁解读】分布式锁可以把整个集群就当作是一个应用一样去处理，那么也就需要这个锁独立于每一个服务之外，而不是在服务里面。
假设第一个服务器接收到用户1的请求后，不能只在自己的应用中去判断还有多少钱可以分了，而需要去外部请求专门负责管理这1亿红包的人（服务），问他：哎，我这里要分100块，给我100 。
管理红包的妹子（服务）一看，还有1个亿，那好，给你100块，然后剩下99999900块。
第二个请求到来后，被服务器2获取，继续去询问，管理红包的妹子，我这边要分10块，管理红包的妹子先查了下还有99999900，那就说：好，给你10块。那就剩下99999890块。
等到第1000w个请求到来后，服务器100拿到请求，继续去询问，管理红包的妹子，我要100，妹子翻了翻白眼，对你说，就剩1块了，爱要不要，那这个时候就只能给你1块了（1块也是钱啊，买根辣条还是可以的）。
这些请求编号1,2不代表执行的先后顺序，正式的场景下，应该是100台服务器每个服务器持有一个请求去访问负责管理红包的妹子（服务），那在管红包的妹子那里同时会接收到100个请求，这个时候就需要在负责红包的妹子那里加个锁就可以了（抛绣球），你们100个服务器谁拿到锁（抢到绣球），谁就进来和我谈，我给你分，其他人就等着去吧。
经过上面的分布式锁的处理后，马云爸爸终于放心了，决定给红包团队每人加一个鸡腿。
简化的结构图如下：