2021-08-08

Paxos - 分布式一致性协议

对论文的总结

Paxos要解决的问题

用来确定一个不可变变量var的取值。

Paxos适用的范围

容忍任何非Byzantine的失败

方案设定的角色

  • proposers: 负责提议 (如proposer角色的server发送 propose(var, v))
  • acceptors: 负责就某个提议达成决议 (如acceptor角色的server对propose的响应为<ok, f> or )
  • learners: 负责获取已经达成决议的值
    一个节点可以扮演多种角色
    对于如何确定一个不可变变量的取值,有如下可能的几种方案。

具体方案

两个阶段的算法

  • 阶段一:prepare request
    • 一个proposer发送proposal(n) 请求到大多数的acceptors;
    • acceptors接受到propose请求后:
      • 如果acceptor已接受到比n大的number,则ignore此条请求;
      • 否则,发送<promise, proposal with highest-number>
  • 阶段二:accept request
    • proposer接收到来自大多数acceptors对于prepare requests的回应,则给这些response的acceptors发送 accept request
    • proposal(n ,v) 其中v是回应中最高number的proposal的值,或者,如果回应中没有proposal, 可以是任何value。

paxos两阶段协议的推导过程(如何快速对一件事达成一致,这件事到底是什么不重要)

论文中描述的paxos要解决的问题

如在paxos论文中提到,
Assume a collection of processes that can propose values. A consensus algorithm ensures that a single one among the proposed values is chosen.

为了解决这个问题,一致性协议需要满足的条件有:

  • Safety (Consistency)
    • Only a value that has been proposed may be chosen, (只有提出的值,才能被选取)
    • Only a single value is chosen, and (只有唯一的值被选取)
    • A process never learns that a value has been chosen unless it actually has been. (只有被选取的值。learner才能学习到它被选取)
  • Liveness (活性Progress) (as long as majority of servers up and communicating with reasonable timeliness):
    • Some proposed value is eventually chosen.
    • if a value is chosen, servers eventually learn about it.

论文中提到的方案

一 个acceptor

Acceptor总是选择第一个接收到的proposed value。
问题:这个Acceptor挂掉,整个系统就不可用,也就是单点故障。

多个acceptor方案的推导过程

如果acceptor接受到accept request(number n),它接受这个proposal,除非它已经对一个number大于n的prepare request作了响应。

  1. A proposer chooses a new proposal number n and sends a request to each member of some set of acceptors, asking it to respond with: (a) A promise never again to accept a proposal numbered less than n, (对应上面的promise)and (b) The proposal with the highest number less than n that it has accepted, if any. I will call such a request a prepare request with number n.

  2. If the proposer receives the requested responses from a majority of the acceptors, then it can issue a proposal with number n and value v, where v is the value of the highest-numbered proposal among the responses, or is any value selected by the proposer if the responders reported no proposals.
    大多数的acceptors接受了一个值,这个值就被选中。
    为了容忍发送消息过程产生的各种错误,我们想让一个value被选中,即使仅有一个proposer propose了这个值。这就产生一个一个需求

P1. An acceptor must accept the first proposal that it receives

但是这个需求又产生一个问题:可能同时有不同的proposers propose values,每一个acceptor接收了一个value,但是没有一个value被大多数acceptors接收。

然后P1 和大多数acceptors接受了一个value,此value才能算真正被接收的要求=> an acceptor must be allowed to accept more than one proposal
=> assign a (natural) number to each proposal. => proposal(number, value) => to prevent confusion, 不同的proposals有不同的numbers。=>这个怎么达到,依赖实现

一个proposal被大多数acceptors接受,proposal的value才可以被选中。

可以有多个proposal被选中,但是我们要保证所有被选中的proposal的value都相同。=>

P2. If a proposal with value v is chosen, then every higher-numbered proposal that is chosen has value v.

P2a . If a proposal with value v is chosen, then every higher-numbered proposal accepted by any acceptor has value v.

增强P2a,得到P2b

P2b . If a proposal with value v is chosen, then every higher-numbered proposal issued by any proposer has value v.

如何满足P2b

需要维持下面的不变式

P2c . For any v and n, if a proposal with value v and number n is issued, then there is a set S consisting of a majority of acceptors such that either (a) no acceptor in S has accepted any proposal numbered less than n, or (b) v is the value of the highest-numbered proposal among all proposals numbered less than n accepted by the acceptors in S.

P2c决定了如果一个proposer想发送一个number为n的proposal,首先必须学习比n小的最大的proposal(如果有的话,此proposal已经或者正要被大多数的acceptos接收。如果已经被接收,那就比较容易了,如果没有,预测后面是否被接收就难了。)=>

promise: there won’t be any such acceptances. =>

the proposer requests that the acceptors not accept any more proposals numbered less than n. =>

  1. A proposer chooses a new proposal number n and sends a request to each member of some set of acceptors, asking it to respond with: (a) A promise never again to accept a proposal numbered less than n, (对应上面的promise)and (b) The proposal with the highest number less than n that it has accepted, if any. I will call such a request a prepare request with number n.

  2. If the proposer receives the requested responses from a majority of the acceptors, then it can issue a proposal with number n and value v, where v is the value of the highest-numbered proposal among the responses, or is any value selected by the proposer if the responders reported no proposals.

=>

P1a . An acceptor can accept a proposal numbered n iff it has not responded to a prepare request having a number greater than n.

optimization:

ignore a prepare request: number 为n的proposal(比n大的已经被接收,和已经被接收的)的prepare requests。=>

一个acceptor需要记住的内容(即使失败后重启):

  • 已经被接收的最高number的proposal
  • 已经响应的prepare requests中的最高的number

两个阶段的算法

optimization

Therefore, if an acceptor ignores a prepare or accept request because it has already received a prepare request with a higher number, then it should probably inform the proposer, who should then abandon its proposal. This is a performance optimization that does not affect correctness.

Implement

Because the state machine is deterministic, all the servers will produce the same sequences of states and outputs if they all execute the same sequence of commands.

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值