共识Raft 如何保障多机房数据的分歧性

当机房 A 修正了一条数据的同时，机房 B 也对该数据启动了降级，Otter 会经过兼并逻辑来处置抵触的数据行或字段，以到达兼并成果。为了防止这种抵触，咱们在上节课对客户端提出了要求：用户客户端在必定时期内只能衔接一个机房。但是，假设业务对“事务和强分歧性”有极高的需求，例如库存不准许超卖的场景，通常只要两种选用：一种是将服务部署为本地服务，但这并不实用于一切业务；另一种是经常使用多机房架构，但必定驳回散布式强分歧性算法以确保多个正本之间的分歧性。

在业界，最出名的散布式强分歧性算法是 Paxos。虽然它的原理十分形象，经过屡次修正后往往会与最后设计发生很大偏离，使得很多人难以判别这些修正能否正当。通常须要一到两年的通常阅历才干齐全把握该算法。随着对散布式多正本同步需求的参与，Paxos 的形象性已无法齐全满足市场需求，因此 Raft 算法应运而生。相比于 Paxos，Raft 更易于了解，同时能够保障操作的顺序分歧性，因此被宽泛运行于散布式数据服务中，像 etcd 和 Kafka 等出名基础组件都经常使用了 Raft 算法。

如图所示，咱们启动了五个 Raft 散布式数据服务节点：S1、S2、S3、S4 和 S5。每个节点可以处于以下三种形态之一：

假设某个 Follower 节点在规则时期内未收到 Leader 的心跳信号，则象征着 Leader 或许已失效，集群无法继续降级数据。在这种状况下，Follower 节点会进中选举形式，并在多个 Follower 节点之间选出一个新的 Leader，确保服务集群中一直有一个 Leader，确保数据变卦的惟一决策进程。

那么 Leader 是如何选举进去的呢？在进中选举形式后，这五个节点会各自随机期待一段时期。期待时期一到，节点会先为自己投一票，并将其任期（term）加 1（如图中的 term:4 示意第四任 Leader），而后经过发送 RequestVote RPC（即恳求投票的远程环节调用）向其余节点拉票。

S1失去咨询，S5最先超时动员选举

当服务节点收到投票恳求时，假设该恳求节点的任期和日志同步进展都上游或相反，则会向其投票，并将自己的以前任期降级为新的任期。在此时期，收到投票恳求的节点将不会再动员投票，而是期待其余节点的投票约请。须要留意的是，每个节点在同一任期内只能投出一票。

假设一切节点在选举环节中都未取得少数票（即超越半数的票数），则在选举超时后，节点会将任期加 1 并从新动员选举。最终，取得少数票且最早完结选举倒计时的节点将中选为新的 Leader。该 Leader 随即广播通知其余节点，并同步新的任期和日志进展。

在成为 Leader 后，新的 Leader 会活期发送心跳信号，确保各个 Follower 节点坚持衔接形态，不因超时而进中选举形式。在选举环节中，假设有节点收到了前一任 Leader 的心跳信号，便会中止的选举并拒绝新的选举恳求。选举完结后，一切节点进入数据同步形态，确保日志分歧性。

如何保障多正本写分歧？

当服务节点收到投票恳求时，假设该恳求节点的任期和日志同步进展都上游或相反，则会向其投票，并将自己的以前任期降级为新的任期。在此时期，收到投票恳求的节点将不会再动员投票，而是期待其余节点的投票约请。须要留意的是，每个节点在同一任期内只能投出一票。

假设一切节点在选举环节中都未取得少数票（即超越半数的票数），则在选举超时后，节点会将任期加 1 并从新动员选举。最终，取得少数票且最早完结选举倒计时的节点将中选为新的 Leader。该 Leader 随即广播通知其余节点，并同步新的任期和日志进展。

在成为 Leader 后，新的 Leader 会活期发送心跳信号，确保各个 Follower 节点坚持衔接形态，不因超时而进中选举形式。在选举环节中，假设有节点收到了前一任 Leader 的心跳信号，便会中止的选举并拒绝新的选举恳求。选举完结后，一切节点进入数据同步形态，确保日志分歧性。

详细来说，当 Leader 成功修负数据后，它会生成一条对应的日志，并将该日志发送给一切 Follower 节点启动同步。只需超越半数的 Follower 前往同步成功的反应，Leader 就会将该预提交的日志正式提交（commit），并向客户端确认数据修正成功。

在下一个心跳中，Leader 会经过信息中的 leader commit 字段，将最新提交的日志索引（Log index）告知各 Follower 节点。Follower 节点依据该提交的索引降级数据，仅对外提供被 Leader 最终提交的数据，未被提交的数据不会被耐久化或展现。

假设在数据同步时期，客户端继续向 Leader 发送其余修正恳求，这些恳求会进入队列期待处置，由于此时 Leader 正在期待其余节点的同步照应，造成临时的阻塞。

不过，这种阻塞期待的设计使得 Raft 算法对网络性能的依赖性较强，由于每次数据修正都须要向多个节点收回并发恳求，期待大少数节点成功同步。最蹩脚的状况是，前往的往复时延（RTT）会遭到最慢节点的网络照应时期影响，例如“两地三核心”的一次性同步时期或许到达约 100ms。此外，由于主节点只要一个，这限度了 Raft 服务的全体性能。

为了处置这个疑问，咱们可以经过缩小数据量和对数据启动切片来优化集群的修正性能。须要留意的是，当大少数 Follower 与 Leader 的日志进展差异过大时，数据变卦恳求将会处于期待形态，直到超越一半的 Follower 与 Leader 的进展分歧后，才会前往修正成功的结果。当然，这种状况并不经常出现。

服务之间如何同步日志进展？

讲到这咱们不美观出，在 Raft 的数据同步机制中，日志施展着关键的作用。在同步数据时，Raft 驳回的日志是一个有顺序的指令日志 WAL（Write Ahead Log），相似 MySQL 的 binlog。该日志中记载着每次修负数据的指令和修正任期，并经过 Log Index 标注了是第几条日志，以此作为同步进展的依据。

在 Raft 中，Leader 节点的日志是终身保管的，一切 Follower 节点会与 Leader 坚持齐全分歧。假设发生差异，Follower 的日志将被强迫笼罩以与 Leader 同步。此外，每条日志记载都经过“写入”和“提交”（commit）两个阶段。在选举环节中，每个节点会基于自身未提交的日志索引（Log Index）进展优先选用进展最靠前的节点，从而确保中选的 Leader 领有最新、最完整的数据。

在 Leader 任期内，它会按顺序向各 Follower 节点推送日志以成功同步。若 Leader 的同步进展上游于某个 Follower，该 Follower 将拒绝同步恳求。收到拒绝反应后，Leader 会从日志末尾向前回溯，找出 Follower 未同步或存在差异的日志局部，而后逐条推送笼罩，直到 Follower 与 Leader 坚持分歧。

Leader 和 Follower 的日志同步进展是经过日志索引（index）来确认的。Leader 对日志的内容和顺序领有相对的决策权，当发现自己的日志与某个 Follower 的日志存在差异时，为了确保多个正本的数据齐全分歧，Leader 会强迫笼罩该 Follower 的日志。

那么，Leader 是如何识别 Follower 的日志与自己的日志之间的差异呢？在向 Follower 同步日志时，Leader 会同时提供自己上一条日志的任期和索引号，与 Follower 的同步进展启动比拟。对比关键触及两个方面：

假设以上马意一个方面存在差异，Leader 就会以为 Follower 的日志与自己的日志不分歧。在这种状况下，Leader 会逐条倒序对比日志，直到找到日志内容和任期齐全分歧的索引，而后从这个索引开局按顺序向下笼罩。

在日志同步时期，Leader 只会提交其以前任期内的数据，之前任期的数据则依赖日志同步来逐渐复原。可以看到，这种逐条推送的同步形式效率较低，特意是对新启动的服务并不友好。因此，Leader 会活期生成快照，将之前的修正日志记载兼并，以降落日志的大小。同时，进展差距过大的 Follower 会从 Leader 的最新快照中复原数据，并按快照最后的索引追逐进展。

如何保障读取数据的强分歧性？

经过前面的解说，咱们了解了 Leader 和 Follower 之间的同步机制，那么从 Follower 的角度来看，它又是如何确保自己对外提供的数据一直是最新的呢？这里有一个小技巧：当 Follower 收到查问恳求时，会同时向 Leader 恳求最新提交的日志索引（commit log index）。假设这个日志索引大于 Follower 的同步进展，就象征着 Follower 的本地数据不是最新的。此时，Follower 会从 Leader 失掉最新的数据并前往给客户端。

由此可见，坚持数据的强分歧性须要付出较大的代价。

你或许会猎奇：如何在业务经常使用时保障读取数据的强分歧性呢？其实咱们之前说的 Raft 同步期待 Leader commit log index 的机制，曾经确保了这一点。咱们只须要向 Leader 反常提交数据修正的操作，Follower 读取时拿到的就必定是最新的数据。

很多人都说 Raft 是一个散布式分歧性算法，但实践上 Raft 算法是一个共识算法（多个节点达成共识），它经过任期机制、随机时期和投票选举机制，成功了服务灵活扩容及服务的高可用。经过 Raft 驳回强迫顺序的日志同步成功多正本的数据强分歧同步，假设咱们用 Raft 算法成功用户的数据存储层，那么数据的存储和增删改查，都会具备跨机房的数据强分歧性。这样一来，业务层就无需关心分歧性疑问，对数据间接操作，即可轻松成功多机房的强分歧同步。