仍然需要IT专业人员担任关键角色

删除成功返回1，那么其他的服务器就可以继续重复上面的步骤去设置这个key，以达到获取锁的目的。

当然以上的操作是在redis客户端直接进行的，通过程序调用的话，肯定就不能这么写，比如java 就需要通过jedis 去调用，但是整个处理逻辑基本都是一样的

通过上面的方式，我们好像是解决了分布式锁的问题，但是想想还有没有什么问题呢？？

对，问题还是有的，可能会有死锁的问题发生，比如服务器1设置完之后，获取了锁之后，忽然发生了宕机。
 

3，分布式锁的实现有哪些？

说到分布式锁的实现，还是有很多的，有数据库方式的，有redis分布式锁，有zookeeper分布式锁等等

我们如果采用redis作为分布式锁，那么上图中负“责红包的妹子（服务）”，就可以替换成redis，请自行脑补。

3.1，为什么redis可以实现分布式锁？

首先redis是单线程的，这里的单线程指的是网络请求模块使用了一个线程（所以不需考虑并发安全性），即一个线程处理所有网络请求，其他模块仍用了多个线程。

在实际的操作中过程大致是这样子的：

服务器1要去访问发红包的妹子，也就是redis，那么他会在redis中通过"setnx key value" 操作设置一个key 进去，value是啥不重要，重要的是要有一个key，也就是一个标记，而且这个key你爱叫啥叫啥，只要所有的服务器设置的key相同就可以。

假设我们设置一个，如下图
 

2，分布式锁怎么去处理？

那么为了解决这个问题，让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个服务器谁拿到锁（抢到绣球），谁就进来和我谈，我给你分，其他人就等着去吧

经过上面的分布式锁的处理后，马云爸爸终于放心了，决定给红包团队每人加一个鸡腿。

简化的结构图如下：

（编辑：新余站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!