Paxos算法1-算法形成理论

 Paxos算法的难理解与算法的知名度一样令人敬仰，从我个人的经历而言，难理解的原因并不是该算法高深到大家智商不够，而在于Lamport在表达该算法时过于晦涩且缺乏一个完整的应用场景。如果大师能换种思路表达该算法，大家可能会更容易接受：

• 首先提出算法适用的场景，给出一个多数读者能理解的案例
• 其次描述Paxos算法如何解决这个问题
• 再次给出算法的起源（就是那些希腊城邦的比喻和算法过程）

Lamport首先提出算法的起源，在没有任何辅助场景下，已经让很多人陷于泥潭，在满脑子疑问的前提下，根本无法继续接触算法的具体内容，更无从体会算法的精华。本文将换种表达方法对Paxos算法进行重新描述。

我们所有的描述都假设读者已经熟读了Lamport的paxos-simple一文，因此对各种概念不再解释。

除了Lamport的几篇论文，对Paxos算法描述比较简洁的中文文章是：http://zh.wikipedia.org/zh-cn/Paxos%E7%AE%97%E6%B3%95，该文翻译的比较到位，但在关键细节上还是存在一些歧义和一些对原文不正确的理解，可能会导致读者对Paxos算法更迷茫，但阅读该文可以快速地对Paxos算法有个大概的了解。

 

1.应用场景

 

（1）分布式中的一致性

Paxos算法主要是解决一致性问题，关于“一致性”，在不同的场景有不同的解释：

• NoSQL领域：一致性更强调“能读到新写入的”，就是读写一致性

• 数据库领域：一致性强调“所有的数据状态一致”，经过一个事务后，如果事务成功，所有的表数据都按照事务中的SQL进行了操作，该修改的修改，该增加的增加，该删除的删除，不能该修改的修改了，该删除的没删掉；如果事务失败，所有的数据还是在初始状态；

• 状态机：在状态机中的一致性更强调在每个初始状态一致的状态机上执行一串命令后状态都必须相互一致，也就是顺序一致性。Paxos算法中的一致性指的就是这种情况，接下来我们会对这种场景进一步讨论。

（2）MQ

假如所有系统的Log信息都写入一个MQ Server，然后通过MQ把每条Log指令发异步送到多个Log Server写入文件（写入多个Log Server的原因是对Log文件做备份以防数据丢失），则所有Log Server上的数据肯定是一致的（Log内容及顺序完全相同），因为MQ本身就有排序功能，只要进了Q数据也就有了序，相当于编了全局唯一的号，无论把这些数据写入多少个文件，只要按编号，各文件的内容必定是一致的，但一个MQ Server显然是一个单点，如果宕机，会影响整个系统的可用性。

 

（3）多MQ

要解决MQ单点问题，首选方案是采用多个MQ Server，即使用一个MQ Cluster，客户端可以访问任意MQ Server，不同的客户端可能访问不同MQ Server，不同MQ Server上的数据内容、顺序可能不一致，如果不解决这个问题，每个MQ Server写入Log Server的内容就不一致，这显然不是我们期望的结果。

 

（4）NoSQL中的数据更新

一般的NoSQL都会通过数据复制的形式保证其可用性，但客户端对多数据进行操作时，可能会有很多对同一数据的操作发送的某一台或几台Server，有可能执行：Insert、Update A、Update B....Update N，就一次Insert连续多次Update，最终复制Server上也必须执行这一的更新操作，如果因为线程池、网络、Server资源等原因导致各复制Server接收到的更新顺序不一致，这样的复制数据就失去了意义，如果在金融领域甚至会造成严重的后果。

 

上面这些不一致问题性正是Paxos算法要解决的，当然这些问题也不是只有Paxos能解决，在没有Paxos之前这些问题也得到了解决，比如通过使用双Ma