2.1.7RAFT
2013年，斯坦福大学的 DiegoOngaro和 JohnOusterhout发表的 RAFT论文综合前人的成果，将复杂的 PAXOS协议理论用 更简单的方式描述，同时在细节上大晕借鉴 VR工程实现上的落地性，最终让 RAFT被学术界和产业 界广泛接受。
如图 2-12所示，首先根据共识理 论的成果 ，定义架构核心为状态机复制和日志，然后描述故障发生后角色 （领导者、跟随者、候选者，类似 PAXOS角色）的状态切换，接着 描述成员变换后的视图 ( Term, 类似 VR的 View视图）序号更新，最后描述复制曰志 的顺序号 ( LogIndex, 类似 VR的 Log) ，从而成为共识理论的最新集大成者。
图 2-12RAFT架构原理
2.1.8协调达成共识算法分析
通过学术和产业两 个角度的介绍及算法 分析可以看出，共识算法解决的核心问题是系统成员正常时如何解决多个请求提案的顺序处理间题并保证每个提案能够被系统成员投票达成一致，以及系 统成员异常时如何重新选取成员 并让系统重新进入正常状态 。现实生活中，美国国会开会的“罗伯特议事 规则”就是解决共识的经 典方案，团队开会 也是简单的共识解决方法。
· 会议的 N位成员正常时的议题处理方法。会议秘书 收集议题 ，秘书会按顺序编号 议题，对于相同的议题进行合并或排序 。会议主 持人发出评审议题 X, 参会入对该议题反馈同意／反对 ，然后主持人根据会 议成员 的投票结果 （如多千一半的成员同意）给
出议题的结 论。评审完议题 x, 再次评审下个 议题 ，直到所有议题结束。
· 会议的 N位成员异常时的议题处理方法。如果成员出现异常，如主待人请假、 参会人请假、新增参会人等，就必须形成新的会议投票 机制。
► 若主持人请假，则需 要选出 新的主持人。需要有机制、流程选出新的主持人，新
主持人必须能掌握会议运作机制和 投票机制（如成员变为 N- 1位）。
► 若参会人调整（如参会人请假、新增参会人），则需要调整新的投票 机制。假设有
1人请假，那么新的会议成员 为M位，M=N- 1。若投票时 ，超过一半 (? M/2) 成员同意，则该议题通过。
1. . 状态机复制
共识在成员 正常时，采用主来控制议题的顺序性，并且由主来推动成员 的投票，就像会议的主 持人推动参会人投票议题 ，并按议题 顺序推进会议，直到议题结束。
2. 投票
若想要请求在共识的多个成员 中达成一致，则需要采用投票 机制进行决策。类似会议主持人要求参会人 投票，对议题 X达成同意／反对的结论。成员投票 只是给出反馈，还需要以下决策方案。
· 同等权重决策。成员每人 1票，权重相同，假设总分为 N, 那么只有同意的结论分大千或等千 N/2时，该议题才能被同意。
· 不同权重决策。成员每人 1票，权重不相同，如主待人为 3分，参会人为 1分，假设总分为 M; 那么只有同意的结论分大 千或等千M/2时，该议题才能被同 意。
3. 故障类型
共识协议能实现故障的容错，分布式系 统中典型的故障如下。
· 崩溃故障 ( CrashFa ilure, 也叫作 Fail-Stop) 。成员在发生故障后会停止运行 ( Fa仆Stop)。例如，服务器直接崩溃 重启，由千及时从系统中离开，所以让状态机的后续运行更简单。
· 拜占庭故障。成员发生故障但并不 停止运 行，进入不 稳定状态 ，甚至给出 错误的反馈。例如，扮演成员的进程因系统繁忙偶发挂住 ( Hang) ，时而响应，时而不响应，甚至返回错误的消息 。由于成员处千亚健康状态 ，会干扰系统的状态机运行，所以更难处理。
4. 选主
共识协议中的成员发生故障时 ，特别是主成员发生故障时 需要进行选主动作 ，如会议主持人请假。通常来说，选主有以下解决方案。
· 基千投票选举。参与选主的成员进行投票 ，按照投票的半数得分决策原则选主。
· 优先级 ( Priority) 选举。参与选主的成员被指定优先级 ID，由 ID号最小的成员作为主，就像权利的顺位继承，该方法决策速度快 。选择日 志顺序号最小的成员作为新主可以提高恢复效率 ，因为其他成员只需向新主 获取有差鼠的日志，而无须日志回退的处理逻辑。
5. 日志复制
支持数据 持久化能力的共识算法在复制状态机中需要引入日 志复制。也就是说 ，将复制状态机中涉及数据变更的请求（创建、删除、更新等）按更新操作的日志 顺序号保存，从而支持成员发生故障后 的恢复。
每个成员根据状态机运行，无依赖地独 立记录自己的日志。在成员发生故障时 ，根据选主策略对日志顺序号进行比对，选择日志顺 序号最大的成员作为新主。由千新主有最多的日志记录，所以未成为主的成员向它申请修复差量 的曰志 ，然后正确地进入 新状态。控制日志的存储空间大 小，以及如何设计日志组织 （如 Checkpoint) 是成员快速恢复的关键技术。
2.1.9对象存储服务的共识应用
对象存储作为典型的分布式系 统，必须要有一致性共识服务 。阿里云对象存储依赖 女蜗共识服务，女娱是阿里云飞天系统底层核心模块 之一，女姻对外提供一致性共识、分布式锁、消息通知等服务。与业界类似功能的开源软件 ( ZooKeeper、ETCD) 相比，女姻在性能、可扩展性和可运维性上有明显的优势，如图 2-13所示。
图 2-13阿里云女蜗一致性（共识）服务
女娴服务采用两 层架构，后端是实现一致性的功能模块 ，前端是达到分流效果 的前端机，从而提供更 好的扩展能力，支撑大规模云业务的接入。
· 前端机通过 VIP做负载均衡，主要实现两个功能：第一个，负责维护众多客户端 的通信，从而 保证客户 端请求能够均衡到后 端；第二个，向客户端隐藏后端的切换过程，同时提供高效的消息通知功能。
· 后端由多台服务器 组成 PAXOS组，形成一致性共识协议核心 。为客户端使用的资源
（文件、锁等）提供 PAXOS组仲裁并采用 PAXOS分布式 共识协议进行同步 ，保证资源的一致性和待久化 。为了提供更 好的扩展能力 ，后端提供了多个 PAXOS组。
因此，通过多 VIP冗余、前端机透明切 换、冗 余的一致性共识 PAXOS组，实现发生故障时的快速切换，从而 为一致性共识提供高可用性。
