微信号:java_bj

介绍:从算法基础到常用框架的知识体系,从初级程序员到高级架构师的成长之路,从创业小团队到Google、BAT的工作机会,始于JAVA而又不止于JAVA.JAVAer在北京,我们一起成长.

这才是真正的分布式锁

2016-12-17 23:35 58沈剑

昨晚十点下班,回家花了1个小时写了一篇《一分钟实现分布式锁》,引起读者一些反响,有些朋友反馈“setnx算什么方案”,“没有考虑超时”,“为啥不用zookeeper”,有甚者上升到 “质疑58同城的技术水平”,“拉低了架构师的层次”,“适合小学生阅读”。


58带来负面的影响实在对不起公司,也抱歉耽误部分同学1分钟时间(还好是1分钟系列),不过大部分读者的反馈是正向的,只生气了5分钟。

 

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

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

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

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

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

 

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

 

一、需求缘起

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


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

 

解决思路同一个用户同时只能有一个导入请求,需要做互斥,最简易的方案,使用setnx快速解决。


1)同一个用户,多个service进行并发操作,service需要先去抢锁

2抢到锁的service,才去数据库操作

具体这个锁用setnx,还是zookeeper都不太重要,利用一个互斥方能够访问的公共资源来实现分布式锁,这才是《一分钟实现分布式锁》的重点。

 

二、Google Chubby分布式锁阅读笔记

上一篇文章的评论中,有些朋友提到了zookeeper,会使用不够,借着Google Chubby了解下分布式锁的实现也是有必要的。


早年Google的四大基础设施,分别是GFSMapReduceBigTableChubby,其中Chubby用于提供分布式的锁服务

 

1.简介

Chubby系统提供粗粒度的分布式锁服务Chubby的使用者不需要关注复杂的同步协议,而是通过已经封装好的客户端直接调用Chubby的锁服务,就可以保证数据操作的一致性。

 

Chubby具有广泛的应用场景,例如:

1GFS选主服务器;

2BigTable中的表锁;

 

2.背景

Chubby本质上是一个分布式文件系统,存储大量小文件。每个文件就代表一个锁,并且可以保存一些应用层面的小规模数据。用户通过打开、关闭、读取文件来获取共享锁或者独占锁;并通过反向通知机制,向用户发送更新信息。

 

3.系统设计

3.1设计目标

Chubby系统设计的目标基于以下几点:

1粗粒度的锁服务

2高可用、高可靠

3可直接存储服务信息,而无需另建服务;

4高扩展性

 

在实现时,使用了以下特性:

1缓存机制:客户端缓存,避免频繁访问master

2通知机制:服务器会及时通知客户端服务变化;

 

3.2整体架构


Chubby架构并不复杂,如上图分为两个重要组件:

1Chubby:客户端通过调用Chubby库,申请锁服务,并获取相关信息,同时通过租约保持与服务器的连接;

2Chubby服务器组:一个服务器组一般由五台服务器组成(至少3台),其中一台master,服务维护与客户端的所有通信;其他服务器不断和主服务器通信,获取用户操作。

 

4.系统实现

4.1文件系统

Chubby文件系统类似于简单的unix文件系统,但它不支持文件移动操作与硬连接。文件系统由许多Node组成,每个Node代表一个文件,或者一个目录。文件系统使用Berkeley DB来保存每个Node的数据。文件系统提供的API很少:创建文件系统、文件操作、目录操作等简易操作。

 

4.2基于ICEChubby通信机制

一种基于ICERPC异步机制,核心就是异步,部分组件负责发送,部分组件负责接收。

 

4.3客户端与master的通信

1)长连接保持连接,连接有效期内,客户端句柄、锁服务、缓存数据均一直有效;

2)定时双向keep alive

3)出错回调是客户端与服务器通信的重点。


下面将说明正常客户端租约过期主服务器租约过期主服务器出错等情况。

 

1)正常情况

keep alive是周期性发送的一种消息,它有两方面功能:延长租约有效期,携带事件信息告诉客户端更新正常情况下,租约会由keep alive一直不断延长。

潜在回调事件包括:文件内容修改、子节点增删改、master出错等。


2)客户端租约过期

客户端没有收到masterkeep alive,租约随之过期,将会进入一个“危险状态”。由于此时不能确定master是否已经终止,客户端必须主动让cache失效,同时,进入一个寻找新的master的阶段。


这个阶段中,客户端会轮询Chubby Cell中非master的其他服务器节点,当客户端收到一个肯定的答复时,他会向新的master发送keep alive信息,告之自己处于“危险状态”,并和新的master建立session然后把cache中的handler发送给master刷新。


一段时间后,例如45s,新的session仍然不能建立,客户端立马认为session失效,将其终止。当然这段时间内,不能更改cache信息,以求保证数据的一致性。


3master租约过期

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,客户端必须更新handlelock

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.1master

1)每个server都试图创建/打开同一个文件,并在该文件中记录自己的服务信息,任何时刻都只有一个服务器能够获得该文件的控制权;

2)首先创建该文件的server成为主,并写入自己的信息;

3)后续打开该文件的server成为从,并读取主的信息;

 

5.2进程监控

1)各个进程都把自己的状态写入指定目录下的临时文件里;

2)监控进程通过阅读该目录下的文件信息来获得进程状态;

3)各个进程随时有可能死亡,因此指定目录的数据状态会发生变化;

4)通过事件机制通知监控进程,读取相关内容,获取最新状态,达到监控目的;

 

6.总结

Google Chubby提供粗粒度锁服务,它的本质是一个松耦合分布式文件系统;开发者不需要关注复杂的同步协议,直接调用库来取得锁服务,并保证了数据的一致性。

 

最后要说明的是,最终Chubby系统代码共13700多行,其中ice自动生成6400行,手动编写约8000行,这就是Google牛逼的地方:强大的工程能力,快速稳定的实现,然后用来解决各种业务问题。

==【完】==

如果没有时间读完,看看文末“选master”和“进程监控”两个例子,对理解“利用一个互斥方能够访问的公共资源来实现分布式锁”应该有帮助。本篇只是读书笔记,了解更多细节可查阅Google的论文。


相关阅读:巧用CAS解决数据一致性问题

 
Java北京 更多文章 Java中的ThreadPoolExecutor类
猜您喜欢 通俗解释主要编程语言及其用途 DevOps2.0工具集黑宝书-读书笔记之14-群集和服务扩展 或许我会成为一个大胖子! 关于Docker Swarm的用途详细介绍 腾讯社交LBS服务技术要点