Multi-Master-Paxos-3
Posted 分布式研究小院
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Multi-Master-Paxos-3相关的知识，希望对你有一定的参考价值。
本文链接: https://blog.openacid.com/algo/mmp3
Background
中介绍了一款非常简洁的分布式kv存储实现, 它是基于 classic-paxos 实现分布式一致性. 在 中我们提到, 每次写入, 也就是每个 paxos 实例需要2轮 RPC 完成, 效率低.
一个常见的优化就是 mutli-paxos(或raft), 但这种设计在跨机房(或跨云)部署的环境中的缺陷是: 异地机房的写入就需要2个 RTT 才能完成:
client → leader → followers → leader → client
它无法做到 异地多活, 在3节点的场景里, 有 2/3 的写入效率降低到2 个 RTT.
本文从另一角度出发来解决异地多活的问题, 3机房部署的3副本集群中:
任一节点都可写,
任一笔写入都可以严格在1个 RTT 内完成.
这就是今天要介绍的paxoskv的改进版: mmp-3: multi-master-paxos 3副本实现.
同样 show me the code 的原则不能变: 本文实现的3节点多活代码在: https://github.com/openacid/paxoskv/tree/mmp3
异地多活是目前分布式领域越来越被重视的一个问题, 机房正在变成单机, 单机房多机分布式在现在大规模部署的业务中已经满足不了业务的可用性需求了.
几乎所有线上环境部署的分布式存储, 都需要跨机房(或者跨云)的部署. 而大家也积极在解决这些问题:
或者用队列等最终一致性的手段来完成跨机房的复制, 这样会产生数据不一致, 2条互相冲突的数据可能同时被写入; 业务层需要参与解决这类冲突.
或者将数据做拆分, 将在A地写入多的分配到A机房为 leader 的 sharding , 将B地写入较多的数据分配到B机房为 leader 的 sharding .
或者一个机房为主: 部署2个副本, 另一个机房部署1个副本来形成3副本的集群, 这样实际上A机房故障会导致全局不可读写, B机房只能提供额外的数据冗余, 无法提供更多的数据可用性.
paxos 在集群较小时可以通过定制 paxos 来完成1个 RTT 的写入, 如果使用 , 最多支持5个副本的多活.
在 epaxos 定义的多活设计, 简单介绍了3节点的设计, 但并没有给出实现的细节, 其中各种冲突的处理以及修复的流程并没有明确的定义.
同时 epaxos 的 apply 算法存在不可解决的 livelock 问题: 通过 SCC 来确定 instance 顺序无法保证在有限时间内结束.
另外 epaxos 的设计中缺少一个 rnd 记录( paxos 中的 last-seen-ballot 或 vbal), 导致其一致性实现是错误的.
以及 instance 之间的依赖关系会在修复过程中产生不一致的问题.
epaxos 需要另外一个seq来确定 instance 之间的顺序, 在 mmp3 的设计中, seq 是不必要的, 只需依赖关系就可以确定确定的 apply 顺序.
Multi master paxos - 3
我们从 classic-paxos 出发来分析问题.
xp的tips: 要实现一个稳定的分布式系统, 最好用 raft, 因为开箱就用. 要学习分布式系统, 最好从 paxos 开始. raft 看似简单的设计 隐藏了一些隐晦的条件, 其正确性的证明要比 paxos 复杂.
我们需要达到2个目的:
1个 RTT 完成一次commit.
3个节点同时无冲突写.
1 RTT 的 classic- paxos
如果 classic-paxos 不需要2个 RTT, 我们就不需要 multi-paxos 或 raft 这些东西来优化延迟了.
在3节点的系统中, 这是可以实现的.
首先做一些基础的设定: 一个 replica 在系统中是一个replica(或叫作server或node), 它同时是 proposer 和 acceptor. 一个 replica 接受到一个写入请求时, 它就用本地的 proposer 来完成提交.
回顾 classic paxos
介绍的 classic-paxos 写入流程如下, replica-0 上的 proposer P0, 顺次完成 phase-1, phase-2 和 commit:
以上是关于Multi-Master-Paxos-3的主要内容，如果未能解决你的问题，请参考以下文章