删除sybase里面的锁_史上最通俗分布式锁解读

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

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

但是我们现在的应用程序如果只部署一台服务器&＃xff0c;那并发量是很差的&＃xff0c;如果同时有上万的请求&＃xff0c;很有可能造成服务器压力过大而瘫痪。想想双十一和大年三十晚上十点&＃xff0c;瓜分支付宝红包等业务场景&＃xff0c;自然需要用到多台服务器去同时处理这些业务&＃xff0c;这些服务可能会有上百台同时处理。

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

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

一、常规锁会造成什么情况&＃xff1f;

首先说一下我们为什么要搞集群。

简单理解就是&＃xff0c;需求量(请求并发量)变大了&＃xff0c;一个工人处理能力有限&＃xff0c;那就多招一些工人来一起处理。

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

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

• 第一个用户来分&＃xff0c;请求到来后&＃xff0c;需要在1亿里面给他分一部分钱&＃xff0c;金额随机&＃xff0c;假设第一个人分到了100&＃xff0c;那就要在这1亿中减去100块&＃xff0c;剩下99999900块~
• 第二个用户再来分&＃xff0c;金额随机&＃xff0c;这次分200块&＃xff0c;那就需要在剩下的99999900块中再减去200块&＃xff0c;剩下99999700块。
• 等到第10w个用户来&＃xff0c;一看还有1000w&＃xff0c;那这1000w全成他的了。

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

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

简化结构图如下&＃xff1a;

二、分布式锁怎么去处理&＃xff1f;

那么为了解决这个问题&＃xff0c;让1000万用户只分1亿&＃xff0c;而不是100亿&＃xff0c;这个时候分布式锁就派上用处了。

分布式锁可以把整个集群就当作是一个应用一样去处理&＃xff0c;那么也就需要这个锁独立于每一个服务之外&＃xff0c;而不是在服务里面。

假设第一个服务器接收到用户1的请求后&＃xff0c;不能只在自己的应用中去判断还有多少钱可以分了&＃xff0c;而需要去外部请求专门负责管理这1亿红包的人(服务)&＃xff0c;问他&＃xff1a;哎&＃xff0c;我这里要分100块&＃xff0c;给我100。

管理红包的妹子(服务)一看&＃xff0c;还有1个亿&＃xff0c;那好&＃xff0c;给你100块&＃xff0c;然后剩下99999900块。

第二个请求到来后&＃xff0c;被服务器2获取&＃xff0c;继续去询问&＃xff0c;管理红包的妹子&＃xff0c;我这边要分10块&＃xff0c;管理红包的妹子先查了下还有99999900&＃xff0c;那就说&＃xff1a;好&＃xff0c;给你10块。那就剩下99999890块。

等到第1000w个请求到来后&＃xff0c;服务器100拿到请求&＃xff0c;继续去询问&＃xff0c;管理红包的妹子&＃xff0c;我要100&＃xff0c;妹子翻了翻白眼&＃xff0c;对你说&＃xff0c;就剩1块了&＃xff0c;爱要不要&＃xff0c;那这个时候就只能给你1块了(1块也是钱啊&＃xff0c;买根辣条还是可以的)。

这些请求编号1,2不代表执行的先后顺序&＃xff0c;正式的场景下&＃xff0c;应该是100台服务器每个服务器持有一个请求去访问负责管理红包的妹子(服务)&＃xff0c;那在管红包的妹子那里同时会接收到100个请求&＃xff0c;这个时候就需要在负责红包的妹子那里加个锁就可以了(抛绣球)&＃xff0c;你们100个服务器谁拿到锁(抢到绣球)&＃xff0c;谁就进来和我谈&＃xff0c;我给你分&＃xff0c;其他人就等着去吧。

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

简化的结构图如下&＃xff1a;

三、分布式锁的实现有哪些&＃xff1f;

说到分布式锁的实现&＃xff0c;还是有很多的&＃xff0c;有数据库方式的&＃xff0c;有Redis分布式锁&＃xff0c;有Zookeeper分布式锁等等。

我们如果采用Redis作为分布式锁&＃xff0c;那么上图中负“责红包的妹子(服务)”&＃xff0c;就可以替换成Redis&＃xff0c;请自行脑补。

1、为什么Redis可以实现分布式锁&＃xff1f;

首先Redis是单线程的&＃xff0c;这里的单线程指的是网络请求模块使用了一个线程(所以不需考虑并发安全性)&＃xff0c;即一个线程处理所有网络请求&＃xff0c;其他模块仍用了多个线程。

在实际的操作中过程大致是这样子的&＃xff1a;

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

假设我们设置一个&＃xff0c;如下图&＃xff1a;

那么我们可以看到会返回一个1&＃xff0c;那就代表了成功。

如果再来一个请求去设置同样的key&＃xff0c;如下图&＃xff1a;

这个时候会返回0&＃xff0c;那就代表失败了。

那么我们就可以通过这个操作去判断是不是当前可以拿到锁&＃xff0c;或者说可以去访问“负责发红包的妹子”&＃xff0c;如果返回1&＃xff0c;那我就开始去执行后面的逻辑&＃xff0c;如果返回0&＃xff0c;那就说明已经被人占用了&＃xff0c;我就要继续等待。

当服务器1拿到锁之后&＃xff0c;进行了业务处理&＃xff0c;完成后&＃xff0c;还需要释放锁&＃xff0c;如下图所示&＃xff1a;

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

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

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

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

那后续的删除key操作就没法执行&＃xff0c;这个key会一直在Redis中存在&＃xff0c;其他服务器每次去检查&＃xff0c;都会返回0&＃xff0c;他们都会认为有人在使用锁&＃xff0c;我需要等。

为了解决这个死锁的问题&＃xff0c;我们就需要给key设置有效期了。

设置的方式有2种&＃xff1a;

• 第一种就是在set完key之后&＃xff0c;直接设置key的有效期 "expire key timeout" &＃xff0c;为key设置一个超时时间&＃xff0c;单位为second&＃xff0c;超过这个时间锁会自动释放&＃xff0c;避免死锁。

这种方式相当于&＃xff0c;把锁持有的有效期&＃xff0c;交给了Redis去控制。如果时间到了&＃xff0c;你还没有给我删除key&＃xff0c;那Redis就直接给你删了&＃xff0c;其他服务器就可以继续去setnx获取锁。

• 第二种方式&＃xff0c;就是把删除key权利交给其他的服务器&＃xff0c;那这个时候就需要用到value值了&＃xff0c;比如服务器1&＃xff0c;设置了value也就是timeout为当前时间&＃43;1秒 &＃xff0c;这个时候服务器2通过get发现时间已经超过系统当前时间了&＃xff0c;那就说明服务器1没有释放锁&＃xff0c;服务器1可能出问题了&＃xff0c;服务器2就开始执行删除key操作&＃xff0c;并且继续执行setnx操作。

但是这块有一个问题&＃xff0c;也就是不光你服务器2可能会发现服务器1超时了&＃xff0c;服务器3也可能会发现&＃xff0c;如果刚好服务器2 setnx操作完成&＃xff0c;服务器3就接着删除&＃xff0c;是不是服务器3也可以setnx成功了&＃xff1f;

那就等于是服务器2和服务器3都拿到锁了&＃xff0c;那就问题大了。这个时候怎么办呢&＃xff1f;

这个时候需要用到“GETSET key value”命令了。这个命令的意思就是获取当前key的值&＃xff0c;并且设置新的值。

假设服务器2发现key过期了&＃xff0c;开始调用getset命令&＃xff0c;然后用获取的时间判断是否过期&＃xff0c;如果获取的时间仍然是过期的&＃xff0c;那就说明拿到锁了。

如果没有&＃xff0c;则说明在服务2执行getset之前&＃xff0c;服务器3可能也发现锁过期了&＃xff0c;并且在服务器2之前执行了getset操作&＃xff0c;重新设置了过期时间。

那么服务器2就需要放弃后续的操作&＃xff0c;继续等待服务器3释放锁或者去监测key的有效期是否过期。

这块其实有一个小问题是&＃xff0c;服务器3已经修改了有效期&＃xff0c;拿到锁之后&＃xff0c;服务器2也修改了有效期&＃xff0c;但是没能拿到锁&＃xff0c;但是这个有效期的时间已经被在服务器3的基础上有增加一些&＃xff0c;但是这种影响其实还是很小的&＃xff0c;几乎可以忽略不计。

2、为什么Zookeeper可实现分布式锁&＃xff1f;

百度百科是这么介绍的&＃xff1a;ZooKeeper是一个分布式的&＃xff0c;开放源码的分布式应用程序协调服务&＃xff0c;是Google的Chubby一个开源的实现&＃xff0c;是Hadoop和Hbase的重要组件。

那对于我们初次认识的人&＃xff0c;可以理解成ZooKeeper就像是我们的电脑文件系统&＃xff0c;我们可以在d盘中创建文件夹a&＃xff0c;并且可以继续在文件夹a中创建文件夹a1&＃xff0c;a2。

那我们的文件系统有什么特点&＃xff1f;那就是同一个目录下文件名称不能重复&＃xff0c;同样ZooKeeper也是这样的。

在ZooKeeper所有的节点&＃xff0c;也就是文件夹称作Znode&＃xff0c;而且这个Znode节点是可以存储数据的。

我们可以通过“ create /zkjjj nice”来创建一个节点&＃xff0c;这个命令就表示&＃xff0c;在跟目录下创建一个zkjjj的节点&＃xff0c;值是nice。同样这里的值&＃xff0c;和我在前面说的Redis中的一样&＃xff0c;没什么意义&＃xff0c;你随便给。

另外ZooKeeper可以创建4种类型的节点&＃xff0c;分别是&＃xff1a;

• 持久性节点
• 持久性顺序节点
• 临时性节点
• 临时性顺序节点

首先说下持久性节点和临时性节点的区别&＃xff1a;

• 持久性节点表示只要你创建了这个节点&＃xff0c;那不管你ZooKeeper的客户端是否断开连接&＃xff0c;ZooKeeper的服务端都会记录这个节点&＃xff1b;
• 临时性节点刚好相反&＃xff0c;一旦你ZooKeeper客户端断开了连接&＃xff0c;那ZooKeeper服务端就不再保存这个节点&＃xff1b;
• 顺便也说下顺序性节点&＃xff0c;顺序性节点是指&＃xff0c;在创建节点的时候&＃xff0c;ZooKeeper会自动给节点编号比如0000001&＃xff0c;0000002这种的。

Zookeeper有一个监听机制&＃xff0c;客户端注册监听它关心的目录节点&＃xff0c;当目录节点发生变化(数据改变、被删除、子目录节点增加删除)等&＃xff0c;Zookeeper会通知客户端。

四、在Zookeeper中如何加锁&＃xff1f;

下面我们继续结合我们上面的分红包场景&＃xff0c;描述下在Zookeeper中如何加锁。

假设服务器1&＃xff0c;创建了一个节点 /zkjjj&＃xff0c;成功了&＃xff0c;那服务器1就获取了锁&＃xff0c;服务器2再去创建相同的锁&＃xff0c;就会失败&＃xff0c;这个时候就只能监听这个节点的变化。

等到服务器1处理完业务&＃xff0c;删除了节点后&＃xff0c;他就会得到通知&＃xff0c;然后去创建同样的节点&＃xff0c;获取锁处理业务&＃xff0c;再删除节点&＃xff0c;后续的100台服务器与之类似。

注意这里的100台服务器并不是挨个去执行上面的创建节点的操作&＃xff0c;而是并发的&＃xff0c;当服务器1创建成功&＃xff0c;那么剩下的99个就都会注册监听这个节点&＃xff0c;等通知&＃xff0c;以此类推。

但是大家有没有注意到&＃xff0c;这里还是有问题的&＃xff0c;还是会有死锁的情况存在&＃xff0c;对不对&＃xff1f;

当服务器1创建了节点后挂了&＃xff0c;没能删除&＃xff0c;那其他99台服务器就会一直等通知&＃xff0c;那就完蛋了。。。

这个时候就需要用到临时性节点了&＃xff0c;我们前面说过了&＃xff0c;临时性节点的特点是客户端一旦断开&＃xff0c;就会丢失&＃xff0c;也就是当服务器1创建了节点后&＃xff0c;如果挂了&＃xff0c;那这个节点会自动被删除&＃xff0c;这样后续的其他服务器&＃xff0c;就可以继续去创建节点&＃xff0c;获取锁了。

但是我们可能还需要注意到一点&＃xff0c;就是惊群效应&＃xff1a;举一个很简单的例子&＃xff0c;当你往一群鸽子中间扔一块食物&＃xff0c;虽然最终只有一个鸽子抢到食物&＃xff0c;但所有鸽子都会被惊动来争夺&＃xff0c;没有抢到…

就是当服务器1节点有变化&＃xff0c;会通知其余的99个服务器&＃xff0c;但是最终只有1个服务器会创建成功&＃xff0c;这样98还是需要等待监听&＃xff0c;那么为了处理这种情况&＃xff0c;就需要用到临时顺序性节点。大致意思就是&＃xff0c;之前是所有99个服务器都监听一个节点&＃xff0c;现在就是每一个服务器监听自己前面的一个节点。

假设100个服务器同时发来请求&＃xff0c;这个时候会在/zkjjj节点下创建100个临时顺序性节点/zkjjj/000000001&＃xff0c;/zkjjj/000000002&＃xff0c;一直到/zkjjj/000000100&＃xff0c;这个编号就等于是已经给他们设置了获取锁的先后顺序了。

当001节点处理完毕&＃xff0c;删除节点后&＃xff0c;002收到通知&＃xff0c;去获取锁&＃xff0c;开始执行&＃xff0c;执行完毕&＃xff0c;删除节点&＃xff0c;通知003~以此类推。

作者&＃xff1a;贾俊江&＃xff0c;JAVA开发工程师&＃xff0c;一个不止会写代码的程序员&＃xff0c;还是一个会打篮球的程序员。热衷于实用技术便捷方案的探索&＃xff0c;目前在研究分布式架构相关技术。

来自&＃xff1a;博客园&＃xff0c;链接&＃xff1a;https://www.cnblogs.com/JJJ1990/p/10496850.html

本文分享自微信公众号 - 数据和云(OraNews)