关于Paxos算法的一些读后感(一)

Paxos据说是一个相当难以理解的算法，自己读了几遍，对于作者的每一个步骤意图一知半解，以下内容，大概是关于paxos算法的一个介绍，我不想大段大段的摘抄，或者去论述Paxos的意义，掉书袋。从一个程序员的角度，力求用最简单的语言把它叙述清楚，毕竟，如果能说清楚，对于自己来说，就是一个进步了。

Terminologies

力求简单明了，所以在此定义一些接下来会用到的一些词汇或者概念

1.Peer: 整个算法中涉及到的节点，无论是所谓的Proposer还是Acceptor，他们都是Peer

2.Majority Consensus: 本文指大部分的一致性，假如100个Peer，其中有严>1/2（50）Peer都choose了一个suggestion，则达到了Majority Consensus

3.Suggestion: 可以指代一个操作，可以指一条日志，或者简单的一个值，一个Suggestion包含一个Id和一个value，即(id,value)pair

4.Chosen: 针对Suggestion而言，如果一个suggestion被一个Peer choose，这个Peer便不能够再chose别的suggestion

5.Accept: 针对Suggestion而言，如果一个suggestion被一个Peer accept，可以理解成如果Peer没有发现更好的Suggestion，那么当前Suggestion会被Chosen

6.Accept != Choosen.  Accept表明一个Suggestion候选，Choosen表示一个Suggestion中标~

背景

1.Paxos解决的是Majority Consensus的问题，也就是说，在Peer propose suggestion，和Acceptor accept/choose suggestion的过程中，多余百分之50的Peer会最后choose同一个suggestion，至于其他Peer，他们也许choose的是另外的suggestion，他们是否要和大部分统一，如何统一，何时统一，这里不做讨论

2. Paxos与其说是一种算法，倒不如说是一种指导思路，所以灵活性相当大，下面的几个步骤，和每个步骤的内容，都是我根据自己的理解写的，也许和别人家的不太一样

过程

1.Permission Request（一些Peer发送请求说，我想要提意见）

目的：Proposer想要提出Suggestion，但是在真正的Suggest之前，他们需要获得Acceptor的许可

发起人：Proposer

请求对象：Acceptor

结果：Proposer将要提出的Suggestion的Id放在Request里，发给所有Acceptor

总结起来，就是我想要提意见！但是我要先提出申请，向在座各位表明我想提意见。我的申请被在座各位Accept以后，我才可以提出我的意见，至于意见会不会被在座Chosen，这不是这个阶段我需要考虑的，我甚至这时候连我的意见的内容都不告诉你，我只告诉你意见的Id，屌不屌！

2.Permisson Granted（另一些收到某些人想要提意见的申请，并依据一定的规则回复）

目的：Acceptor收到Permission Request以后，需要对这个Permission  Request做出回应(Accept or Not)

发起人：Acceptor（这个阶段中Acceptor还没有Choose过Suggestion, Acceptor收到了Permission Request请求）

回复对象：Proposer

结果：(我=Acceptor)

• 好的，我Accept Proposer想要提意见的申请（满足下面的条件之一即可）；
  • 这个Permisson Request是我（Acceptor）收到的第一个Permission Request 请求 
  • 这个Permisson Request不是我（Acceptor）收到的第一个Permission Request 请求， 在这个请求之前，我已经Accept过别的请求啦，但是如果这个请求中包含的Suggestion Id比我之前Accept过的请求的Id更大
• 不，我并不Accept你想提意见的申请；
  • 这个Permisson Request不是我（Acceptor）收到的第一个Permission Request 请求， 在这个请求之前，我已经Accept过别的请求啦，并且这个请求中包含的Suggestion Id比我之前Accept过的请求的Id更小
  • 我已经choose了一个value啦

选择其一进行回复（大多数论文里，说如果不同意的话，就不回复了，其实回复不回复都可以的）

发起人将结果返还给回复对象，如果结果是接受，Acceptor还将保存这个Permission Request里面附带的Suggestion Id

总结起来，Acceptor Accept 某个Proposer提出的Permisson Request的标准就是:  1.Acceptor总会Accept他收到的第一个Permission Request请求   2.若Acceptor已经Accept过别人的请求，那么对于新的请求，对比一下其中包含的Suggestion Id，如果新的请求中的更大，那么也要接受！3.这一步做出的决定是Accept！！！！不是Choose！！！！

3.Suggestion making（第一步的申请被批准啦，可以开始提出Suggestion啦）

目的：Proposer，在第一步中发出的Permisson Request请求收到了很多Accept回复，且Accept回复的个数占了所有负责Acceptor 的大多数之后，开始提出Suggestion

发起人：Proposer

请求对象：Acceptor

注意，在第一步里面，Proposer说了要提出一个Suggestion，并且在Request中放入了Suggestion的Id，至于Suggestion真正的内容（value）并未提及。Suggestion的内容具体是什么，将在这一步根据一定的规则决定，然后发出。规则如何，容后再说。

4.Suggestion Chosen（那些收到某些人想要提意见的人，依据一定规则决定的最终是否采纳意见）

• 目的：Acceptor最终将决定，接受哪一个suggestion

发起人: Acceptor

内容：Step 3里面的Suggestion

结果：(我=Acceptor)

• 好的，我Acceptor接受此Suggestion
  • 这个Suggestion的Id等于我Acceptor保存的Suggestion Id
• 不我，我不接受此Suggestion
  • 这个Suggestion的不等于我Acceptor保存的Suggestion Id 

注意，Acceptor一旦Choose了某个Suggestion的Value，那么这个Acceptor便不会再Choose别的Value，相当于，Acceptor被锁定了

过程的内容:

1.Permission Request

message: {id: message-id, value: 将要发布的suggestion的suggestion-id}

2. Permission Granted:

• 第一步的suggestion-id被accept  
  • 如果Acceptor没有Accept过任何Permission Request
    • Permission Granted: {id: message-id, value: null}
  • 如果Acceptor Accept过别的Permission Request，但是记录的Permission request的suggestion id比当前的Permission Request包含的Suggestion Id 小
    • Permission Granted: {id: message-id， value: 记录的Suggestion Id }

message返回以后，Acceptor会修改自己记录的suggestion Id

• 第一步的suggestion-id被deny 
  • 如果Acceptor Accept过别的Permission Request，并且记录的Permission request的suggestion id比当前的Permission Request包含的Suggestion Id 大
    • Deny: {id: message-id， value: 记录的Suggestion Id }

3. Suggestion Making

Propser会收到很多来已于Acceptor的Message，

• 如果大于半数的message都是Permission Granted Message
  • 如果所有的Permission Granted Message都是{id: message-id, value: null}, 则Propser在这一步发出的message为
    • suggestion message: {id: 第一步中的value的值（将要发布的suggestion的suggestion-id）， value： proposer自己决定value的值}
  • 但凡Permission Granted Message中包含 {id: message-id, value: 记录的Suggestion Id }
    • suggestion message: {id: 第一步中的value的值（将要发布的suggestion的suggestion-id）， value: 值*}
      • 这里的值*： Proposer收到的所有的 {id: message-id, value: 记录的Suggestion Id }消息中，Suggestion Id最大的那个suggestion的值-如果收到了{id：2，value：3, suggestion-value: ** }， {id： 3， value：10, suggestion-value: **}， {id： 5， value：null, suggestion-value: null}，则这里的值将会是suggestion id = 10的那个suggestion的value
• 如果大于半数的message都是Deny Message
  • Proposer重复第一步，并且 最好value选取大于Deny Message中最大的value

• Accept过别的Permission Request，并且记录的Permission request的suggestion id比当前的Permission Request包含的Suggestion Id 大
  • Deny: {id: message-id， value: 记录的Suggestion Id }

4.Accept (类似于步骤2)

 

写在后面的话哦，第一章，先弄明白，这个算法的过程是什么，至于为什么，等我以后再写。。其实我自己也还没吃透，加上自己也很懒，就下次再写！