浅谈分布式一致性协议笔记（二）| 青训营笔记

LimeRanceLan
159 阅读6分钟

浅谈分布式一致性协议笔记（二）| 青训营笔记

这是我参与「第四届青训营 -大数据场」笔记创作活动的第21天

三、一致性协议案例

1. Paxos

  • The Part-Time Parliamen by Lamport 1989

    • 也就是人们提到的Paxos
    • 基本上就是一致性协议的的同义词
    • 该算法的正确性是经过证明的

那么问题解决了吗？

  • Paxos是出了名的难以理解，Lamport本人在01年又写了一篇Paxos Made Simple

    • "The Paxos Algorighm, when presented in plain English, is very simple."

  • 算法整体是以比较抽象的形式描述，工程实现时需要做一些修改

  • Google在实现Chubby的时候是这样描述的

    • here are significant gaps between the description of the Paxos algorithm and the needs of a real-world system.... the final system will be based on an unproven protocol .

2. Raft

  • 2014年发表

  • 易于理解作为算法的设计目标

    • 使用了RSM、Log、RPC的概念
    • 直接使用RPC对算法进行了描述
    • Strong Leader-based
    • 使用了随机的方法减少约束

  • 正确性

    • 形式化验证
    • 拥有大量成熟系统
2.1 角色

image.png

2.2 整体流程

image.png

2.3 日志复制

image.png

2.4 从节点失效

image.png

2.5 Term
  • 每个 Leader 服务于一个 term
  • 每个 term 至多只有一个 leader
  • 每个节点存储当前的 term
  • 每个节点 term 从一开始，只增不减
  • 所有 rpc 的 request reponse 都携带 term
  • 只 commit 本 term 内的 log

image.png

2.6 主节点失效

  • Leader 定期的发送 AppendEntries RPCs 给其余所有节点

  • 如果 Follower 有一段时间没有收到 Leader的 AppendEntries, 则转换身份成为 Candidate

  • Candidate 自增自己的 term,同时使用 RequestVote RPCs 向剩余节点请求投票

    • raft 在检查是否可以投票时，会检查 log 是否 outdated, 至少不比本身旧才会投给对应的 Candidate

  • 如果多数派节点投给它，则成为该 term 的 leader

2.7 Leader failure

image.png

2.8 安全性
2.8.1 同 Term

  • 对于 Term 内的安全性

    • 目标：

      • 对于所有已经的 commited 的 <term,index> 位置上至多只有一条 log

  • 由于 Raft 的多数派选举，我们可以保证在一个 term 中只有一个 leader

    • 我们可以证明一条更严格的声明：在任何 <term,index> 位置上，至多只有一条 log
2.8.2 跨 Term

  • 对于跨 Term 的安全性

    • 目标：

      • 如果一个log被标记 commited,那这个log一定会在未来所有的leader中出现 Leader completeness

  • 可以证明这个 property

    • Raft 选举时会检查 Log 的是否 outdated, 只有最新的才能当选 Leader
    • 选举需要多数派投票，而 commited log 也已经在多数派中（必有overlap)
    • 新 Leader 一定持有 commited log, 且 Leader 永远不会 overwrite log

3. 复制状态机（RSM）

  • RSM (replicated state machine)

    • Raft中所有的consensus都是直接使用Log作为载体

  • Commited Index

    • 一旦Raft更新Commited Index,意味着这个Index前的所有Log都可以提交给状态机了
    • Commited Index是不持久化的，状态机也是volatile的,重启后从第一条Log开始

image.png

四、实现细节以及未来

1. 用Raft构建KV系统

案例-KV

1.1 一致性读写的定义

  • 方案一:

    • 写log被commit 了。返回客户端成功，
    • 读操作也写入一条log，状态机apply时返回client
    • 增加Log量

  • 方案二:

    • 写log被commit 了。返回客户端成功
    • 读操作先等待所有commited log apply，再读取状态机
    • 优化写时延

  • 方案三:

    • 写Log被状态机 apply，返回给client
    • 读操作直接读状态机
    • 优化读时延
1.2 Raft不保证一直有一个leader
  • 只保证一个term至多有一个 leader
  • 可能存在多个term 的leader

既然可能存在多个term 的leader，如何确定只有一个Leader呢？

  • 确定合法的Leadership

    • 方案一: 通过一轮 Heartbeat 确认 Leadership(获取多数派的响应)

    • 方案二:

      • 通过上一次 Heartbeat时间来保证接下来的有段时间内follower不会timeout
      • 如果follower上一次收到心跳，那么follower在这段时间内不进行投票
      • 如果多数follower满足条件，那么在这段时间内则保证不会有新的Leader产生
1.3 结合实际情况
  • 选择读写方案二或方案三，只不过读之前要采用上面方案确认是否是合法的Leadership。
  • 取决于raft 的实现程度以及读写的情况
1.4 出现问题及方案

  • 多个副本只有单个副本可以提供服务，一个Leader忙不过来。

    • 服务无法水平拓展

  • 增加更多Raft组

    • 操作跨Raft组。每个Raft组负责一个range的Key，这样读写就找对应的Raft组，这样就把集群的Leader打散并且可以水平拓展

2. 回到共识算法

  • Raft :关于Log

    • 论文中就给出的方案，当过多的Log占用后，启动snapshot，替换掉Log，相当于从0开始到snapshot包含的这条Log都扔掉而被snapshot替换掉。
    • 如果对于持久化的状态机，如何快速的产生Snapshot？需要优化。
    • 多组 Raft的应用中，Log 如何合流

  • 关于configuration change（比如说现在是三节点，其中一个节点挂了之后，将三个节点扩容到4个节点后再踢掉一个节点的过程）

  • 论文中给出的joint-consensus以及单一节点变更两种方案

  • Raft是正确的，但是在工程世界呢?

    • 真实世界中不是所有的错误都是完美fail-stop的
    • cloudflare 的case,etcd在partial network 下,outage了6个小时[1]

[1]AByzantine failure in the real world. blog.cloudflare.com/a-byzantine…

3. 共识算法的未来

  • 高性能

    • 数据中心网络100G，时延约为几个us

    • RDMA 网卡以及programable switch的应用。

    • 我们想要的是:us级别的共识，以及us级别的容错，下面是两种出名方案。

      • HovercRaft（原来状态机都是在CPU里面跑，现在通过可编程交换机把raft协议用了IP multicast做了网络层，这样用户从这边就不感知）

        • P4 programable switch:IP multicast

      • Mu（Leader通过one-sided RDMA(不通过rpc)去直接往Follower内存里面去写，这样可以达到超高性能的共识）

        • Use one-sided RDMA
        • pull based heartbeat instead of push-based.

  • 多节点提交(Leaderless)

    • 节点跨地域，导致节点间的RTT(Round Trip Time)很大

    • EPaxos [1]

      • 使用了冲突图的方式来允许并行Commit
      • 不冲突的情况下1RTT 提交时间

[1] Moraru, lulian, David G. Andersen, and Michael Kaminsky. "Egalitarian paxos." ACM Symposium on Operating Systems Principles. 2012.

  • Raft Paxos相互移植

    • Raft有很多成熟的实现

    • 研究主要关注在Paxos 上

    • 如何关联两种算法

      • On the Parallels between Paxos and Raft, and how to Port Optimizations[1]
      • Paxos vs Raft: Have we reached consensus on distributed consensus?[2]

[1] Wang, Zhaoguo, et al. "On the Parallels between Paxos and Raft, and how to Port Optimizations." Proceedings of the 2019 ACM Symposium on Principles of Distributed Computing.2019.

[2] Howard, Heidi, and Richard Mortier. "Paxos vs Raft: Have we reached consensus on distributed consensus?." Proceedings of the 7th Workshop on Principles and Practice of Consistency for Distributed Data.2020.

  • 共识算法作为一个系统

    • 多数分布式系统都选择共识算法作为底座

    • 不同一致性协议有不同的特性

    • Virtual consensus in delos[1]

      • 对外暴露一致性的LOG作为借口
      • 内部对于LoG可以选择不同的实现

4. 小结

  • 了解到了Raft如何应用在KV中
  • 也了解到了单一的共识算法有其局限性
  • 在工程实践中，需要对其进行一定的优化
  • 最后，了解到了一致性协议当前的研究热点
avatar
文章
阅读
粉丝