分布式一致性

绪论

最近20年的计算机规模的发展飞速，重要的变化是从集中式、单点架构往分布式架构发展，推出诸多的分布式计算和存储，以google mapreduce、bigtable为代表，近20年业内也主要围绕分布式一致性问题做出巨大的努力。本文主要也探讨一致性算法的演变，以及一致性算法介绍等。

架构演变

在集中式存储计算时代，数据规模较小，普遍采用类似mysql之类的数据库存储，在此阶段，大家主要关心的是ACID特性，以B树为代表的存储检索引擎得到了广泛的应用。随着数据获取的容易，大量数据接入，传统的B树索引难以大量数据写入和变更，LSMT为代表的算法在写多读少场景下得到了普遍的应用，典型的有bigtable、hbase等大数据存储，这类系统由于将数据分散在多个节点分散存储节点数据，采用分而治之的方式管理，使得大数据存储难题得到有效的解决，但同时由于多个节点存储数据，因此节点网络分区、节点下线可认为是常态，数据一致性成为这类系统的通病。于是类似CAP(一致性，可用性、分区容忍性）等成为分布式领域经常探讨的话题，数据一致性算法也得到了广泛应用。

算法演变

2阶段提交

两阶段提交协议的流程如下所述：

       准备阶段 协调者向参与者发起指令，参与者评估自己的状态，如果参与者评估指 令可 以完成，则会写 redo 或者 und 日在、（ te Ahea Log 种），然后锁定资源，执 操作，但是并不提交。

      提交阶段 如果每个参与者明确返回准备成功，也就是预留资源和执行操作成功，则协 调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的资源；如果任 个参与者明确返回准备失败， 就是预留资源或者执行操作失败，则协调者向 与者发起中止指令，参与者取消己经变更的事务，执行 nd 日志，释放锁定的资源。

    可以归纳为阶段1：提交事务请求。阶段2：执行事务阶段

优缺点：实现简单，但容易同步堵塞，尤其是网络集群中。

 

3阶段提交

     

        询问阶段：协调者询问参与者是否可以完成指令，协调者只需要回答是或不是，而不 要做真正的操作 ，这个阶段超时会导致中止

      准备阶段 如果在询问阶段所有参与者都返回可以执行操作，则协调者向参与者发 送预 执行请求，然后参与者写 re do undo 日志，执行操作但是不提交操作：如果在询问 段任意参与者返回不能执行操作的结果，则协调者向参与者发送中止请求，这 里的逻 辑与两阶段提交协议的准备阶段是相似的。

      提交阶段：如果每个参与者在准备阶段返回准备成功，也就是说预留资源和执行操 作成 功，则协调者向参与者发起提交指令，参与者提交资源变更的事务，释放锁定的 资源： 如果任何参与者返回准备失败，也就是说预留资源或者执行操作失败，则协调者向 与者发起中止指令，参与者取消已经变更的事务，执行 undo 日志，释放锁定的 资源， 这里的逻辑与两阶段提交协议的提交阶段一致。

归纳为阶段1：can commit。阶段2：precommit。阶段3：doCommit

优缺点：降低了2阶段的堵塞成本，但在precommit阶段，网络分区，存在数据不一致问题

 

paxos算法

 归纳为：（1）提案必须有序递增。（2）必须大多数同意才认为通过

算法解决了2阶段算法无限等待问题，利用大多数同意，解读了分布式单点问题，目前成为主流的一致性算法。

ZAB协议

分为发现，同步，广播3个阶段