Raft算法系列教程2：状态机复制 (State Machine Replication)
备注：Raft将分布式一致性分解为多个子问题：Leader选举（Leader election）、日志复制（Log replication）、安全性（Safety）、日志压缩（Log compaction）等。欢迎大家持续关注本系列内容！
备注：本系列内容专供
网站核心社群成员学习使用。
分区容错如何保证？在分布式系统设计中，需要遵循CAP理论，如果我们要让一个服务具有容错能力，那么最常用最直接的办法就是让一个服务的多个副本同时运行在不同的节点上。但是，当一个服务的多个副本都在运行的时候，我们如何保证它们的状态都是同步的呢，或者说，如果让客户端看起来无论请求发送到哪一个服务副本，最后都能得到相同的结果？实现这种同步方法就是所谓的状态机复制（State Machine Replication）。
状态机复制的理论基础是：如果集群里的每一个节点上都运行着相同的确定性状态机S，并且所有的状态机刚开始都处于同样的初始状态s0，那么给予这些状态机相同的输入序列：
{i1, i2, i3, i4, i5, i6, …, in}这些状态机必然会经过相同的状态转换路径：
s0->s1->s2->s3->…->sn最终达到相同的状态sn，同时生成相同的输出序列：
{o1(s1), o2(s2), o3(s3), …, on(sn)}状态机复制在实际应用中的一个例子就是MySQL集群。我们知道，MySQL集群中的master会把所有的操作记录到binlog中，这里的操作就是输入序列I，然后slave会把master上的binlog复制到自己的relaylog中，然后再把relaylog里的操作回放一遍（相当于执行了一遍输入序列I）。所以，如果master和slave里的状态机是完全相同的，并且在执行序列I之前都处于相同的状态下，那么执行完序列I后，它们的状态依旧是相同的（一致性）。
在执行输入序列I的过程中，根据同步方式的不同，系统就有了强一致性和最终一致性。如果我们要求对于序列I中的每一个in， 都需要所有的服务副本确认成功执行了in，才能执行in+1，那么这个系统就是强一致性的系统。如果我们取消掉这个限制，仅仅要求所有的服务副本执行相同的输入序列I，但是完全各自独立执行，而不需要在中间同步，那么就有了最终一致性（各服务都会达到相同的最终状态，但是达到的时间不确定）。
所有一致性算法都会涉及到状态机，而状态机保证系统从一个一致的状态开始，以相同的顺序执行一些列指令最终会达到另一个一致的状态。
以上是状态机的示意图。所有的节点以相同的顺序处理日志，那么最终x、y、z的值在多个节点中都是一致的。