Paxos 算法 的理解

Paxos 算法

首先，mark一个网上的一个视频，可以有一个初步的了解，虽然可能不完善

http://www.tudou.com/programs/view/e8zM8dAL6hM/?qq-pf-to=pcqq.group

1.解决的问题

分布式系统采用多副本的形式进行存储，必须保证每台服务器上的副本都是一样的，才能保证数据一致性。

所以多个用户分别向多台服务器上提交请求时，最终的每台服务器上的副本都是一致的。

比如：用户A向服务器A提交了"update name=‘2’ where id=1"，用户B向服务器B提交了"update name='name2' where id=1" 服务器必须决定先执行哪一条语句，然后让其他服务器都执行这条语句，才能保证一致性，且每次只能决定出一条需要执行的语句（另一条会失败）。

paxos算法就是为了决定第n次操作的取值。

2.概念

Proposer

Proposer可以简单的理解成前面说的用户，他会向Acceptor提交请求。

Acceptor

Acceptor会接收Proposer的请求，并且判断是否应该接受它。

3.过程

3.1）Proposer 提交数据value时，都会带上一个id

• 这个id不会冲突，生成规则可以是n*count+index，其中n是第n次需要确定的操作，count是Proposer总数，index是给Proposer分配的序号

3.2）Proposer 分两阶段向Acceptor提交

第一阶段：Propose(id)。

有两个任务：

3.2.1.调用Propose(id)，向Acceptor获取此id的访问权

3.2.2.根据Acceptor的返回值，确定需要提交的数据value.

你可能会问，要提交的数据不就是我想提交的值value吗，为什么还需要从Acceptor获取呢？ 是的，Propose确实有一个想要提交的value，但是他第二阶段不一定会提交这个value，为什么呢？咱们往下看第一阶段的具体过程。

• 调用Propose(id)访问Acceptor时，Acceptor的返回值包含三个字段： status：成功失败状态 ok/error。只有当Acceptor判断没有更高的id在这之前提交过来，才会接受这个id id：Acceptor接受的已进入到第二阶段的其他Proposer的id，如果没有则为null（是不是有点拗口，通俗的说就是我执行第一阶段的时候，其他Propersor已经在这个Acceptor上完成第二阶段了） value：Acceptor接受的的进入到第二阶段的其他Proposer的value，如果没有则为null

  a.如果status==error。

    说明已经有更大的id获取到访问权了。则该Propesor没有获取到id在该Acceptor上的执行权，但是Propesor还是有可能进入第二阶段。
    因为判断能否进入第二阶段的条件是：是否有半数以上的Acceptor给我发放了访问权，而不是某一个Acceptor能决定的

  b.如果status==ok,且_value!=null。

    status=ok。说明我没有被拒绝，可能进入第二阶段。注意是可能进入，因为Acceptor有多个，Proposer需要收到大多数的Acceptor的访问权才能进入第二阶段！
    _value!=null。说明已经有其他Proposer进入第二阶段了(即_id和_value不为null)，那我如果进入第二阶段，就会把自己的value换成_value。
        而且只要我向多个Acceptor发送的请求中有任何一个返回值_value不为空，我都需要将value替换成_value。（注意是任何一个！）

  c.如果status==ok,且_value==null。

    说明我成功获取到这个Acceptor的访问权，并且没有其他Acceptor进入第二阶段。那我还有可能进入第二阶段，并有可能在第二阶段提交自己的value。
    注意也是“有可能”
  
    有可能进入第二阶段：当超过半数的Acceptor都发放访问权能进入第二阶段
  
    有可能在第二阶段提交自己的value：只有所有的Acceptor的返回值中_value全部都为空，我才能提交自己的value
    注意：只要我向多个Acceptor发送的请求中有任何一个返回值_value不为空，我都需要将value替换成_value。

  --

    证据在这：“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. ”
  
    看我蹩脚的翻译：
  
    “如果Proposer收到大多数Acceptor的返回值，这个Proposer就能进入第二阶段，提交id是n value是v的提议。
    v必须是这些返回值中id最大的那个提议对应的value，或者所有返回值都为空时自己选择一个value提交。”

总结一下Proposer的第一阶段： Proposer向多个Acceptor提交id，获取访问权

• 如果返回值中status=error，则说明已经有更高的id在这台机器上获取到了访问权
• 如果返回值中status=ok超过半数以上，则获取到了半数以上的访问权，能进入第二阶段
• 如果返回值中_value全部都为空，则我进入第二阶段时，会提交自己的value，否则提交最大的那个_id对应的值_value，即：

第二阶段：Accept(id, value)。

第二阶段是向Acceptor提交value，如果超过半数以上的Acceptor都接受了这个value，则value形成了一个确定性取值。

id：是Proposer自己原本生成的那个id
value：自己原本生成的value或者已经进入第二阶段的最大的_id对应的那个_value。

注意：可能会出现多个Proposer都出现确定性取值的情况，但是多个Proposer形成的确定性取值都是同一个value。

It’s easy to construct a scenario in which two proposers each keep issuing a sequence of proposals with increasing numbers, none of which are ever chosen. 
Proposer p completes phase 1 for a proposal number n1. 
Another proposer q then completes phase 1 for a proposal number n2 > n1. 
Proposer p’s phase 2 accept requests for a proposal numbered n1 are ignored because the acceptors have all promised not to accept any new proposal numbered less than n2. 
So, proposer p then begins and completes phase 1 for a new proposal number n3 > n2, causing the second phase 2 accept requests of proposer q to be ignored. 
And so on.

可以很简单的构造出一个场景，让两个Proposer一直使用不断增大的id循环进行第一阶段提交，但是没有任何一个能成功。
Proposer1 用 n1 完成了第一阶段;
proposer2 用 n2 完成了第一阶段,并且 n2>n1;
Proposer1 的第二阶段肯定会被拒绝,
原因:
既然proposer2也完成了第二阶段,
那肯定有一个半数以上的集合都存储了 proposer2 的n2,
那Proposer1肯定无法在第二阶段得到半数以上的Acceptor的支持.
为什么呢==>
假定Proposer1在第二阶段能得到半数以上的Acceptor的支持,
因为proposer2的第一阶段也得到了半数以上的Acceptor的支持,
所以这两个半数肯定会存在一个公共的Acceptor,这个Acceptor既支持Proposer1 的第二阶段,也支持proposer2的第一阶段.
这显然是不合理的,因为支持了proposer2的第一阶段 则 Acceptor会承诺不再接收比 n2小的 提议,而 Proposer1的n1却刚好比n2小
所以,Proposer1 拿出一个更大的数 n3,来进行第一阶段(其中n3>n2).从而使 proposer2 的第二阶段也失败了.
然后一直这样循环失败!

---

The value is chosen when a large enough set of acceptors have accepted it. How large is large enough? To ensure that only a single value is chosen, we can let a large enough set consist of any majority of the agents. 疑问，P2中反复提到“If a proposal with value v is chosen ”。其他Proposer如何知道value v is chosen呢？ value v is chosen 必须满足 v 被半数以上的acceptor通过,但是只要让通过v的这个acceptor集合中的Acceptor down掉一部分, 其他的Proposer就算请求剩余的所有Proposer，也无法知道 v是否已经被大多数通过了.

那应该如何判断 v is chosen 呢?

假设1.通过取返回值中统计哪些v被大多数Acceptor通过来判断 比如: 有5个Acceptor: a1,a2,a3,a4,a5 v 被 a1,a2,a3 通过了,这时 v is chosen 但是加入这时 a3 down了,只剩下 a1,a2,a4,a5 另一个Proposer1在这时提交 v1,就算Proposer1 提交到所有剩下的4个Acceptor, 也无法从Acceptor的返回结果中发现 v已经被半数以上的Acceptor所接受(因为接受v的3个Acceptor中只剩下 a1,a2) ==>显然通过取返回值中统计哪些v被大多数Acceptor通过的方法不可行。

假设2.假如Proposer通过返回值返回值中不为空的返回值来判断 假如Proposer接收到的返回值只要一个不为空,那我就不再提交自己的,而是提交这个值 貌似可行，但是如果返回值有多个不为空，我应该选择提交哪个呢? 还有其他方式吗?paxos是这样进行判断吗?