这才是真正的分布式锁
技术领域,我觉得了解来龙去脉,了解本质原理,比用什么工具实现更重要:
(1)进程多线程如何互斥?
(2)一个手机上两个APP访问一个文件如何互斥?
(3)分布式环境下多个服务访问一个资源如何互斥?
归根结底,是利用一个互斥方能够访问的公共资源来实现分布式锁,具体这个公共资源是redis来setnx,还是zookeeper,相反没有这么重要。
言归正传,今天把昨天文章的缘起讲一讲,并通过Google Chubby的论文阅读笔记聊一聊分布式锁。
一、需求缘起
58到家APP新上线了导入通讯录好友功能,测试的同学发现,连续点击导入会导入重复数据:
客户端同一个用户同时发出了多个请求,分布式环境下,多台机器上部署的多个service进行了并发操作,故插入了冗余数据。
解决思路:同一个用户同时只能有一个导入请求,需要做互斥,最简易的方案,使用setnx快速解决。
(1)同一个用户,多个service进行并发操作,service需要先去抢锁
(2)抢到锁的service,才去数据库操作
具体这个锁用setnx,还是zookeeper都不太重要,利用一个互斥方能够访问的公共资源来实现分布式锁,这才是《一分钟实现分布式锁》的重点。
二、Google Chubby分布式锁阅读笔记
上一篇文章的评论中,有些朋友提到了zookeeper,会使用不够,借着Google Chubby了解下分布式锁的实现也是有必要的。
早年Google的四大基础设施,分别是GFS、MapReduce、BigTable、Chubby,其中Chubby用于提供分布式的锁服务。
1.简介
Chubby系统提供粗粒度的分布式锁服务,Chubby的使用者不需要关注复杂的同步协议,而是通过已经封装好的客户端直接调用Chubby的锁服务,就可以保证数据操作的一致性。
Chubby具有广泛的应用场景,例如:
(1)GFS选主服务器;
(2)BigTable中的表锁;
2.背景
Chubby本质上是一个分布式文件系统,存储大量小文件。每个文件就代表一个锁,并且可以保存一些应用层面的小规模数据。用户通过打开、关闭、读取文件来获取共享锁或者独占锁;并通过反向通知机制,向用户发送更新信息。
3.系统设计
3.1设计目标
Chubby系统设计的目标基于以下几点:
(1)粗粒度的锁服务;
(2)高可用、高可靠;
(3)可直接存储服务信息,而无需另建服务;
(4)高扩展性;
在实现时,使用了以下特性:
(1)缓存机制:客户端缓存,避免频繁访问master;
(2)通知机制:服务器会及时通知客户端服务变化;
3.2整体架构
Chubby架构并不复杂,如上图分为两个重要组件:
(1)Chubby库:客户端通过调用Chubby库,申请锁服务,并获取相关信息,同时通过租约保持与服务器的连接;
(2)Chubby服务器组:一个服务器组一般由五台服务器组成(至少3台),其中一台master,服务维护与客户端的所有通信;其他服务器不断和主服务器通信,获取用户操作。
4.系统实现
4.1文件系统
Chubby文件系统类似于简单的unix文件系统,但它不支持文件移动操作与硬连接。文件系统由许多Node组成,每个Node代表一个文件,或者一个目录。文件系统使用Berkeley DB来保存每个Node的数据。文件系统提供的API很少:创建文件系统、文件操作、目录操作等简易操作。
4.2基于ICE的Chubby通信机制
一种基于ICE的RPC异步机制,核心就是异步,部分组件负责发送,部分组件负责接收。
4.3客户端与master的通信
(1)长连接保持连接,连接有效期内,客户端句柄、锁服务、缓存数据均一直有效;
(2)定时双向keep alive;
(3)出错回调是客户端与服务器通信的重点。
下面将说明正常、客户端租约过期、主服务器租约过期、主服务器出错等情况。
(1)正常情况
keep alive是周期性发送的一种消息,它有两方面功能:延长租约有效期,携带事件信息告诉客户端更新。正常情况下,租约会由keep alive一直不断延长。
潜在回调事件包括:文件内容修改、子节点增删改、master出错等。
(2)客户端租约过期
客户端没有收到master的keep alive,租约随之过期,将会进入一个“危险状态”。由于此时不能确定master是否已经终止,客户端必须主动让cache失效,同时,进入一个寻找新的master的阶段。
这个阶段中,客户端会轮询Chubby Cell中非master的其他服务器节点,当客户端收到一个肯定的答复时,他会向新的master发送keep alive信息,告之自己处于“危险状态”,并和新的master建立session,然后把cache中的handler发送给master刷新。
一段时间后,例如45s,新的session仍然不能建立,客户端立马认为session失效,将其终止。当然这段时间内,不能更改cache信息,以求保证数据的一致性。
(3)master租约过期
master一段时间没有收到客户端的keep alive,则其进入一段等待期,此期间内仍没有响应,则master认为客户端失效。失效后,master会把客户端获得的锁,机器打开的临时文件清理掉,并通知各副本,以保持一致性。
(4)主服务器出错
master出错,需要内部进行重新选举,各副本只响应客户端的读取命令,而忽略其他命令。新上任的master会进行以下几步操作:
a,选择新的编号,不再接受旧master的消息;
b,只处理master位置相关消息,不处理session相关消息;
c,等待处理“危险状态”的客户端keep alive;
d,响应客户端的keep alive,建立新的session,同时拒绝其他session相关操作;同事向客户端返回keep alive,警告客户端master fail-over,客户端必须更新handle和lock;
e,等待客户端的session确认keep alive,或者让session过期;
f,再次响应客户端所有操作;
g,一段时间后,检查是否有临时文件,以及是否存在一些lock没有handle;如果临时文件或者lock没有对应的handle,则清除临时文件,释放lock,当然这些操作都需要保持数据的一致性。
4.4服务器间的一致性操作
这块考虑的问题是:当master收到客户端请求时(主要是写),如何将操作同步,以保证数据的一致性。
(1)节点数目
一般来说,服务器节点数为5,如果临时有节点被拿走,可预期不久的将来就会加进来。
(2)关于复制
服务器接受客户端请求时,master会将请求复制到所有成员,并在消息中添加最新被提交的请求序号。member收到这个请求后,获取master处被提交的请求序号,然后执行这个序列之前的所有请求,并把其记录到内存的日志里。如果请求没有被master接受,就不能执行。
各member会向master发送消息,master收到>=3个以上的消息,才能够进行确认,发送commit给各member,执行请求,并返回客户端。
如果某个member出现暂时的故障,没有收到部分消息也无碍,在收到来自master的新请求后,主动从master处获得已执行的,自己却还没有完成的日志,并进行执行。
最终,所有成员都会获得一致性的数据,并且,在系统正常工作状态中,至少有3个服务器保持一致并且是最新的数据状态。
4.5Chubby系统锁机制
客户端和服务器除了要保存lease对象外,服务器和客户端还需要保存另一张表,用于描述已经加锁的文件及相关信息。由于Chubby系统所使用锁是建议性而非强制性的,这代表着如果有多个锁请求,后达的请求会进入锁等待队列,直到锁被释放。
5.Chubby使用例子(重点)
5.1选master
(1)每个server都试图创建/打开同一个文件,并在该文件中记录自己的服务信息,任何时刻都只有一个服务器能够获得该文件的控制权;
(2)首先创建该文件的server成为主,并写入自己的信息;
(3)后续打开该文件的server成为从,并读取主的信息;
5.2进程监控
(1)各个进程都把自己的状态写入指定目录下的临时文件里;
(2)监控进程通过阅读该目录下的文件信息来获得进程状态;
(3)各个进程随时有可能死亡,因此指定目录的数据状态会发生变化;
(4)通过事件机制通知监控进程,读取相关内容,获取最新状态,达到监控目的;
6.总结
Google Chubby提供粗粒度锁服务,它的本质是一个松耦合分布式文件系统;开发者不需要关注复杂的同步协议,直接调用库来取得锁服务,并保证了数据的一致性。
最后要说明的是,最终Chubby系统代码共13700多行,其中ice自动生成6400行,手动编写约8000行,这就是Google牛逼的地方:强大的工程能力,快速稳定的实现,然后用来解决各种业务问题。
更多建议: