本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可。
本作品 (李兆龙 博文, 由 李兆龙 创作),由 李兆龙 确认,转载请注明版权。
引言
第一次看到这个问题是在看一些技术博客讨论ZAB与Paxos,Raft的区别的时候。这个问题困扰了我很久,我一直不清楚它们之间到底有什么不同。说实话,网上我看的的所有文章对这个问题的描述也是含含糊糊。本篇文章基于维基上的的内容对此问题给出自己的看法,观点不保证正确,错误之处还请斧正。
Active replication 与 Passive replication
要搞清楚state machine replication
与 primary backup system
之间的区别我们必须先了解下Active replication
与 Passive replication
。我们可以在[2]中看到如下描述:
Computer scientists further describe replication as being either:
- Active replication, which is performed by processing the same request at every replica
- Passive replication, which involves processing every request on a single replica and transferring the result to the other replicas
计算机科学进一步将复制描述为以下两者之一:
- 通过在每个副本上处理相同的请求来执行复制
- 涉及处理单个副本上的每个请求,并将结果传输到其他副本
其实已经很清楚了,后者强调必须有一个单点来处理请求,然后将结果传输到其他副本;而前者的限制更宽松,强调只需要存在一个状态机,输入相同,输出相同即可。
[2]把State machine replication
描述成分布式系统中复制模型的一种,我们看看[2]中对State machine replication
的描述:
assumes that the replicated process is a deterministic finite automaton and that atomic broadcast of every event is possible. It is based on distributed consensus and has a great deal in common with the transactional replication model. This is sometimes mistakenly used as a synonym of active replication. State machine replication is usually implemented by a replicated log consisting of multiple subsequent rounds of the Paxos algorithm. This was popularized by Google’s Chubby system, and is the core behind the open-source Keyspace data store.
我们再来看看[8]中对Active replication
与 Passive replication
的精确定义:
- With active replication, also known as state machine replication, each replica implements a deterministic state machine. All replicas process the same operations in the same order.
- With passive replication, also known as primary backup, a primary replica runs a deterministic state machine, while backups only store states. The primary computes a sequence of new application states by processing operations and forwards these states to each backup in order of generation.
- 使用passive replication,也称为state machine replication,每个副本都实现确定性状态机。 所有副本均以相同顺序处理相同操作。
- 使用被动复制,也称为primary backup,主副本运行确定性状态机,而备份仅存储状态。 主数据库通过处理操作计算一系列新的应用程序状态,并将这些状态按生成顺序转发给每个备份。
更加佐证了我们上面说的那些话。说了这么多,不如来副图看看更清晰[8]:
很清楚的描述了Active replication
与 Passive replication
的关系,即前者无主,后者有主。我们也知道multi-Paxos
存在主的原因是为了提高效率,免去第一阶段生成提案,不使用主节点的话对安全性也没有什么影响,不过可能影响活性(活锁)。而ZAB和Raft是必须需要一个主节点的。
我们再来看一幅非常著名的图[8]:
可以很清楚的看到各个协议之间的关系。
从[4]中我们也可以看到如下文字,可以看到网上很多博主都引用了这段文字:
What is the difference between primary-backup and state machine replication?
- A state machine is a software component that processes a sequence of requests. For every processed request, it can modify its internal state and produce a reply. A state machine is deterministic in the sense that, given two runs where it receives the same sequence of requests, it always makes the same internal state transitions and produces the same replies.
- A state machine replication system is a client-sever system ensuring that each state machine replica executes the same sequence of client requests, even if these requests are submitted concurrently by clients and received in different orders by the replicas. Replicas agree on the execution order of client requests using a consensus algorithm like Paxos. Client requests that are sent concurrently and overlap in time can be executed in any order. If a leader fails, a new leader that executes recovery is free to arbitrarily reorder any uncommitted request since it is not yet completed.
- In the case of primary-backup systems, such as Zookeeper, replicas agree on the application order of incremental (delta) state updates, which are generated by a primary replica and sent to its followers. Unlike client requests, state updates must be applied in the exact original generation order of the primary, starting from the original initial state of the primary. If a primary fails, a new primary that executes recovery cannot arbitrarily reorder uncommitted state updates, or apply them starting from a different initial state.
- In conclusion, agreement on state updates (for primary-backup systems) requires stricter ordering guarantees than agreement on client requests (for state machine replication systems).
- 状态机是处理一系列请求的软件组件。对于每个已处理的请求,它可以修改其内部状态并产生答复。状态机在某种意义上是确定性的,即在给定两次运行接收相同请求序列的情况下,状态机始终进行相同的内部状态转换并产生相同的答复。
- 状态机复制系统是确保所有状态机副本执行相同顺序的客户端请求的客户端服务器系统,即使这些请求由客户端同时提交并由副本以不同顺序接收。副本使用诸如Paxos之类的共识算法就客户端请求的执行顺序达成一致。并发发送且时间重叠的客户端请求可以按任何顺序执行。如果领导者失败,则执行恢复的新领导者可以随意重新排序任何未提交的请求,因为该请求尚未完成。
- 对于诸如Zookeeper之类的主备份系统,副本在增量(增量)状态更新的应用程序顺序上达成一致,增量状态更新由主副本生成并发送给其跟随者。与客户端请求不同,状态更新必须从主数据库的原始初始状态开始,按照主数据库的原始原始生成顺序进行应用。如果主数据库发生故障,则执行恢复的新主数据库无法任意重新排序未提交的状态更新,也不能从其他初始状态开始应用它们。
- 总之,与对客户端请求的协议(对于状态机复制系统)相比,对状态更新的协议(对于主备份系统)需要更严格的顺序保证。
我个人认为上面的文字其实就是阐述了一个问题,这个问题也是为什么zookeeper不使用Paxos来做一致性协议的原因,这个问题我在[9]中也描述过,即multi-Paxos只保证了所有节点的日志顺序一模一样,但对于每个节点自身来说,可以认为它的日志并没有所谓的“顺序”。出现这个问题的原因其实就是Paxos允许多节点写入,两个请求AB可能在两个结点提交,但是逻辑上的第二个请求B可能在日志中index更小,因为其先获取提案且提交成功,或者使得A提案无效,自己先提交。
当然也可以看出其实primary backup system
就是一个特殊的state machine replication
。可以参考Figure1。
一致性算法与状态机
那么一致性算法和状态机的关系是什么呢?[10]给出了这样的解释:
写的非常清楚:
一致性算法管理着来自客户端指令的复制日志。状态机从日志中处理相同顺序的相同指令,所以产生的结果也是相同的。
状态机的意义是把日志代表的操作输入,保证不同机器上的状态机状态相同,而保证复制日志相同就是一致性算法的工作了。在一台服务器上,一致性模块接收客户端发送来的指令然后增加到自己的日志中去。它和其他服务器上的一致性模块进行通信来保证每一个服务器上的日志最终都以相同的顺序包含相同的请求,从而保证状态机状态一致。
就我写过的ChubbyGo的经验来说,状态机的实质其实就是执行了Commit日志的各种数据结构。
如此看来Raft的优化方向之一可能就是去除冗余的日志,类似与Redis的AOF重写,主从同步的时候检测到不相同的日志点,基于状态机发送更少的日志,日志压缩时也可以进行重写,以发送更少的日志。
发送日志的区别
可以看到它们之间最大的差别就是一个直接发送日志,另一个会进行评估后再发送。我认为这其实在实现时区别很大,前者相当于状态机只是存储结果,不参与决策;后者状态机参与决策,原因是Leader拥有最权威的日志。这样也可以看出前者没办法实现诸如Random
这样的指令。当然在[1]中我们还可以发现Primary backup
还有如下问题:
- 如果某一个操作最后并没有提交, 那么这个state machine 必须将这次的操作给回滚掉
- 如果一个新的节点成为primary, 那么旧的primary 的state machine 必须将最近的未提交的操作给回滚掉
这类似于幽灵复现的问题,在[9]中讨论过了。
其实也可以看出Primary backup
需要更严格的顺序保证。不然的话就可能出现数据丢失的问题,比如Redis就是Primary backup
模型,其存在上面的问题,就是数据可能还没同步到backup
,但是Primary
宕机,这样的话可能出现数据丢失的问题,在用户角度看就是操作明明已经成功,但是看不到结果,原因就是没有执行回滚操作。当然Redis主从没有任何的一致性保证可言。
参考:
- 博客《state machine replication vs primary backup system》
- 维基《Replication (computing)》
- 维基《State machine replication》
- 博客《Zab vs. Paxos》
- StackOverflow《Relationship between primary-backup and state machine replication》
- 课件《KAU Replication State Machines via Primary-Backup 》
- 博客《众协议 Paxos/ZAB/Raft/VR 值得注意的细节》
- 论文《Vive La Difference: Paxos vs. Viewstamped Replication vs. Zab》
- 博客《Paxos,Raft,ZAB的差异对比》
- 论文《In Search of an Understandable Consensus Algorithm(Extended Version)》