大数据-复习笔记-15 | 青训营笔记

能鸽善鹉
124 阅读9分钟

浅谈一致性协议 - 复习笔记

这是我参与「第四届青训营 」笔记创作活动的的第16天！

1. 分布式系统

1.1 分布式系统面临的挑战

  • 数据规模越来越大
  • 服务的可用性要求越来越高
  • 快速迭代的业务要求系统足够易用

1.2 理想中的分布式系统

  • 高性能：可拓展、低时延、高吞吐
  • 正确：一致性、易于理解
  • 可靠：容错、高可用

1.3 从 HDFS 开始

image.png

1.4 案例-KV

  • 从最简单机KV开始
  • 接口：
    • Get（key）->value
    • BatchPut（[k1，k2，...]，[v1，v2,…]）
  • 第一次实现
    • RPC
    • DB Engine

image.png

  • 可靠性：
    • 容错？
    • 高可用？
  • 正确性：
    • 单进程，所有操作顺序执行

2. 一致性与共识算法

2.1 从复制开始

  • 既然一台机器会挂 image.png
  • 如果两个副本都能接受请求 image.png

2.2 如何复制

  • 主副本定期拷贝全量数据到从副本
  • 主副本拷贝操作到从副本

image.png

2.3 如何复制操作

  • 主副本把所有的操作打包成Log
    • 所有的Log写入都是持久化的，保存在磁盘上
  • 应用包装成状态机，只接收Log作为Input
  • 主副本确认Log 已经成功写入到副本机器上，当状态机apply后，返回客户端

image.png

2.4 关于读操作

  • 读操作
    • 方案一：直接读状态机，要求写操作进入状态机后再返回 client
    • 方案二：写操作复制完成后直接返回，读操作Block等待所有 pending log 进入状态机
  • 如果不遵循上述两种方案呢？
    • 可能存在刚刚写入的值读不到的情况（在Log中）

2.5 什么是一致性

  • 对于我们的KV
    • 像操作一台机器一样
      • 要读到最近写入的值
  • 一致性是一种模型（或语义）
    • 来约定一个分布式系统如何向外界（应用）提供服务
    • KV中常见的一致性模型
      • 最终一致性：读取可能暂时读不到但是总会读到
      • 线性一致性：最严格，线性执行

image.png

  • 致性的分类
    • 经常与应用本身有关
  • Linearizability 是最理想的

2.6 复制协议-当失效发生

  • 当主副本失效

    • 手动切换
    • 容错？
      • 不，我们的服务还是停了
    • 高可用？
      • 也许，取决于我们从发现到切换的过程的有多快
    • 正确？
      • 操作只从一台机器上发起
      • 所有操作返回前都已经复制到另一台机器了

  • 当主副本失效时，为了使得算法简单

    • 我们人肉切换，只要足够快
      • 我们还是可以保证较高的可用性。

  • 但是如何保证主副本是真的失效了呢？

    • 在切换的过程中，主副本又开始接收client端的请求
    • 两个主副本显然是不正确的，log 会被覆盖写掉
    • 我们希望算法能在这种场景下仍然保持正确

  • 要是增加到三个节点呢？

    • 每次都等其他节点操落盘性能较差
    • 能不能允许少数节点挂了的情况下，仍然可以工作
      • falut-tolerance

2.7 共识算法

  • 什么是共识算法
    • "The consensus problem requires agreement among a number of processes（or agents）for a single data value.Some of the processes（agents）may fail or be unreliable in other ways，so consensus protocols must be fault tolerant or resilient"
    • 简而言之一个值一旦确定，所有人都认同。
  • 有文章证明是一个不可能的任务（FLP impossibility）
    "In this paper，we show the surprising result that o complelely asynchronous consensus protocol can tolerate even a single unannounced process deat.We do not consider Byzantine failures，and we assume that the message system is reliableit delivers all messages correctly and exactly once."
    -JACM 85[1]
  • 错误总是发生
    • Non-Byzantine fault
  • 错误类型很多
    • 网络断开，分区，缓慢，重传，乱序
    • CPU、IO都机会停住
  • 容错（falute-tolerance）
  • 共识协议不等于一致性
    • 应用层面不同的一致性，都可以用共识协议来实现
      • 比如可以故意返回旧的值
    • 简单的复制协议也可以提供线性一致性
  • 一般讨论共识协议时提到的一致性，都指线性一致性
    • 因为弱一致性往往可以使用相对简单的复制算法实现

3.从Rat入手

3.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 fimal system will be based on an unproven protocol.

3.2 Raft

  • 2014年发表
  • 易于理解作为算法的设计目标
    • 使用了RSM、Log、RPC的概念
    • 直接使用RPC对算法进行了描述
    • Strong Leader-based
    • 使用了随机的方法减少约束
  • 正确性
    • 形式化验证
    • 拥有大量成熟系统

3.3 复制状态机（RSM）

  • RSM（replicated state machine）
    • Raft中所有的consensus 都是直接使用Log作为载体
  • Commited Index
    • 一旦Raft 更新Commited Index，意味着这个Index前的所有Log 都可以提交给状态机了
    • Commited Index是不持久化的，状态机也是volatile的，重启后从第一条Log开始

image.png

3.4 Raft 角色和整体流程

Raft 角色

image.png

Raft 整体流程

1660357891837.png

3.5 Raft 日志复制

image.png

3.6 Raft 从节点失效

1660358015757.png

3.7 Raft Term

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

1660358093421.png

3.8 Raft 主节点失效山学

  • Leader 定期的发送AppendEntries RPCs给其余所有节点
  • 如果Follower 有一段时间没有收到Leader的AppendEntries，则转换身份成为Candidate
  • Candidate 自增自己的term，同时使用RequestVote RPCs向剩余节点请求投票
    • rat在检查是否可以投票时，会检查log 是否outdated，至少不比本身旧才会投给对应的Candidate
  • 如果多数派节点投给它，则成为该term的leader

3.9 Raft Leader failure

image.png

3.10 Raft 安全性

3.10.1 Raft 安全性-同Term

  • 对于Term内的安全性
    • 目标：
      • 对于所有已经的commited的<term，index>位置上至多只有一条log
  • 由于Raft的多数派选举，我们可以保证在一个term中只有一个leader
    • 我们可以证明一条更严格的声明：在任何<term，index>位置上，至多只有一条log

3.10.1 Raft 安全性-跨Term

  • 对于跨Tem的安全性
    • 目标：
      • 如果一个log 被标记commited，那这个log定会在未来所有的leader中出现Leader completeness
  • 可以证明这个property
    • Raft 选举时会检查Log的是否outdated，只有最新的才能当选Leader
    • 选举需要多数派投票，而commited log 也已经在多数派中（必有overlap）
    • 新Leader一定持有commited log，且Leader 永远不会overwrite log

3.10.3 Raft 安全性验证

  • 真的安全吗
    • Raft 使用TLA+进行了验证
      • 形式验证（Formal Method）以数学的形式对算法进行表达，由计算机程序对算法所有的状态进行遍历

image.png

4.实现细节以及未来

4.1案例-KV

  • 利用Raft 算法，重新打造我们的KV

image.png

回顾一下一致性读写的定义

  • 方案一：

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

  • 方案二：

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

  • 方案三：

    • 写Log 被状态机apply，返回给client
    • 读操作直接读状态机
    • 优化读时延

  • Raft 不保证一直有一个leader

    • 只保证一个term至多有一个leader
    • 可能存在多个term的leader

  • Split brain

image.png

  • 确定合法的Leadership
    • 方案一：
      • 通过一轮Heartbeat 确认Leadership（获取多数派的响应）
    • 方案二：
      • 通过上一次Heartbeat 时间来保证接下来的有段时间内follower 不会timeout
      • 同时follower 在这段时间内不进行投票
      • 如果多数follower 满足条件，那么在这段时间内则保证不会有新的Leader产生
  • 结合实际情况选择方案二或方案三
    • 取决于raft的实现程度以及读写的情况

image.png

  • 多个副本只有单个副本可以提供服务
    • 服务无法水平拓展
  • 增加更多Raft组
    • 如果操作跨Raft组

image.png

4.2 回到共识算法

  • Raft：关于Log
    • 论文中就给出的方案，当过多的Log占用后，启动snapshot，替换掉Log
    • 如果对于持久化的状态机，如何快速的产生Snapshot
    • 多组Raft的应用中，Log如何合流
  • 关于configuration change
    • 论文中给出的 joint-consensus 以及单一节点变更两种方案

image.png

  • Raft是正确的，但是在工程世界呢？
    • 真实世界中不是所有的错误都是完美fail-stop的
    • cloudflare的case，etcd在partial network下，outage了6个小时

image.png

  • 高性能
    • 数据中心网络100G，时延约为几个us
    • RDMA 网卡以及 programable switch 的应用
    • 我们想要的是：us级别的共识，以及us级别的容错
    • HovercRaft
      • P4programable switch:IP multicast
    • Mu
      • Use one-sided RDMA
      • pull based heartbeat instead of push-based.

image.png

image.png

  • 多节点提交（Leaderless）
    • 节点跨地域，导致节点间的RTT（Round Trip Time）很大
    • EPaxos
      • 使用了冲突图的方式来允许并行Commit
      • 不冲突的情况下1RTT提交时间

4.3 共识算法的未来

  • Raft Paxos 相互移植
    • Raft有很多成熟的实现
    • 研究主要关注在Paxos上
    • 如何关联两种算法
      • On the Parallels between Paxos and Raft，and how to Port Optimizations
      • Paxos vs Raft:Have we reached consensus on distributed consensus？
  • 共识算法作为一个系统
    • 多数分布式系统都选择共识算法作为底座
    • 不同一致性协议有不同的特性
    • Virtual consensus in delos
      • 对外暴露一致性的LOG作为借口
      • 内部对于LOG可以选择不同的实现
avatar
文章
阅读
粉丝