这才是真正的分布式锁

由 58沈剑 创建, 最后一次修改 2017-05-16

技术领域,我觉得了解来龙去脉,了解本质原理,比用什么工具实现更重要

(1)进程多线程如何互斥?

(2)一个手机上两个APP访问一个文件如何互斥?

(3)分布式环境下多个服务访问一个资源如何互斥?

归根结底,是利用一个互斥方能够访问的公共资源来实现分布式锁,具体这个公共资源是redis来setnx,还是zookeeper,相反没有这么重要。


言归正传,今天把昨天文章的缘起讲一讲,并通过Google Chubby的论文阅读笔记聊一聊分布式锁。

一、需求缘起

58到家APP新上线了导入通讯录好友功能,测试的同学发现,连续点击导入会导入重复数据:

数据重复导入
客户端同一个用户同时发出了多个请求,分布式环境下,多台机器上部署的多个service进行了并发操作,故插入了冗余数据。

解决思路同一个用户同时只能有一个导入请求,需要做互斥,最简易的方案,使用setnx快速解决。
使用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整体架构
figure 1:system structure

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牛逼的地方:强大的工程能力,快速稳定的实现,然后用来解决各种业务问题。


以上内容是否对您有帮助:

您可能还喜欢:

二维码
建议反馈
二维码