共识算法:Paxos 算法

骚铭

1. 目录

[TOC]

2. 共识问题 1

  • 什么是共识问题?
    粗略地说,该问题是在一个或多个进程提议了一个值应当是什么后,使进程对这个值达成一致协定。
  • 解决什么问题?

    • 在一个计算机提议一个动作后,控制引擎的所有计算机要决定“继续”还是“放弃”。
    • 在互斥中,进程对哪个进程可以进入临界区达成协定。
    • 在选举中,进程对当选进程达成协定。
    • 在全排序组播中,进程对消息传递顺序达成协定。

2.1 一个例子:问题描述 2

假设有两支(或多支)军队,他们必须做到同时进攻或同时防守,否则就会失败。所有军队组成一个系统,他们必须共同动作。问题是,如何让他们步调一致?

现在不妨把军队看做”进程“,把进攻或防守看做一个变量”行动“。

  • 单机系统中,这个问题很容易解决。用一个互斥量就搞定了,类似于多线程。
  • 分布式系统中,这个问题就麻烦啦。假设每个进程都在不同的服务器上,他们就无法通过共享内存达到同步。如果进程是军队的话,军队之间只能通过通信兵来进行通信(消息传递)。基于消息传递的分布式军队系统会有这些问题:

    1. 如何确定另一支军队是否被干掉?(服务器崩溃)
    2. 如何知道通信兵是否被杀死(消息丢失)或久久未到达其他军队(延迟不可预知)?
    3. 如果马路等通信信道被切断怎么办?(网络分割)

2.2 另一个例子

在一个分布式数据库系统中,如果各节点(server,或进程)的初始状态一致,每个节点都执行相同的操作序列,那么他们最后能得到一个一致的状态。为保证每个节点执行相同的命令序列,需要在每一条指令上执行一个“一致性算法”以保证每个节点看到的指令一致,是分布式计算中的重要问题。

3. Paxos 的一致性原则 3

  • Safety (坏的事情一定不会发生)

    1. 只有被提议的值才会被选择;
    2. 只能有一个值被批准,不能出现第二个值把第一个覆盖的情况;
    3. 每个节点只能学习到已经被批准的值,不能学习没有被批准的值 。
  • Liveness (好的事情最终一定会发生)

    1. 最终会批准某个被提议的值;
    2. 一个值被批准了,其他进程最终会学习到这个值。

Paxos 只保证Safety,而不能保证Liveness。

4. Paxos算法描述

4.1 假设 3

每个server都可以担任三种角色:提案者(Proposer)、接受者(Acceptor)、学习者(Learner)。提案者负责提出提案(proposal),接受者负责通过提案,而学习者负责更新提案。

每个提案都会被分配一个自然数$n$作为ID,以及一个需要提出的值$v$。

4.2 选择一个值(Choosing a Value) 3

阶段一
a. 提案者选择一个提案(proposal)编号$n$,向接受者多数派组播一个prepare请求。
b. 如果一个接受者收到一个prepare请求,并且编号$n$是所有他已经通过的prepare请求中最大的,那么他会同意这个新的prepare请求,并承诺不会再同意任何比$n$小的prepare请求和accept请求。

阶段二
a. 如果提案者收到一个接受者多数派的回应prepare_ok(n,na, va),那么他就选出最大的$n_a$所对应的$v_a$。或者,若所有回应中$v_a$都为空,也就是还没有同意过任何提案,那么就选择自己的$v$。然后发送accept(n,v)请求。
b. 如果一个接受者收到一个 accept(n,v) 请求,并且$n$大于所有它 prepare 过的$n_p$,那么他就接受这个$v$,然后回复 accept_ok(n)

4.3 学习一个值(Learning a Chosen Value)

当一个提案被多数派通过,这提案者就向所有人(servers)发送decided(v),贯彻与落实这个$v$。

4.4 Paxos伪代码4

# Proposer
proposer(v):
    while not decided:
        n = heigher(N[:])  # 尝试分配一个当前最大的n值给这个proposal
        send prepare(n)     # 向所有acceptor发送prepare request
        # 若大部分返回ok:
        if prepare_ok(n, na, va) from majority:
            # 从{na...}中选出最大的那个和对应的va,令v=va;否则,就选自己的v
            v = va with heighest na; otherwise choose its own v
         
            send accept(n, v) to all  # 向所有acceptor发送accept request
            if accept_ok(n) from majority:
                send decided(v) to all  # 决定v并通知所有成员

# Acceptor
acceptor state on each node (persistent):
    np      # 最大的promise值
    na, va  # 最大的accepted值
    
    prepare(n) handler:
        if n > np:
            n = np
            send prepare_ok(n)  # 承诺不再接受任何比 n 小的proposal
        else:
            send prepare_reject
    
    accept(n, v) handler:
        if n >= np:
            na = n
            va = v
            send accept_ok(n)
        else:
            send accept_reject

直观理解

这里写图片描述
这里写图片描述

容错性分析(Fault tolerant) 5

究竟Paxos是如何保证一致性的呢?例子如下。

3.1服务器崩溃(crash)

若有 $2f+1$ 台服务器,则最多可以容忍 $f$ 台服务器崩溃。下面举一个简单的例子,假设一个分布式系统由5个servers组成,其中2个在任意时刻崩溃。存在两种情况:1.AcceptorLearner崩溃了;2.Leader崩溃了。

3.1.1. Acceptor 崩溃

如下图所示,S1Leader,当其发出Accept请求时,S4S5崩溃了。但是S1S2S3仍然构成多数派,所以$v$仍然可以被决定下来。
acceptor crash

3.1.2. Leader 崩溃

Learder崩溃要稍微麻烦一点。首先要有错误检测,发现leader S1挂了。然后,因为没有leader了,所以要重新选举。如图,S1S5挂了,但是S2S2S3仍然构成多数派。S2发出prepare请求,S3S4返回最近接受的$v_1$,$v_1$再次被S2请求接受。于是$v_1$还是成功被决定下来了。
leader crash

3.2 网络分割(network partitioning)

另一种常见错误是网络分割。如下图所示,S1S2S3S4S5之间的通信被断开,分成了两个子网络。在这种悲催的情况下,系统仍然可以达成共识。
一旦发生分割,通过错误检测是可以发现的,例如超时。然后多数派一方就会进行重新选举,如图,S3成为新leader。系统又可以正常运作了。
不过,问题还没完。如果网络通信在某一时刻又恢复正常,分布式系统中就会同时存在两个leader!Paxos还可以保证共识吗?是可以的。因为$n_2>n_1$,S3~S4 已经承诺不再接受比$n_2$小的提案了。所以老leader S1的提案$(n_1,v_1)$会被拒绝,而S3的提案$(n_2,v')$会获得通过。
network partitioning

3.3 消息丢失(message lost)

由于网络层是不可靠的,消息丢失和延时是无法避免的。应对这类错误的主要方法还是重传。

参考文献


  1. 分布式系统:概念与设计, 共识和相关问题 系统模型和问题定义
  2. 分布式系统:概念与设计, 共识和相关问题 同步系统中的共识问题
  3. Lamport,L: Paxos Made Simple. ACM Trans. on Comp. Syst.
  4. MIT 6.824 Lab 3: Paxos-based Key/Value Service
  5. Tutorial Summary: Paxos Explained from Scratch
阅读 426
1 声望
0 粉丝
0 条评论
你知道吗?

1 声望
0 粉丝
宣传栏