PacificA: Replication in Log-Based Distributed Storage Systems阅读

最新推荐文章于 2024-10-16 11:02:33 发布

动态一时爽，重构火葬场

最新推荐文章于 2024-10-16 11:02:33 发布

阅读量889

点赞数 21

分类专栏： distributed 文章标签：分布式

本文链接：https://blog.csdn.net/iUcool/article/details/136262249

版权

distributed 专栏收录该内容

13 篇文章 0 订阅

订阅专栏

PacificA是微软实现的强一致性的分布式共识协议，用于局域网中基于log的大规模储存系统

遵循以下原则

replicgroup配置管理与数据复制分离
分散监控，用于检测故障和触发重配置，监控流量遵循数据复制的通信模式
通用抽象模型，阐明正确性并允许不同的实例化。

有以下前提条件

系统仅发生fail-stop错误

fail-stop是系统组件仅停止运行，而没有其他额外的错误行为
消息可能丢弃或者重排，但不会被修改
网络分区也可能发生
不同服务器上的时钟不一定同步，甚至不一定是松散同步的，但是时间漂移有上限

primary/backup 结构

系统维护着一组数据，每片数据都复制到一组服务器上，这些服务器称为副本组。副本组中的每个服务器都是副本。一台服务器可以作为多个组中的副本。数据复制协议遵循主/备模式。
副本组中的一个副本被指定为primary副本，而其他副本被称为secondary副本。

prepare list: 按照sn排序的准备处理的队列
committed list: 在prepare list中提交点commit point之前的部分

请求分为query和update请求，其中query进行数据查询，而update则进行数据更新。

query: 对于query请求，primary直接本地查询已提交数据就可以了
update: 对于update请求，primary分配单调递增的sn号，并要求所有secondary按照sn顺序执行update请求。当收到所有secondary执行完毕的ack后才标记该update为已提交

当所有secondary将请求加入到prepare list中之后，primary才会将之加入到committed list。而只有primary加入到committed list之后secondary才会加入到committed list

因此引出提交不变量：committed(q) ⊆ committed§ ⊆ prepared(q)成立（其中p为primary、q为secondary）

配置管理

在整个储存系统中保证了primary不变量：任何时候，仅有config manager配置的primary才会被认为是primary

server可以根据错误检测到某副本下线，而传递修改后的配置和版本号给config manager，若版本匹配则config manager就采纳该更新配置，并将版本号加一

不过，在发生网络分区时，如果primary尝试删除secondary，而该secondary则尝试将自己提升为primary，那么就可能导致无法保证primary不变量，存在多个副本认为是primary

而config manager处理方案很简单就是只接受最先发来的配置更新

那么在分布式系统中，config manager可用性又是如何实现的呢？

PacificA的做法是允许采用Paxos等其他算法来管理以实现高可用，并且由于config manager仅在reconfiguration的时候才需要参与进来，因此也不会成为性能瓶颈

租期和错误探测

假设网络发生了异常，secondary s1意外将自己提升为primary，config manager检查版本一致后就直接提升了，但是原primary此时还不知道仍然在处理请求中，那么此时就会出现两个primary，导致不一致性

为了解决这个问题，PacificA采用了基于租期的错误探测机制

在一个租期内，primary定期向secondary发送消息，并等待ack。
若经过固定时间(lease period)内没有收到ack，那么并认为租期已经结束，停止处理任何请求
并联系config manager移除相应的secondary
若config manager接受了配置，则移除secondary

否则，则移除该primary

对于secondary也是如此

若一定时间内(grace period)没有收到来自primary的消息，那么也会通知config manager移除primary并使自己成为新的primary
当config manager接受了该请求
新primary将其所有prepare list中所有未commit的prepare发送给所有secondary，使得所有secondary都commit，并删除secondary所独有的prepare

在lease period <= grace period，那么primary移除自己为primary的时间一定早于secondary提升自己为primary，那么这就保证不会同时存在多primary

提升新primary

在secondary提升自己为primary后，新primary将其prepare list中未commit的数据发送给secondary进行提交，并要求其他secondary删除primary不存在的prepare。由此来达成新primary与secondary的一致

这也就因此了最后一个不等式——reconfiguration不等式：若新primary在T时刻完成reconciliation，那么对于所有节点T之前的所有committed list都是新committed list的前缀

添加新secondary

一种简单的方案是让primary延迟新的更新，直到新加入的secondary复制完副本prepare list数据。但这显然对可用性影响较大

另一种方案是让新加入secondary作为候选secondary，候选secondary从其他副本持续拉取数据，primary也将候选secondary当作正常secondary看待，向其持续发送新请求。当数据最终同步完成之后，候选secondary就升级为secondary，并添加到配置中

如果是那种从副本组移除的secondary，那么当重新加入时，将会重新更新拉取之前未接收的数据。但是由于可能出现primary变更，那么之前旧secondary仍然可能出现prepare数据不一致情况。为应对这种情况，旧secondary便仅能保留已提交的数据，并直接获取更新其他副本prepare数据