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

121 阅读4分钟

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

基础知识点

  • 远程过程调用(RPC)

    • 分布式系统中通常将不同组件,或者不同节点的交互使用 RPC 的方式进行封装,在调用方的视角一次远程过程调用不需要关心如何对请求和响应进行编码,也不用关心具体的网络传输。
  • 状态机(State Machine)

    • 一种编程架构,状态机只取决于当前的状态与的输入,确定下一个状态
  • 并发/并行

    • 并发:多个任务可以在重叠的实践中启动、运行、完成,并发不一定意味着并行,可以通过切换的方式做到在一个执行单元上实现并发任务
    • 并行:真正的多个任务同时运行,如多核CPU
  • 容错

    • 通常指一种软件架构,架构可以容许一定数目的节点失效,同时保证系统正常或降级运行
  • 高可用

    • 指系统可以达到较高的可用时间,如系统保证一年中只有若干分钟不可用,通常以 SLA(Service-level agreement) 进行描述,容错架构是实现高可用系统的一种方式

一、分布式系统

分布式系统是一个建立在网络之上的软件系统,正是因为软件的特性,所以分布式系统具有高度的内聚性和透明性。

1、分布式系统面临的挑战:

  • 数据规模越来越大

  • 服务的可用性要求越来越高

  • 快速迭代的业务要求系统足够易用

2、理想中的分布式系统:

  • 高性能:可扩展、低时延、高吞吐(能否灵活的扩展处理容量、同时兼顾低时延和高吞吐)

  • 正确:一致性、易于理解

  • 可靠:容错(一种架构上的操作)、高可用

二、一致性与共识算法

因为现如今对分布式系统的要求越来越高,所以一台机器是负担不了巨大的需求。

1、复制

这是一台机器的处理过程,于是就通过复制操作,如果两个副本都能接受请求。

image.png

那么主副本会定期拷贝全量数据到从副本 主副本也会拷贝操作到从副本

image.png

2、复制操作

  1. 主副本把所有的操作打包成Log

    所有的Log写入都是持久化的,保存在磁盘上

  2. 应用包装成状态机,只接收Log作为Input

  3. 主副本确认Log已经成功写入到副本机器上,当状态机apply后,返回客户端

image.png

3、读操作

  1. 方案一:直接读状态机,要求写操作进入状态机后再返回client

  2. 方案二:写操作复制完成后直接返回,读操作Block等待所有pending log进入状态机

image.png

4 共识算法

共识算法就是所有人都认同的算法。

  • 应用层面不同的一致性,都可以用共识协议来实现
  • 简单的复制协议也可以提供线性一致性
  • 弱一致性往往可以使用相对简单的复制算法实现

三、一致性协议案例:Raft

1、背景

  • 2014年发表

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

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

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

2、Raft日志复制和从节点失效

image.png

以上是日志复制,以下是从节点失效

image.png

Raft Term:

  1. 每个Leader服务于一个term
  2. 每个term至多只有一个leader
  3. 每个节点存储当前的term
  4. 每个节点term从一开始,只增不减
  5. 所有rpc的request reponse都携带term
  6. 只commit本term内的log

Raft主节点失效:

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

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

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

    • raft在检查是否可以投票时,会检查log是否outdated ,至少不比本身旧才会投给对应的Candidate
  • 如果多数派节点投给它,则成为该term的leader

Raft Leader failure

image.png

Raft安全性-同Term:

  • 对于Term内的安全性

    • 目标:对于所有已经的commited的<term,index>位置上至多只有一条log
  • 由于Raft的多数派选举,我们可以保证在一个term 中只有一个leader。

    • 我们可以证明一条更严格的声明:在任何<term,index>位置上,至多只有一条log Raft安全性-跨Term:
  • 对于跨Term的安全性

    • 目标:如果个log被标记commited,那这个log一定会在未来所有的leader中出现Leader completeness
  • 可以证明这个property

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