分布式理论，架构设计（一）---- 分布式理论

文章内容输出来源：拉勾教育Java高薪训练营。
本篇文章是 分布式理论 学习课程中的一部分笔记。

分布式系统架构回顾

• 概念：分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。

  所谓分布式系统，就是一个业务拆分成多个子业务，分布在不同的服务器节点，共同构成的系统称为分布式系统，同一个分布式系统中的服务器节点在空间部署上是可以随意分布的，这些服务器可能放在不同的机柜中，也可能在不同的机房中，甚至分布在不同的城市。

• 特点

  • （1）分布性（2）对等性（3）并发性（4）缺乏全局时钟（5）故障总是会发生

• 分布式架构发展大致过程

  • https://mp.weixin.qq.com/s/bFMObUDJI1zwChirDK6RKQ

• 面临的问题

  • 通信异常

    网络本身的不可靠性，因此每次网络通信都会伴随着网络不可用的风险（光纤、路由、DNS等硬件设备或系统的不
    可用），都会导致最终分布式系统无法顺利进行一次网络通信，另外，即使分布式系统各节点之间的网络通信能够
    正常执行，其延时也会大于单机操作，存在巨大的延时差别，也会影响消息的收发过程，因此消息丢失和消息延迟
    变的非常普遍。
    
    
    

  • 网络分区

    网络之间出现了网络不连通，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个
    孤立的区域，分布式系统就会出现局部小集群，在极端情况下，这些小集群会独立完成原本需要整个分布式系统才
    能完成的功能，包括数据的事务处理，这就对分布式一致性提出非常大的挑战
    
    

  • 节点故障

    节点故障是分布式系统下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或"僵死"现象，
    根据经验来说，每个节点都有可能出现故障，并且经常发生
    

  • 三态

    分布式系统每一次请求与响应存在特有的“三态”概念，即成功、失败和超时。
    分布式系统中，由于网络是不可靠的，虽然绝大部分情况下，网络通信能够接收到成功或失败的响应，但当网络出
    现异常的情况下，就会出现超时现象，通常有以下两种情况：
    
    

    1. 由于网络原因，该请求并没有被成功的发送到接收方，而是在发送过程就发生了丢失现象。
    2. 该请求成功的被接收方接收后，并进行了处理，但在响应反馈给发送方过程中，发生了消息丢失现象。

一致性

• 概念：分布式数据一致性，指的是数据在多份副本中存储时，各副本中的数据是一致的。

• 一致性分类 / 级别

  • 强一致性

    • 这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大。但是强一致性很难实现

  • 弱一致性

    这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，
    但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。
    

    • 读写一致性

      • 用户读取自己写入结果的一致性，保证用户永远能够第一时间看到自己更新的内容。

        解决方案:
        方案1：一种方案是对于一些特定的内容我们每次都去主库读取。 （问题主库压力大）
        

        方案2：我们设置一个更新时间窗口，在刚刚更新的一段时间内，我们默认都从主库读取，过了这个窗口之后，我们会挑选最近有过更新的从库进行读取

        方案3：我们直接记录用户更新的时间戳，在请求的时候把这个时间戳带上，凡是最后更新时间小于这个时间戳的从库都不予以响应

    • 单调读一致性

      • 本次读到的数据不能比上次读到的旧。

        解决方案:就是根据用户ID计算一个hash值，再通过hash值映射到机器。同一个用户不管怎么刷新，都只会被映射到同
        一台机器上。这样就保证了不会读到其他从库的内容，带来用户体验不好的影响。
        

    • 因果一致性

      • 指的是：如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后 的值。于此同时，和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。

    • 最终一致性

      • 最终一致性是所有分布式一致性模型当中最弱的。可以认为是没有任何优化的“最”弱一致性，它的意思是说，我不考虑 所有的中间状态的影响，只保证当没有新的更新之后，经过一段时间之后，最终系统内所有副本的数据是正确的

CAP定理

• 概念：一个分布式系统不可能同时满足一致性（C:Consistency)（强一致性），可用性（A: Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中的2个。

  C 一致性
  分布式系统当中的一致性指的是所有节点的数据一致，或者说是所有副本的数据一致
  

  A 可用性
  Reads and writes always succeed. 也就是说系统一直可用，而且服务一直保持正常
  

  P 分区容错性
  系统在遇到一些节点或者网络分区故障的时候，仍然能够提供满足一致性和可用性的服务
  

BASE理论

• 阐述：BASE是对CAP中一致性和可用性权衡的结果，BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

  BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个
  短语的缩写
  

• Basically Available(基本可用)

  • 基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用

    响应时间上的损失：正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出
    现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
    

    功能上的损失：正常情况下，在一个电子商务网站（比如淘宝）上购物，消费者几乎能够顺利地完成每一笔
    订单。但在一些节日大促购物高峰的时候（比如双十一、双十二），由于消费者的购物行为激增，为了保护
    系统的稳定性（或者保证一致性），部分消费者可能会被引导到一个降级页面
    
    

• Soft state（软状态）

  • 软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本之间进行数据同步的过程中存在延迟。

• Eventually consistent（最终一致性）

  • 最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此最终
    一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
    

一致性协议2PC

• 描述：2PC （ Two-Phase Commit缩写）即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare
  phase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段
  

• 过程：

  • 1 准备阶段：

    • 事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此时事务没有提交。 （Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数 据文件）

  • 2 提交阶段：

    • 如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。

• 执行流程

  • 成功执行

    • 阶段一: 1. 事务询问 协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。 2. 执行事务 (写本地的Undo/Redo日志) 3. 各参与者向协调者反馈事务询问的响应 总结: 各个参与者进行投票是否让事务进行
    • 阶段二: 1. 发送提交请求： 协调者向所有参与者发出 commit 请求。 2. 事务提交： 参与者收到 commit 请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资 源。 3. 反馈事务提交结果： 参与者在完成事务提交之后，向协调者发送 Ack 信息。 4. 完成事务： 协调者接收到所有参与者反馈的 Ack 信息后，完成事务。

  • 中断执行

    • 阶段一： 同成功执行过程
    • 阶段二： 1. 发送回滚请求： 协调者向所有参与者发出 Rollback 请求。 2. 事务回滚： 参与者接收到 Rollback 请求后，会利用其在阶段一中记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后 释放在整个事务执行期间占用的资源。 3. 反馈事务回滚结果： 参与者在完成事务回滚之后，向协调者发送 Ack 信息。 4. 中断事务： 协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。 从上面的逻辑可以看出，二阶段提交就做了2个事情：投票，执行。

• 优缺点

  • 优点： 原理简单，实现方便

  • 缺点

    • 1 同步阻塞， 2 单点问题， 3数据不一致， 4数据不一致，过于保守

一致性协议 3PC

• 描述：3PC，全称 “three phase commit”，是 2PC 的改进版，将 2PC 的 “提交事务请求” 过程一分为二，共形成了由CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。

• 流程

  • 第一个阶段： CanCommit
    ① 事务询问 协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
    ② 各参与者向协调者反馈事务询问的响应 参与者在接收到来自协调者的包含了事务内容的canCommit请求后，正常情况下，如果自身认为可以顺利执行事务，则反馈Yes响应，并进入预备状态，否则反馈No响应。
    
    

  • 阶段二：PreCommit
    协调者在得到所有参与者的响应之后，会根据结果有2种执行操作的情况：执行事务预提交，或者中断事务
    假如所有参与反馈的都是Yes，那么就会执行事务预提交。
    
    

    1. 执行事务预提交分为 3 个步骤
       ① 发送预提交请求：
       协调者向所有参与者节点发出preCommit请求，并进入prepared阶段。
       ② 事务预提交：
       参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。
       ③ 各参与者向协调者反馈事务执行的结果：
       若参与者成功执行了事务操作，那么反馈Ack
       若任一参与者反馈了No响应，或者在等待超时后，协调者尚无法接收到所有参与者反馈，则中断事务
       
       
       
       
       
       
       

    2. 中断事务也分为2个步骤：
       ① 发送中断请求：
       协调者向所有参与者发出abort请求。
       ② 中断事务：
       无论是收到来自协调者的abort请求或者等待协调者请求过程中超时，参与者都会中断事务
       
       
       
       

  • 阶段三：do Commit
    该阶段做真正的事务提交或者完成事务回滚，所以就会出现两种情况
    

    1. 执行事务提交
       ① 发送提交请求：
       进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的Ack响应，那么他将从预提交状
       态转化为提交状态，并向所有的参与者发送doCommit请求。
       ② 事务提交：
       参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行过程中占用的事
       务资源。
       ③ 反馈事务提交结果：
       参与者在完成事务提交后，向协调者发送Ack响应。
       ④ 完成事务：
       协调者接收到所有参与者反馈的Ack消息后，完成事务。
       
       
       
       
       
       
       
       
       
       

    2. 中断事务
       ① 发送中断请求：协调者向所有的参与者节点发送abort请求。
       ② 事务回滚：参与者收到abort请求后，会根据记录的Undo信息来执行事务回滚，并在完成回滚之后释放整
       个事务执行期间占用的资源。
       ③ 反馈事务回滚结果：参与者在完成事务回滚后，向协调者发送Ack消息。④ 中断事务：协调者接收到所有参与者反馈的Ack消息后，中断事务。
       
       
       
       

    • 注意：一旦进入阶段三，可能会出现 2 种故障：

1. 协调者出现问题
2. 协调者和参与者之间的网络故障
   如果出现了任一一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求，针对这种情况，参与者都会在等待超时之后，继续进行事务提交
   

• 对比2PC

  • 1.首先对于协调者和参与者都设置了超时机制（在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收到参与者的消息则默认失败）,主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。

  • 2.通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的 。

  • 3.PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。

• 问题：3PC协议并没有完全解决数据不一致问题。

一致性算法Paxos

• 描述：一种基于消息传递的分布式一致性算法

  ZooKeeper，以及MySQL 5.7推出的用来取代传统的主从复制的MySQL Group Replication等纷纷采用Paxos算法
  解决分布式一致性问题
  

  • 解决了分布式系统的一致性问题

• 相关概念：

  • 提案 (Proposal)：Proposal信息包括提案编号 (Proposal ID) 和提议的值 (Value) 最终要达成一致的value就在提案里。

  • 角色

    • Client: 客户端

      • 客户端向分布式系统发出请求，并等待响应。例如，对分布式文件服务器中文件的写请求。

    • Proposer：提案者（可以有多个）

      • 提案者提倡客户请求，试图说服Acceptor对此达成一致，并在发生冲突时充当协调者以推动协议向前发展

    • Acceptor：决策者，可以批准提案（可以有多个）

      • Acceptor可以接受（accept）提案；如果某个提案被选定（chosen），那么该提案里的value就被选定了

    • Learners：最终决策的学习者（可以有多个）

      • 学习者充当该协议的复制因素

  • 假设有一组可以提出提案的进程集合，那么对于一个一致性算法需要保证以下几点：

    • 在这些被提出的提案中，只有一个会被选定
    • 如果没有提案被提出，就不应该有被选定的提案。
    • 当一个提案被选定后，那么所有进程都应该能学习（learn）到这个被选定的value

• 推导过程

  • 几个约束：一个提案被选定需要被半数以上的Acceptor接受

    • P1：一个Acceptor必须接受它收到的第一个提案

    • P2：如果某个value为v的提案被选定了，那么每个编号更高的被选定提案的value必须也是v。

      • P2a：如果某个value为v的提案被选定了，那么每个编号更高的被Acceptor接受的提案的value必须也是v。
      • P2b：如果某个value为v的提案被选定了，那么之后任何Proposer提出的编号更高的提案的value必须也是v。
      • P2c：对于任意的Mn和Vn,如果提案[Mn,Vn]被提出，那么肯定存在一个由半数以上的Acceptor组成的集合S，满足以下 两个条件中的任意一个： * 要么S中每个Acceptor都没有接受过编号小于Mn的提案。 * 要么S中所有Acceptor批准的所有编号小于Mn的提案中，编号最大的那个提案的value值为Vn

• Proposer生成提案，Acceptor接受提案规则

  这里有个比较重要的思想：Proposer生成提案之前，应该先去『学习』已经被选定或者可能被选定的value，然后以该value作为自己提出的提案的value。如果没有value被选定，Proposer才可以自己决定value的值。这样才能达成一致。这个学习的阶段是通过一个『Prepare请求』实现的。

  • Proposer生成提案

    • prepare请求

      • Proposer选择一个新的提案编号N，然后向某个Acceptor集合（半数以上）发送请求，要求该集合中的每个Acceptor做出如下响应（response） (a) Acceptor向Proposer承诺保证不再接受任何编号小于N的提案。 (b) 如果Acceptor已经接受过提案，那么就向Proposer反馈已经接受过的编号小于N的，但为最大编号的提案的值。

    • accept请求

      • 如果Proposer收到了半数以上的Acceptor的响应，那么它就可以生成编号为N，Value为V的提案[N,V]。这里
        的V是所有的响应中编号最大的提案的Value。如果所有的响应中都没有提案，那 么此时V就可以由Proposer
        自己选择。生成提案后，Proposer将该提案发送给半数以上的Acceptor集合，并期望这些Acceptor能接受该提案。我们称该请求为Accept请求。
        
        

  • Acceptor接受提案

    • Prepare请求：Acceptor可以在任何时候响应一个Prepare请求
      Accept请求：在不违背Accept现有承诺的前提下，可以任意响应Accept请求
      

      • P1A 一个Acceptor只要尚未响应过任何编号大于N的Prepare请求，那么他就可以接受这个编号为N的提案。

    • 算法优化：如果Acceptor收到一个编号为N的Prepare请求，在此之前它已经响应过编号大于N的Prepare请求。根据P1a，该 Acceptor不可能接受编号为N的提案。因此，该Acceptor可以忽略编号为N的Prepare请求。

      通过这个优化，每个Acceptor只需要记住它已经批准的提案的最大编号以及它已经做出Prepare请求响应的提案的最大编号，以便出现故障或节点重启的情况下，也能保证P2c的不变性，而对于Proposer来说，只要它可以保证不会产生具有相同编号的提案，那么就可以丢弃任意的提案以及它所有的运行时状态信息

• Paxos算法描述

  • 阶段一：
    (a) Proposer选择一个提案编号N，然后向半数以上的Acceptor发送编号为N的Prepare请求。
    (b) 如果一个Acceptor收到一个编号为N的Prepare请求，且N大于该Acceptor已经响应过的所有Prepare请求的编号，那么它就会将它已经接受过的编号最大的提案（如果有的话）作为响应反馈给Proposer，同时该Acceptor承诺不再接受任何编号小于N的提案。
    
    

阶段二：
(a) 如果Proposer收到半数以上Acceptor对其发出的编号为N的Prepare请求的响应，那么它就会发送一个针对[N,V]提案的Accept请求给半数以上的Acceptor。注意：V就是收到的响应中编号最大的提案的value，如果响应中不包含任何提案，那么V就由Proposer自己决定。
(b) 如果Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor没有对编号大于N的Prepare请求做出过响应，它就接受该提案。

• Learner学习被选定的value

  方案一：
  Learner获取一个已经被选定的提案的前提是，该提案已经被半数以上的Acceptor批准，因此，最简单的
  做法就是一旦Acceptor批准了一个提案，就将该提案发送给所有的Learner
  很显然，这种做法虽然可以让Learner尽快地获取被选定的提案，但是却需要让每个Acceptor与所有的Learner逐
  个进行一次通信，通信的次数至少为二者个数的乘积
  
  
  
  

  方案二：
  另一种可行的方案是，我们可以让所有的Acceptor将它们对提案的批准情况，统一发送给一个特定的Learner（称
  为主Learner）, 各个Learner之间可以通过消息通信来互相感知提案的选定情况，基于这样的前提，当主Learner
  被通知一个提案已经被选定时，它会负责通知其他的learner
  在这种方案中，Acceptor首先会将得到批准的提案发送给主Learner,再由其同步给其他Learner.因此较方案一而
  言，方案二虽然需要多一个步骤才能将提案通知到所有的learner，但其通信次数却大大减少了，通常只是
  Acceptor和Learner的个数总和，但同时，该方案引入了一个新的不稳定因素：主Learner随时可能出现故障
  
  
  
  
  
  

  方案三：
  在讲解方案二的时候，我们提到，方案二最大的问题在于主Learner存在单点问题，即主Learner随时可能出现故
  障，因此，对方案二进行改进，可以将主Learner的范围扩大，即Acceptor可以将批准的提案发送给一个特定的
  Learner集合，该集合中每个Learner都可以在一个提案被选定后通知其他的Learner。这个Learner集合中的
  Learner个数越多，可靠性就越好，但同时网络通信的复杂度也就越高
  
  
  
  

• 如何保证Paxos算法的活性：

  • 活性：最终一定会发生的事情：最终一定要选定value
  • 假设有两个Proposer依次提出编号递增的提案，最终会陷入死循环，没有value被选定（无法保证活性）
  • 解决：通过选区主Proposer，并规定只有主Proposer才能提出提案，这样一来只有主Proposer和过半的Acceptor能够正常进行网络通信，那么但凡主Proposer提出一个编号更高的天，该提案最终将会被批准，这样通过选择一个Proposer，整套Paxos算法就能够保持活性

一致性算法Raft

• 描述： Raft是一种为了管理复制日志的一致性算法， Raft将一致性算法分解成了3各模块：1领导人选举，2日志复制，3安全性

• 两个阶段

  • 领导人Leader选举

    • 描述：Raft 通过选举一个领导人，然后给予他全部的管理复制日志的责任来实现一致性。

      • 在Raft中，任何时候一个服务器都可以扮演下面的角色之一：
        领导者(leader)：处理客户端交互，日志复制等动作，一般一次只有一个领导者
        候选者(candidate)：候选者就是在选举过程中提名自己的实体，一旦选举成功，则成为领导者
        跟随者(follower)：类似选民，完全被动的角色，这样的服务器等待被通知投票
        而影响他们身份变化的则是 选举
        
        
        
        

    • 过程：

      • 初始状态下集群中的所有节点都处于 follower 状态。
      • 某一时刻，其中的一个 follower 由于没有收到 leader 的 heartbeat 率先发生 election timeout 进而发起选举。
      • 只要集群中超过半数的节点接受投票，candidate 节点将成为即切换 leader 状态。
      • 成为 leader 节点之后，leader 将定时向 follower 节点同步日志并发送 heartbeat。

    • 异常及解决方案

      • leader不可用

        • 一般情况下，leader 节点定时发送 heartbeat 到 follower 节点。

          • 由于某些异常导致 leader 不再发送 heartbeat ，或 follower 无法收到 heartbeat 。

            • 当某一 follower 发生 election timeout 时，其状态变更为 candidate，并向其他 follower 发起投票。

        • 当超过半数的 follower 接受投票后，这一节点将成为新的 leader，leader 的步进数加 1 并开始向 follower 同步日志。

          • 当一段时间之后，如果之前的 leader 再次加入集群，则两个 leader 比较彼此的步进数，步进数低的 leader 将切换自己的状态为 follower。

            • ➢ 较早前 leader 中不一致的日志将被清除，并与现有 leader 中的日志保持一致

      • folloer不可用

        • 流程

          集群中的某个 follower 节点发生异常，不再同步日志以及接收 heartbeat

          经过一段时间之后，原来的 follower 节点重新加入集群。

          这一节点的日志将从当时的 leader 处同步。

      • 多个candidate或多个leader

        • 在集群中出现多个 candidate 或多个 leader 通常是由于数据传输不畅造成的。出现多个 leader 的情况相对少见，但多个 candidate 比较容易出现在集群节点启动初期尚未选出 leader 的“混沌”时期。

          初始状态下集群中的所有节点都处于 follower 状态。

          两个节点同时成为 candidate 发起选举

          两个 candidate 都只得到了少部分 follower 的接受投票。

          candidate 继续向其他的 follower 询问。

          由于一些 follower 已经投过票了，所以均返回拒绝接受。

          candidate 也可能向一个 candidate 询问投票。

          在步进数相同的情况下，candidate 将拒绝接受另一个 candidate 的请求。➢ 由于第一次未选出 leader，candidate 将随机选择一个等待间隔（150ms ~ 300ms）再次发起投票。

          如果得到集群中半数以上的 follower 的接受，这一 candidate 将成为 leader。

          稍后另一个 candidate 也将再次发起投票。

          由于集群中已经选出 leader，candidate 将收到拒绝接受的投票。

          在被多数节点拒绝之后，并已知集群中已存在 leader 后，这一 candidate 节点将终止投票请求、切换为follower，从 leader 节点同步日志。

      • 新节点接入集群

  • 日志复制

    Leader选出后，就开始接收客户端的请求。Leader把请求作为日志条目（Log entries）加入到它的日志中，
    然后并行的向其他服务器发起 AppendEntries RPC复制日志条目。当这条日志被复制到大多数服务器上，Leader
    将这条日志应用到它的状态机并向客户端返回执行结果。
    
    

    • 步骤：

      可以看到，直到第四步骤，整个事务才会达成。中间任何一个步骤发生故障，都不会影响日志一致性。

      • 客户端的每一个请求都包含被复制状态机执行的指令。
      • leader把这个指令作为一条新的日志条目添加到日志中，然后并行发起 RPC 给其他的服务器，让他们复制这条信息。
      • 跟随者响应ACK,如果 follower 宕机或者运行缓慢或者丢包，leader会不断的重试，直到所有的 follower 最终都复制了所有的日志条目。
      • 通知所有的Follower提交日志，同时领导人提交这条日志到自己的状态机中，并返回给客户端

来源：oschina

链接：https://my.oschina.net/u/4387121/blog/4382407