paxos算法——此生

Paxos

定义2.1  票：即弱化形式的锁。它具有下面几个性质：

• 可从新发布：服务器能够从新发布新票，即便前面发布的票没有释放。
• 票能够过时：客户端用一张票来给服务器发送命令请求时，只有当这张票是最新的票才会被服务器接受。

从票的性质中咱们能够得出以下结论：

• 客户端崩溃致使死锁的问题获得解决，由于服务器能够发布新票，从而不影响其余客户端。
• 票能够避免死锁的问题，那么如何实现票，可使用计数器来实现，客户端向服务器获取票的请求时，咱们给计算器加1. 当客户端下次再拿服务器端分配的票时发送命令请求，服务器端能够根据该票与服务器端的票（计数器）比对来判断其是否过时，

算法2.1   朴素的基于票的协议。

  阶段1

1: 客户端向全部的服务器请求一张票

  阶段2

2:  if 收到过半数服务器的回复  then

3:        客户端将得到的票和命令一块儿发送每一个服务器

4：      服务器检查票的状态，若是票仍然有效，则存储命令并给客户端一个正反馈信息

5：else

6:         客户端等待，并从新进入阶段1

7:    end if

    阶段3

8:    if 客户端从过半数服务器处获得了正反馈  then

9:              客户端告诉全部的服务器执行以前存储的命令

10:   else

11:          客户端等待，而后从新进入阶段1

12:   end if 

该算法是有问题的：

• 假设客户端  u1 是第一个得到大多数服务器正反馈的客户端。可是u1很慢，在告知全部服务器执行先前存储的命令（c1）（算法第9行命令）以前，这时u2更新了部分服务器的票以及存储了c2命令，这时，执行第9行命令时会致使数据不一致的状态，部分服务器执行了命令c1，部分服务器执行了命令c2。
• 如何解决以上的问题呢？若是在阶段1中服务器不但发布票还发布服务器存储的命令，当u2更新票时，发现服务器端已经存储了命令c1，这时，客户端u2能够不要求服务器存储命令c2,而是继续存储命令c1，这样两个客户端都尝试执行相同的命令c1，谁先谁后则不在重要。
• 其次不一样的服务器可能存放不一样的命令。在阶段1中。客户端须要支持哪个命令？1.对于得到大多数服务器端都支持的命令，则支持改命令，不然，选择存储票据最新的命令。票可使用计数器变量来代替，最新的票，则计数器值最大。
• 每一个服务端都本身生产票号的话，则最新的票号不必定是最大的。服务器端的票号会存在重复的状况。若是由客户端本身来生成票号，这个问题能够获得解决。
• 咱们须要全局一致的票号，所以不能由每一个服务器本身维护一个本地的计数器来产生票号。一个巧妙的办法是让客户端本身来生成票号t，而后向全部的服务器请求编号为t的票。服务器在收到请求后，先将t和它本地的计数器进行比较，只有t大于本地的计数器时，服务器才会发布票（编号为t），同时将其本地计数器的值更新为t。这样就能够获得全局一致的产生票号的方法。这就是下面paxos算法所使用的方案。

算法 2.2  Paxos

客户端（提案者）                                                                                    服务器（接收者）

 初始化………………………………………………………………………………………………………………………………………………………………

  c ——等待执行的命令                                                                                T(max) = 0  —— 当前已发布的最大票号

  t = 0  —— 当前尝试的票号                                                                         C = NULL   ——  当前存储的命令

                                                                                               　              T(store) = 0  ——  用来存储命令C的票

 阶段1……………………………………………………………………………………………………………………………………………………………………

 1：t = t + 1

 2: 向全部服务器发消息，请求获得编号为t的票

                                                                                                                3:  if t > T(max)   then 

                                                                                                                4:         T(max) = t

                                                                                                                5:          回复ok(T(store),C)

                                                                                                                6: endif

阶段2………………………………………………………………………………………………………………

 7: if 过半服务器回复ok  then

 8:     选择T(store)值最大的(T(store),C)

 9:     if  T(store) > 0  then

10:             c = C

11:    endif

12:    向这些回复了 ok的服务器发送消息：propose(t,c)

13:    endif

                                                                                                                 14:  if  t = T(max).   then

                                         　　　　　　　　　　　　　　　　　　                  15:         C = c

　　　　　　　　　　　　　　　　　　　　　　　　　　　　                             16:         T(store) = t

　　　　　　　　　　　　　　　　　　　　　　　　　　　　                             17:          回复：success

　　　　　　　　　　　　　　　　　　　　　　　　　　　　                             18:  endif

阶段3 ………………………………………………………………………………………………………………

 19:  if  过半服务器回复  success  then 

 20：     向每一个服务器发送消息：execute(c)

 21: endif 

• 与前面算法不一样的是，这个算法没有明确客户端从哪一个位置能够跳转到阶段1并开始新的尝试。实际上客户端能够在算法的任何位置取消当前尝试并开始新的一轮的尝试。
• 在阶段1 与阶段2 中若是票已通过期，可让服务器发送负的反馈，这样能够提升性能，没必要等到过半服务器发送正反馈超时而从新尝试。
• 连续两次尝试之间的等待时间能够随机函数肯定，能够缓和不一样结点之间的竞争。