分布式系统需要管理大 规模服务器，而软件就需要运行在海 量服务器之上。管理的服务器越多，越需要在系 统中提供协调 ( Coordination) 的仲裁服务，从而让运行在多台服务器上的软件达成共识 ( Consensus)、形成一致 ( Agreement) ，典 型如对象存储核心元数据。
协调服务本身也是由运行在多台服务器上的软件组成的，当某台服务器发生故障并且无法修复时，还需要继续提供服务。此时引入复制 ( Replication) 技术将数据在多台服务器之间复制，即使某台服务器发生故障也能快速、无缝地切换到其他服务器，从而继续提供仲 裁服务 ，最终让客户端无感知地调用仲裁功能。
复制技术也大规模应用到分布式存储系统中，实现数据的副本冗余或者纠删码冗余，支撑多台服务器 的盘发生故障后，数据仍然可用，还能继续提供数据服务。
因此，协调和复制存在一定的联系，本章将通过介绍学术界和 产业界的技术发展过程来加强对它们的理解。
2.1.1 协调技术发展史
先让我们从学术界研究过程和产业界实践过程回顾下协调技术发展史 。
1. 学术界研究过程
1975年 ， Akkoyunlu、Ekanadham和 Huber在论文 SomeConstraints and Trade-offs intheDesignofNetworkCommunications中 首次提出两组匪徒通信的问题。1978年 ，JimGray在论文 NotesonDataBaseOperatingSystems中 将 该 问 题正式命名为两将军问题( Two Gene rals'Problem) ，描述 在不可靠通信环境中如何协调达成共识。
1982年，基千两将军间题的不可 靠通信环境，继续出现拜占庭故障( Byzantine Fault,将军故意传递伪造的错误消息）的新挑战，LeslieLamport( 2013年图灵奖获得者）提出拜占庭将军问题，从而解决拜占庭故障下的共识问题。
1985年，BirmanKenneth在论文 ReplicationandFault-ToleranceintheISISSystem中提出 Broadcast技术，并于1987年和 JosephThomas共同发表论文ReliableCommunicationinthePresenceofFailures , 构建组播 ( GroupBroadcast, GBCAST) 协议基础，实现基千组播成员视图 ( View) 的原子广播（AtomicBroadcast, ABCAST)，从而解决共识问题。
1988年，BrianOki和 BarbaraLiskov( 2008年图灵奖获得者）在论文 Vie ws tampedReplication: ANewPrimaryCopyMethodtoSupportHighly-AvailableDistributedSystems中详细描述基千主 复制 ( PrimaryCopy) 技术实 现高可用分布式系 统的过程。该论文的核心思想是主服务器负 责复制数据逻辑 ，以及主服务器 故障发生 后的重组 ( Reorganize) 过程，从而应对服务器 崩溃和网络分区 的故障场景。由千采用类似时间戳( Timestamp) 的 Views tamp来检测复制中丢失的信息，所以简称视图复制( ViewstampedReplication, VR)。
1989年，LeslieLamport（提出过拜占庭将军问题）发表文章 PaxosislandinGreece,当时并未引起太多重视，直到 1998年，他在论文 ThePart-TimeParliament中将 PAXOS进行了严格的数 学证明，之后基于 PAXOS的各种变体将该理论不断 完善优化，形成当今业界最流行的技术 之一。
2013年，斯坦福大学的 DiegoOngaro和 JohnOusterhout在 RAFT论文 InSearchofanUnderstandableConsensusAlgorithm中将复杂 的 PAXOS理论用更简单的方式描述，同时参考VR的工程落地性，极大地帮助了开发人员对PAXOS的理解，从而以RAFT为基础的开源代码展现出蓬勃生机。
2产业界实践过程
l) 企业领域高可用集群
产业界多服务器 的协调产品发展过程 是从双机高 可用集群系统逐步演 进到大规模分布式系统。双机系 统从 1960年的研究项目演进到 DatapointARCnet商用产品，再逐步 发展为DECVAXcluster。在大型机领域，IBM 在 1990年发布了 Systems Complex系统，提供双机容错能力 。早期的双机系 统，通常都是通过主／从 ( Primary/Secondary) 模式实现系统协调的 ，正常时都由主 ( Primary) 来裁决，异常时 Secondary角色切换为新的 Primary角色继续提供裁决功能。高可用集群如图 2-1所示。
图2-1 高可用集群
20世纪 90年代，随着业务的迅速增长 ，多个厂家都发布了支持超过两个节点的高可用集群产品。例如，IBM的PowerHA SystemMirror产品 、HP的 Serviceguard产品、Oracle的 SolarisCluster产品、RedHat的 Cluster产品、开源的 Linux-HA、Microsoft的 MSCS(MicrosoftClusterServer) 产品，以及 Veritas公司的 VCS(VeritasClusterServer) 产品。
特别是 VCS产品，它引入了 原子广播技术实 现全局成员服务和 与原子广播 ( GlobalmembershipservicesandAtomicBroadcast, GAB) 模块，提供了集群仲裁和共识服务。
全局成员服务和与原子广播模块运 行在专 有网络中 ， 与数据访 问路径的业务网络隔离。该专有网络的交换机提供集群节点间通信和协调的能力，实现独立的控制网络，保证控制平面的服务质量。但是，该网络存在交换机异常时集群出现脑裂 ( Split Brain) 的问题，此时某些服务器 之间无法 通信协调，但是数据通 路都是正常 的，如果所有服务器 都继续写入数据，那么很可能出 现数据一致性问题，为此引入 IOFencing技术 。
如图 2-2所示，当专有网络交 换机异常 时，集群可能会被分为两 个子集群，子集群内的服务器可以相互通信。为了解决子集群同时写入出现的数据一致性问题，需要通过 IOFencing技术选取某个 子集群继续工作。由千专有网络异常 ，只能依赖正常的数据路径支撑选取，同时数据路径如果 错误，就会导致业务中断，也就没有新数据写入，所以数据路径非常适合完成该工作，其步骤如下 。
图 2-2IOFencing技术 原理
· 配置磁盘阵 列 ( SAN存储）支待 SCSI(SmallComputerSystem Interface) 的预留(Persistent Reservation) 命令。登录 SAN 存储，配置奇数个协调盘 ( CoordinatorDisks)，保证集 群的服务器都能发送预留命令给协调盘 。其中预留命令就 像原子操作 ，多台服务器 给某个协调盘发送该命令，只允许其中一台服务器 预留成功，其他服务器预留失败。
· 当集群间通信协调网络交 换机异常 时，集群出现脑裂，子集群内的服务器相互确认。当交换机异常时，协调网络心跳探测包返回部分失败并确认无法和对应服务器通信， 从而 使能 相互通信的服务器形成子集群，并且从子集群中选取一个代表参与 协调盘的竞争（通常加入集群的服务器会分配 ID, 此时选择ID较小的服务器作为代表），避免子集群的多台服务器同时去竞争，导致竞争算法成功率降低。
· 代表两个子集群去竞争的服务器 A和服务器 B, 分别在 SAN存储竞争奇数个协调盘，竞争到多数的服务器 将胜利，如服务器A。竞争成功的服务器所在的子集群将继续工作，如服务器 A所在的子集群。竞争失败的服务器所在的子集群将停止工作，如服务器 B所在的子集群。
通过 IOFencing 实现脑裂时的协调能力，提高集群在异常场景的可用性。对千特别极端的异常场景，如专有网络交 换机全部出现故障，可以结合子集群的服务器 数目、服务器集群ID的数值作为竞争协调盘的优先级输入 （如竞争时间间隔），从而从工 程上支撑协调成功。
