分布式系统理论之租约机制学习

简介:

一,租约机制介绍

在分布式系统中,往往会有一个中心服务器节点。该节点负责存储、维护系统中的元数据。如果系统中的各种操作都依赖于中心服务器上的元数据,那么中心服务器很容易成为性能瓶颈及存在单点故障。而通过租约机制,可以将中心服务器的“权力”下放给其他机器,就可以减轻中心服务器的压力。当然,租约机制还有许多其他的用途:比如,确定集群中结点的状态,还可以实现分布式下的读写锁……

如下图,GFS master颁发租约给某个chunk server,让它成为Primary 副本,当有多个client并发更新数据块时,由Primary副本确定并发更新该数据块的顺序。GFS master 将权力下放给 chunk server,缓解了一定的压力。

 

当然,也可以将中心服务器(元数据服务器)设计成集群的形式。这样,也避免了中心服务器成为瓶颈问题。比如,消息服务器:RocketMQ。其中生产者和消费者都需要NameServer来确定订阅关系,将NameServer做成无状态的集群,这里就不需要租约机制了。

 

对于租约而言,就有发布租约方 和 接收租约方。租约规定的内容可以多种多样(这也是租约具有各种应用场景的原因)。发布租约方一般为上面提到的中心服务器,中心服务器保证在租约的有效期内承诺租约规定的内容的保持不变。

比如,分布式缓存系统,元数据服务器(中心服务器)给各个Client发布租约,承诺在租约有效期内不会更改元数据。这样,各个Client只要检查它的租约未过期,就可以直接从本地读取缓存的元数据,而不是每次都访问元数据服务器获得元数据。

 

二,租约机制分析

①租约机制保证缓存的一致性

 服务器发出Lease后,会保证在Lease的有效期内不改变数据。这样,收到Lease的Client在有效期内可以放心地使用数据。在这个有效期内,Client 缓存的数据和 服务器上的数据是一致的。

存在的问题:

1)服务器修改元数据时,需要 阻塞所有的读请求,此时服务器不能发出新的Lease。以防止新发出的Lease保证的数据与服务器刚才修改的数据不一致。

解决方法:读请求到来时,直接返回数据,不颁发Lease

 

2)服务器需要等待直至所有的Client的Lease都过期后,再才颁发新“修改”后的Lease。因此,此时服务器上的数据修改了,生成了一个新的Lease版本,需要等到Client上所有的老Lease过期后,该新Lease版本才能颁布给Client。

解决方法:服务器主动通知持久Lease的Client放弃当前的Lease,并请求新Lease

 

另一种缓存一致性的保证方法类似于“租约机制”,当Client请求Server的数据时,Server为Client提供一个“回调承诺”,用于保证当其他Client修改此数据时通知该Client。回调承诺 和 请求的数据都保存在Client端,回调承诺有两种状态:有效和取消。

当Server执行了一个更新数据请求时,它会通知它发送了回调承诺的所有Client,即给Client的端的进程发一个回调(server到client的一个远程过程调用)

,当Client进程收到回调时,它将相关数据的回调承诺标识设置为“取消”。

 

②租约机制能够很好地容纳网络错误异常

 1)Lease颁发过程只依赖于单向的网络通信

服务器颁发Lease后,即使Client没有收到(Client宕机、网络异常),服务器只要等到Lease超时,就可以保证Client不再cache数据,从而可以放心地修改数据而不会破坏cache的一致性。

2)一旦Lease被Client接收,后续Lease机制不再依赖于网络通信。

3)对宕机节点有很好的容错性

颁发Lease的节点宕机了,宕机的颁发者改变不了已经颁发出的Lease的约定,不会影响Lease的正确性。

拥有Lease的节点宕机了,颁发者也不需要做容错处理,只需要等待Lease到期了,就可以收回承诺进行下一步处理。

 

③租约机制确定节点的状态

 在网络中,如何确定某个节点的状态呢?由于网络故障(网络分化)的存在,采用“心跳”机制确定节点的状态会有一些不足。

比如,A、B、C三个节点互为副本,A为primary,Q负责判断A、 B 、C的状态。如果A正常工作,但是A 、Q之间的网络异常,Q也会认为A出现了问题了,于是 Q 重新选择B作为primary,这里会导致“双主”问题。

这里的本质是:Q认为A异常了,但是A自己不认为自己异常。即,由于网络分化造成系统对于“节点状态”认知的不一致。

 解决方法有两个:1)可以使用全体协商确定谁为primary(Paxos算法) ,这是一种去中心化协议

 2)采用Lease机制

 Q收到 A 、B 、C 的heart beat后,给它们颁发一个Lease,表示已经知道了它们的状态,这样 A 、B 、C 可以在有效期内正常工作。同时,Q 可以给 A一个特殊的Lease,表示A可以作为primary工作。当需要切换primary时,只需要等到A的Lease过期,Q给另外节点颁发表示 primary的Lease即可。

 

三,租约机制在 GFS 的写操作中的作用

复制代码
We designed the system to minimize the master’s involvement in all operations.
....
A mutation is an operation that changes the contents or metadata of a chunksuch as a write or an append operation.
Each mutation is performed at all the chunk’s replicas. We use leases to maintain a consistent mutation order across replicas.
The master grants a chunk lease to one of the replicas, which we call the primary. The primary picks a serial order for all mutations to the chunk. All replicas follow this order when applying mutations.
复制代码

为了减小 master 的负载,master 给某个chunk server 颁发lease,使之成为primary,然后由primary确定 mutation order。

The master may sometimes try to revoke a lease before it expires (e.g., when the master wants to disable mutations on a file that is being renamed). 
Even if the master loses communication with a primary, it can safely grant a new lease to another replica after the old lease expires.

这里也采用 “租约机制分析”中讲到的:①master可以在租约还未过期之前 try to revoke a lease。②也可以等到租约过期后,向其他chunk server颁发primary租约(更换primary)。

 

The lease mechanism is designed to minimize management overhead at the master. A lease has an initial timeout of 60 seconds.

这句话表明,租约减少了master的负载,租约的有效期限是60s

写操作的步骤如下:

1)The client asks the master which chunkserver holds the current lease for the chunk and the locations of the other replicas.

Client向master 请求primary地址和其他chunk server地址

2)The master replies with the identity of the primary and the locations of the other (secondary) replicas.

 master返回primary地址及其他chunk server地址。Client可在Lease的有效期内缓存这些信息。

 3)The client pushes the data to all the replicas

Client把待修改的数据发给各个chunk server(replicas),这里实现了控制流与数据流的分离(Client在第二步时获得了控制信息)。

 4)Once all the replicas have acknowledged receiving the data, the client sends a write request to the primary.

Client先把待写入的数据发给各个 chunk server,等到所有的chunk server都收到这些数据后,向 primary 发起写请求。

5)The primary forwards the write request to all secondary replicas.

由primary制定写请求的顺序。所有的replicas都按照这个顺序写数据。看,采用“中心化”的方式制定写请求的顺序,这样很容易保证顺序的唯一性。

6)The secondaries all reply to the primary indicating that they have completed the operation

所有的replicas(secondaries)都按照相同的顺序写入数据后,向primary发送完成报告。

7)The primary replies to the client.

由primary向Client报告此次写操作的结果。

从上面的整个流程看,上面的操作很少涉及到master。大部分由master 颁发给Lease的primary来完成。

其实,个人感觉对于 mutation operation,这里的核心是两个:降低master的负载   保证修改顺序的一致性。而通过Lease机制,解决了这两个问题。

master给某台chunk server颁发Lease,使之成为Primary。由Primary接收Client的写请求,由Primary负责其他replicas的写操作是否完成……这都有效地降低了master的负载;其次,由primary制定写操作的序列号,顺序的确定是由primary确定的,不是协商确定的,这种“中心化”的机制容易保证顺序的一致性。

 

四,参考资料

《分布式系统原理介绍》--刘杰

租约机制简介

租约机制简单介绍

 Lease 机制在分布式系统中的应用

 分布式系统概念--第一篇 一致性协议、一致性模型、拜占庭问题、租约、副本协议 


本文转自hapjin博客园博客,原文链接:http://www.cnblogs.com/hapjin/p/5620542.html,如需转载请自行联系原作者

相关文章
|
2月前
|
消息中间件 关系型数据库 MySQL
分布式事物-全面详解(学习总结---从入门到深化)
分布式事物-全面详解(学习总结---从入门到深化)
1469 0
|
1月前
|
SQL 关系型数据库 数据库
学习分布式事务Seata看这一篇就够了,建议收藏
学习分布式事务Seata看这一篇就够了,建议收藏
|
2月前
|
消息中间件 Dubbo 应用服务中间件
分布式事物【Hmily实现TCC分布式事务、Hmily实现TCC事务、最终一致性分布式事务解决方案】(七)-全面详解(学习总结---从入门到深化)
分布式事物【Hmily实现TCC分布式事务、Hmily实现TCC事务、最终一致性分布式事务解决方案】(七)-全面详解(学习总结---从入门到深化)
72 0
|
3月前
|
消息中间件 RocketMQ 微服务
分布式事物【库存微服务业务层实现、实现充值微服务、充值微服务之业务层实现、账户微服务之业务层实现】(九)-全面详解(学习总结---从入门到深化)(下)
分布式事物【库存微服务业务层实现、实现充值微服务、充值微服务之业务层实现、账户微服务之业务层实现】(九)-全面详解(学习总结---从入门到深化)
37 0
|
2月前
|
Java 数据库连接 API
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)
53 0
|
2月前
|
存储 Oracle 关系型数据库
分布式事物【Seata实现、下载启动Seata服务、搭建聚合父工程构建】(四)-全面详解(学习总结---从入门到深化)
分布式事物【Seata实现、下载启动Seata服务、搭建聚合父工程构建】(四)-全面详解(学习总结---从入门到深化)
45 0
|
3月前
|
NoSQL 中间件 API
分布式锁【数据库乐观锁实现的分布式锁、Zookeeper分布式锁原理、Redis实现的分布式锁】(三)-全面详解(学习总结---从入门到深化)(下)
分布式锁【数据库乐观锁实现的分布式锁、Zookeeper分布式锁原理、Redis实现的分布式锁】(三)-全面详解(学习总结---从入门到深化)
80 2
|
Dubbo 应用服务中间件 微服务
分布式事物【Hmily实现TCC分布式事务、Hmily实现TCC事务、最终一致性分布式事务解决方案】(七)-全面详解(学习总结---从入门到深化)(上)
分布式事物【Hmily实现TCC分布式事务、Hmily实现TCC事务、最终一致性分布式事务解决方案】(七)-全面详解(学习总结---从入门到深化)
40 1
|
开发框架 Java 数据库连接
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)(下)
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)
37 0
|
数据库 微服务
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)(上)
分布式事物【XA强一致性分布式事务实战、Seata提供XA模式实现分布式事务】(五)-全面详解(学习总结---从入门到深化)
37 0