是否保证一致性_分布式系统：一致性协议

一致性模型本质上是进程和数据存储之间的协议。 通过一致性模型，我们可以理解和推理分布式系统中数据复制需要考虑的问题和基本假设。 那么，一致性模型有哪些具体的实现呢？ 本文将介绍共识协议实现的主要思路和方法。

什么是共识协议

共识协议描述了特定共识模型的实际实现。 一致性模型就像接口，共识协议就像接口的具体实现。 一致性模型提供了在分布式系统中数据复制期间保持一致性的约束。 为了实现一致性模型的约束，需要通过一致性协议来保证。

一致性协议根据是否允许数据发散分为两种：

可以发现，它们的核心区别在于是否允许多个节点发起写操作。 单主协议只允许主节点发起写操作，因此可以保证操作的顺序和更强的一致性。 多主协议允许多个节点发起写操作，因此不能保证操作的顺序，只能实现弱一致性。

值得注意的是，共识协议的分类方式有很多种，主要是从哪个角度来分类。 另一种常用的分类方法是基于同步/异步复制，这里不再赘述。 下面对单主协议和多主协议进行总体分析。 限于篇幅，我们将不对协议进行详细介绍。

单一主协议

单主协议的共同点是使用一个主节点负责写操作，可以保证全局写的顺序一致性。 它还有一个名字叫音序器，很形象。

主备复制

主从复制可以说是最常用的数据复制方式，也是最基本的方式。 许多其他协议都基于它的变体。 主备复制要求所有写操作都在主节点上进行，然后将操作的日志发送给其他副本。 可以发现，因为主从复制有延迟，所以达到了最终一致性。

主备复制的实现方式：主节点处理完写操作后立即返回结果给客户端，写操作的日志异步同步到其他副本。 这样做的好处是性能高，客户端不需要等待数据同步。 缺点是如果在主节点将数据同步到副本之前数据丢失，数据将永久丢失。 MySQL的主从同步是典型的异步复制。

两阶段提交

两阶段提交（2PC）是关系型数据库常用的维护分布式事务一致性的协议。 也属于同步复制协议，即数据同步后才返回客户端结果。 可以发现，2PC保证了所有节点的数据在返回给客户端之前是一致的，实现了顺序一致性。

2PC将数据复制分为两步：

投票阶段：主节点将数据发送给所有副本，每个副本必须响应提交或回滚。 如果replica投票commit，会将数据放入暂存区，等待最后的commit。 提交阶段：主节点接收来自其他副本的响应。 如果副本认为他们可以提交，他们将向所有副本发送确认以提交更新，并且数据将从暂存区域移动到永久区域。 只要有一个replica返回回滚，整个回滚就完成了。

可以发现2PC是一个典型的CA系统。 为了保证一致性和可用性，一旦发生网络分区或节点不可用，2PC 将被拒绝写操作，使系统成为只读。 由于2PC容易出现节点宕机导致不断阻塞的情况，因此在数据复制场景中并不常用，一般用于分布式事务（注：实际应用过程中会有很多优化）。

分区容忍一致性协议

分区容忍一致性协议与所有单主协议相同。 它也只有一个主节点负责写入（提供顺序一致性），但它与2PC不同的是它只需要保证大多数节点（通常是一半以上）达成共识后就可以返回客户端结果，这可以提高性能和容忍网络分区（少量节点分区不会导致整个系统失效）。 分区容忍一致性算法保证大部分节点数据在返回客户端之前是一致的，也实现了顺序一致性。

下面用一个简单的例子来说明这类算法的核心思想。 假设有一个分布式文件系统，它的文件被复制到3台服务器上。 我们规定：客户端要更新一个文件，首先要访问至少2台服务器（最多），并且只有在征得他们同意后才能进行更新，每个文件都会有一个版本号标识； 客户端要读取文件，还必须访问至少2台服务器获取文件的版本号，如果所有的版本号都一致，那么版本一定是最新版本，因为如果之前的更新操作需要征得对方的同意大多数服务器更新文件。

以上就是我们熟悉的Paxos、ZAB、Raft等分区容忍共识协议的核心思想：一致性的保证不一定要求所有节点都一致，只要大部分节点更新即可，整个分布式系统的数据也是一致的。 以上只是简单的解释。 真正的算法实现比较复杂，这里就不展开了。

Paxos 等分区容忍一致性协议是典型的 CP 系统。 为了保证一致性和分区容忍性，在网络分区的情况下，允许大多数节点写入，整个系统的一致性是通过大多数节点的一致性来实现的。 ，同时让少数节点停止服务（不能读写），放弃整个系统的可用性，也就是说当客户端访问少数节点时，会失败。

值得注意的是，根据CAP理论，假设有A、B、C三个节点比特币的一致性是一种强一致性，当C被网络分区时，有一个查询请求。 此时C无法响应查询，因为它无法与其他节点通信。 , 它不可用。 但是在工程实现上，这个问题是可以绕过的。 当client访问C得不到响应时，可以访问A和B，其实对于整个系统还是部分可用的，并不是说CP系统就一定失去可用性。详细分析参考分布式系统：过去CAP理论的提出

多主协议

与单主协议不允许多个节点并发写入以实现顺序一致性相比，多主协议相反，只保证最终一致性，允许多个节点并发写入，可以显着提高提高系统性能。 由于多主协议一般会提供最终一致性，因此常用于对数据一致性要求不高的场景。

Gossip协议是一个典型的多主协议，被很多分布式系统用于数据复制，比如比特币，作为一个去中心化的公链，所有节点都使用Gossip协议进行数据同步。 此外，Gossip协议也被用于Dynamo等一些分布式数据库中，用于分布式故障检测的状态同步。 当一个节点未能离开集群时，其他节点可以快速检测到它。

从名字就可以看出Gossip协议的核心思想。 八卦就是八卦的意思。 想想我们日常生活中人与人之间八卦的场景。 一旦流言蜚语在学校传开，就会在人与人之间传播。 基本上整个学校最终都会知道。 因此，Gossip协议的核心思想是：每个节点都可以向其他节点发送消息，收到消息的节点随机选择其他节点发送消息，收到消息的节点做同样的事情。

多主协议允许多个节点并发写入，同时写入一条数据会产生数据冲突。 因此，这类协议需要解决并发写入的问题。 单主协议通过主节点控制写入，保证不会出现并发写，因为所有的写操作最终都会被主节点排序。 从某种意义上说，使用单主协议的系统实际上是串行写的。 好的，所以它的性能是一个瓶颈。 多主协议允许多个节点并发写入，提高了写入的性能，但实际上延迟了数据合并的操作。 单主协议在写的时候进行数据合并，所以读取的数据有数据冲突时，需要进行数据合并，保证全局一致性。

前面我们提到比特币使用Gossip协议进行数据复制，那么问题就来了。 不是说多主协议的性能会比较高吗？ 为什么比特币的表现这么差？ 其实这里要分开来看。 由于比特币是去中心化的，它的支付功能需要保证全局的数据一致性，所以它使用了一个非常巧妙的共识算法POW：所有节点做一道数学题，谁先算出答案，谁就有权将交易写入链中，然后使用 Gossip 协议传播它的答案和交易，其他节点验证它的答案是否正确并保存数据。

说到这里你可能会有一个疑问：为什么POW作为多主协议的性能会这么低？ 任何协议都有它的适用场景。 在比特币场景下，对数据一致性有很强的需求，理论上使用单主协议是最好的选择。 但是，比特币作为一种去中心化的数字货币，不会采用单一主协议，否则会再次成为中心化体系。 因此比特币的一致性是一种强一致性，比特币只能选择多主协议，通过POW协议将整个比特币链的运行近似序列化，以降低双花的概率（并发写入时一个比特币被多次消费），fish熊掌不可兼得。 既然要强一致性，那只能牺牲性能来换取。

由于多主协议允许数据发散，因此需要一种解决数据冲突的策略来确保最终一致性。 如果要严格区分，比特币实际上应用了两种共识协议：

总结

本文主要从是否允许数据发散的角度将分布式共识协议分为两类：单主协议和多主协议。 其中，单主协议会使用一个主节点负责写操作，可以保证全局写的顺序一致性，但也会牺牲部分性能。 多主协议允许写操作由不同的节点发起并同步到其他副本，这只能保证最终的一致性，但也提高了系统并发写的性能。 对数据一致性要求高的场景，比如分布式数据库，主要采用单主协议，而对数据一致性要求不高的场景，比如故障检测，主要采用多主协议来提升性能。 集中使用 POW 和 Gossip 进行数据复制。

值得注意的是，本文提到的单主和多主协议只是我个人对分布式共识协议的分类，以帮助我们更好地理解它们。 读者可以翻阅参考资料，看看不同作者是如何对分布式协议进行分类的，从而对分布式共识协议有更深入的了解。

参考分布式系统 book.mixu.net