问题背景
在旧的分布式框架下,所有节点共同在一个共识组内(Meta组),因此需要全局执行的操作可以在共识组内执行保证最终一致性,即每个节点最终能够执行到该操作。
但在新的架构里,考虑到随着节点数目增多后,Meta组的存在会极大影响性能,且Meta组的leader的任务量会非常大,甚至成为系统瓶颈,因此我们删除了Meta组,由
几个ConfigNode组成的共识组来管理整个集群的DataNode。但这会带来的问题是,我们需要考虑如果保证全局执行的操作的原子性。
以删除存储组为例,该操作需要发送给所有DataNode进行执行,清空本地的数据,元数据,以及对应的分区表和元数据缓存。
由于IoTDB目前单机和分布式都不支持事务处理,如何保证所有节点都成功执行了该操作,我们给出了以下几种方案。
解决方案
用户重试
最简单的方式是ConfigNode发送给所有节点后,在一个timeout时间内,如果有节点未返回Success,则返回给用户partial success信息,让用户自行重试。
自动重试
ConfigNode在某个节点timeout后,自动重试。
自动重试方案流程(以删除存储组为例):
- Coordinator将DeleteStorageGroup请求转发给ConfigNode共识组
- 日志在共识组内进行共识,共识完成后返回给用户开始删除的信息
- apply该日志时进入第一阶段:
- 所有ConfigNode为所有DataNode维护一个状态,用于删除存储组
- 共识组Leader中的异步线程检测到状态创建完成,开始向所有DataNode发起删除存储组请求
- 在transfer leader后,新leader上的异步线程生效,继续发送删除存储组的请求(该操作具有幂等性)
- 在删除完成后,leader在组内发起DeleteStorageGroup完成的日志,所有节点删除对应状态
Lease机制
Lease机制最初用来解决分布式存储中缓存一致性的问题,用来保证缓存的强一致性。Lease由颁发者授予的在某一有效期内的承诺,颁发者一旦发出lease,无论接收方是否收到,无论接收方处于何种状态,只要lease未过期,颁发者都认为lease生效。对于接收方来说,lease过期后,不能再使用该承诺。
Lease 机制的基本原理如下:中心服务器在向各节点发送数据时同时颁发一个 lease,每个 lease 具有一个有效期,,一旦真实时间超过这个时间点,则 lease 过期失效(假设中心服务器与各节点的时钟是同步的)。通常情况下,中心服务器的lease过期时间要略长于节点上的lease过期时间,这样在一定程度上减轻了时钟误差带来的问题。(假设Clock drift在一定范围内)
该机制的具体表现为:
- 如果接收方需要进行写操作,则向中心节点发送一个lease request,拿到对应的lease之后才可以执行写操作
- 中心节点等待所有lease超时再进行写入,这里有一个优化方案是,server直接给其他节点发送invalid lease,这样可以不需要超时等待时间
在IoTDB中,引入lease机制的作用是在DataNode脱离ConfigNode控制时(网络分区,full GC等),阻塞DataNode上的读写操作。
例如,在删除存储组时,需要ConfigNode向所有DataNode发送删除存储组的请求,此时可以设置该请求的timeout时间大于lease过期时间,这样保证若ConfigNode和DataNode网络分区时,请求timeout时,DataNode上的lease
必定过期,因此用户无法在该DataNode上执行读写,以防读到脏数据,或者写入已被删除的存储组。在DataNode可以重新与ConfigNode建立连接时,申请lease,并且接收到之前的删除存储组操作。
引入lease机制会使得系统的复杂度增加,但作为成熟的分布式的协议,并且在工业界下已经被大量使用的方案,如果有需要,可以在后续引入IoTDB中。
工程中的应用:
- GFS 中的 Lease。GFS 中使用 Lease 确定 Chuck 的 Primary 副本。Lease 由 Master 节点颁发给 primary 副本,持有Lease 的副本成为 primary 副本。
- Chubby通过paxos协议实现去中心化选择primary节点,Secondary节点向 primary节点发送 lease,该 lease 的含义是: “承诺在 lease 时间内,不选举其他节点成为 primary节点。除此之外,Chubby用lease维护缓存一致性,client只有拥有primary颁发的lease才可以进行读写操作。
- Zookeeper 中,集群中在选择一个leader节点后,其余节点成为follower,follower接收leader颁发的租约后可进行读操作。当有写操作时,leader将writing replicate到follower时,follower会将租约失效,commit后重新申请,因此zookeeper的写入性能不会太高。
参考文献
An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency