重归混沌的BLOG

在我刚开始写代码时，许多书籍不断教导我遵循正交性、DRY原则（Don’t Repeat Yourself）和SPOT原则（Single Point of Truth）等编程准则。

这些原则确实能够显著提高代码质量和可维护性，我也乐此不疲地在日常开发中应用这些原则。

然而，当我转向编写游戏服务器代码时，却发现自己常常难以严格执行这些原则。

在游戏服务器的开发中，各个模块通常独立存储它们所需的数据。

用关系型数据库的术语来说，每个模块可能会使用独立的table。不过，游戏服务器的存储方式通常并不是按字段构建table，而是将结构体（struct）序列化为blob格式后进行存储。

模块之间很少通过外键进行约束，数据一致性和容错性完全依赖于代码的逻辑处理。

通常，模块内部负责将数据存储到数据库。如果多个模块共享一个table，由于各模块落地时机问题，如果不妥善处理，会大大增加数据不一致的风险。

此外，加上强类型语言的约束以及各模块之间相似却微妙的逻辑差异，迫使开发者反复编写相似但不完全相同的代码。

这些年，我尝试了不同的方法来增加代码的复用。

1. 抽象中间结构：当我们需要使用某段代码时，可以将DB结构转换成抽象的内存结构，处理完业务逻辑后再将内存结构转换回DB结构进行存储。
2. 复用设计好的DB结构：在设计模块数据结构时，复用一些通用的DB结构，并直接调用相同的算法代码。

然而，这两种方式都有很大的局限性。

例如，方式1可能会转换1000个数据，但最终只修改其中的1个数据。不进行转换是不行的，因为修改一个元素时可能会读取其他数据。一个典型的例子就是抽卡。

方式2的复用性更差，举例说明：

struct common {
    // 一些公共字段
}
struct entry_a {
  struct common c;
  // 其他字段
}
struct entry_b {
  struct common c;
  // 其他字段
}
struct module_a {
  struct entry_a[] list;
}
struct module_b {
  struct entry_b[] list;
}

由于强类型语言的限制，几乎不可能直接用相同的代码同时处理module_a.list和module_b.list。

现实中的情况更复杂，比如entry_?.other_fields往往会以某种方式影响struct common[] list的逻辑。

在我以前的游戏服务器开发中，我一直被数据库落地给禁锢了。

我一直认为数据库落地的不一致是无法解决的，因此也就不可能抽象出公共模块来存储并处理不同模块中相同的逻辑。

这就导致了，在进行代码设计时，无法自由的进行抽象。从而在方式1和方式2之间徘徊。

直到最近我终于找到了部分答案。

解决方案其实也很简单：模块不再负责数据的落地，而是通知落地框架需要落地的数据。

落地框架将在合适的时机（如每秒, 或每条协议之后）统一处理所有脏数据的落地。

如果在落地之前服务器崩溃，丢失的也仅仅是最后一秒的修改，相当于游戏回档到1秒前。

这对玩家几乎没有影响（充值问题可以通过掉单处理，充值服务器只需重新补发1秒前的订单即可）。

为强类型语言的游戏服务器设计这个落地框架会比较麻烦，但收益是巨大的。

从此在进行数据库抽象时，我们不必再有数据库的心智负担。可以像普通应用程序那样进行自由的抽象。

在之前的游戏设计中，好友功能只在同一服务器内生效，涉及到以下几个操作：

• A玩家想加B玩家为好友，首先需要向B玩家发出好友申请。
• B玩家可以选择删除申请，也可以同意。一旦同意，A和B的好友列表中都会同时显示对方。
• 成为好友后，A每天可以向B送花，A和B的关系会因此增加友情值。当B收到A的花时，双方的友情值也会增加。每日送花的次数会在0点重置，但累计的友情值不会清空。
• 根据友情值的累积，A和B可以领取不同档次的奖励，每个档次的奖励只能领取一次。

最近策划提出了一个新需求，要求去掉服务器之间的限制，使所有服务器的玩家都可以互加好友，且在操作上与同服好友无异。

面对这个需求，我有两个选择：

1. 单独做一个服务，将所有好友关系集中管理。这样可以避免数据一致性问题。
2. 扩展现有的本服好友系统，将跨服好友纳入其中，但会涉及到同步问题。

虽然单独做一个服务能够较轻松地解决数据一致性问题，但也带来了新的挑战：

• 其他模块可能依赖好友关系，如果把好友关系放在一个单独的服务中，依赖此关系的业务需要异步查询，增加了不确定性。
• 当玩家数量和在线人数达到一定规模时，如果需要进行水平扩展，数据一致性问题仍然会重新浮现。
• 由于游戏已上线，如果跨服好友和本服好友分开存储，两个系统的融合也会带来不小的复杂度。

因此，我最终选择了扩展本服好友系统，让它能够接管所有好友关系，而不仅仅是本服好友。毕竟，“复杂度留给自己，为他人提供简洁的接口”才是最佳选择。

好友关系是强双向的，因此将好友关系存储在各自玩家的服务器中必然涉及数据一致性问题。

在处理好友申请和同意申请时问题不大，这些操作可以很容易地设计为幂等操作。比如，B同意A的好友申请时，可以先向A所在服务器添加好友关系，成功后再从B的申请列表中删除关于A的申请。即便在中途协议超时，也可以通过重试机制来解决。

然而，送花、收花和友情值的处理让我陷入了困境。

因为送花只能每天进行一次，而收花必须在送花之后才能进行。这两个操作都和每日的0点相关联，意味着送花操作无法保证幂等。

不过这也不是很重要，因为其最终的导向是友情值，而友情值才和奖励挂勾。

我最初的想法是，送花和收花完成时，先在本地计算出最新的友情值，然后将这个值同步给好友的服务器。

但我很快发现这个策略存在问题：A收B送的花会增加A和B之间的友情值，而B收A的花也会增加同样的友情值。如果双方同时进行送花或收花操作，友情值可能会被相互覆盖。

这就像是数据库的双主机制，问题开始变得棘手。

经过与同事讨论。他建议不再进行数据同步，当需要使用友情值时，直接从对方服务器获取对方操作产生的友情值，然后与本地的友情值相加。

我很快否定了这个方案。

因为玩家登录时，客户端需要拉取好友列表进行红点提示或其他展示。

如果按照此方案，我必须查询所有好友所在的服务器。

最坏的情况是，有50个好友分别在50个不同的服务器，这会导致协议请求数量放大50倍。

尤其是停服维护再开服时，这个瞬间的消息量是不可接受的。

这些年我刻意对抗性能强迫症时养成了一个习惯，就算一个方案在性能上不可行，我也会忽略性能来思考他的结果究竟是不是对的，有没有可能达成更简洁的抽象。

经过仔细的思考之后发现，虽然性能问题让这个方案行不通，但它揭示了友情值机制的底层逻辑。

通过简化，我们可以将操作归纳为以下公式：假设玩家A和B的友情值为F。

• A一次送花产生的友情值为a1，一次收花产生的友情值为a2
• B一次送花产生的友情值为b1，一次收花产生的友情值为b2

那么，F的最终值就是a1 + a2 + b1 + b2。

从公式中不难看出，F是由A和B各自操作产生的友情值之和。

因此，我们无需在用到友情值时查询对方服务器，而是将友情值拆分为F_A和F_B，在需要时将F视为F_A + F_B。

这样，A送花时可以本地更新F_A，并尝试将F_A同步到B所在的服务器。B的操作也是如此。

这解决了双主问题，两人分别同步自己所有权的数据，即使同时操作也不会产生冲突。

ps. 这篇博客之所以值得一写，是因为在扩展已有代码时，很容易陷入旧有的思维框架，难以跳脱出来。当发现数据所有权冲突时，如果我们仔细思考一下，这块数据中，到底哪部分该由谁管理，也许就可以解决双主问题。

pps. 解决完所有权问题，之后的解决方案又回到了我之前提到的本地事务 + 重试的分布式编程范式。

ppps. 在游戏分布式编程中，强一致性几乎是不可能的，最终一致性才是我们追求的目标。

当我们要测试一个’算法’是否正确时，常常会打开代码编辑器为其编写测试代码。

这种测试往往被称为单元测试，即测试相对独立的最小单元。

由于算法往往都是一个独立的个体，没有依赖，因此很容易为其编写测试代码。

这里的“容易”指的是，我们除了设计testcase之外，不会有额外的心智负担。

当我们开始为业务逻辑编写测试代码时，其复杂程度往往会是我们放弃的开始。

举个例子，class A依赖class B和class C。

当我们为class A编写测试代码时，为了解决class B和class C对测试结果的干扰，或者验证class A执行结果的正确性，往往需要为class B和class C编写mock class。

这意味着我们在每写一个class的同时，也需要维护至少一个对应的mock class，以方便依赖的模块来编写测试代码。

在一些编程语言中，还意味着我们需要为每个class提供一个interface的定义。即，class A依赖的是interface B和interface C，而class B和class C只是interface B和interface C的实现。不然无法实现测试时注入mock class的需求。

我简单尝试了一下，很快便放弃了。

一是因为它对业务有侵入性，需要强制定义interface；二是因为我认为，为每个class维护一个mock class，工作量太大了。

后来我尝试对这种测试思路做出一些简化。

在编写测试代码之前，我会先人工分析出这些class之间的依赖关系。先为依赖链中的末端class编写测试代码。

当某个class的测试代码成功执行后，就认为这个模块是正确的。然后再依次向上进行测试，直到测试完依赖链的顶端。

在这个过程中，我不会提供mock class，而是直接读取到所需要的class中的内部状态来验证结果是否正确。

以上面的依赖关系为例，我会先为class B和class C编写测试代码。

当我认为class B和class C没有bug时，就会开始为class A编写测试代码。

为了验证class A结果是否正确，我会直接读取class B和class C的内部状态来验证。

但这依然不足以让我为游戏服务器编写测试代码，因为游戏服务器是有状态的，而且依赖关系远比我想象的更复杂。

有一天，我突然灵光一闪，想看看lua和redis是怎么来做测试的。

我发现它们也没有mock class（这里的class仅代表某个代码单元，不局限于语法）。

但是作为互联网开源软件，它们的测试是非常到位的，不然无法保证质量。

它们采用的方式都很类似，都是针对特性进行测试，而不是某个函数或class。

lua作为语言虚拟机，它是没有API的，但为了帮助测试，它会在测试模式下导出一些API用于感知当前luaVM的内部状态。

redis作为一个单独的服务，它是从协议层面去测试每一个特性的。

这给了我很大的启发。我想游戏服务器也是需要从协议层面去测试所有功能的，虽然这样代码覆盖率没有单元测试那么高，但想必对代码质量也是有足够帮助的。

既然通过协议来对游戏服务器进行测试，那就势必要启动真正的游戏服务器，这就会导致更多的外部依赖：时间、配置、数据库。

• 时间会要求我们在测试某个功能时，服务器时间必须处于某个指定的时间区间。

• 配置会要求我们在测试某个功能时，某个配置必须包含多少条数据或什么数值，以便测试一些corner case。

• 数据库会有持久化问题，因此某个功能测过一遍之后，状态就被保存下来，下次就无法再次触发了。

这些外部依赖无一不在揭示着“测试代码不能重复执行”这一问题。

为了解决这个问题，我当时的设想是，每测试一个功能就将数据库清空，然后时间修改到本功能所需要的时间，同时为每一个testcase保留一份配置用于测试。

但随之而来的问题就是，因为清档了，所以每执行一个测试用例，都必须要创建新号。

而测试A模块时，它可能对B模块的数据有依赖，否则协议就无法成功执行。

我最初的想法是，在测试代码库中提供很多辅助条件函数。

随着testcase的增加，需要新增的辅助函数将会越来越少。

比如我要测试A模块，它需要玩家等级达到35级，那么就有一个辅助函数，它可以将玩家升到指定等级（是通过正常协议途径，而不是GM直接修改，因为升级有可能还会触发连带效应）。

后面再依赖玩家等级的testcase就不需要再编写这个辅助函数了。

这虽然很麻烦，但理论上它是完备的，可以测试任意代码。

为了验证这一想法，我挑了一个SLG的核心地图玩法，为其编写了测试代码，来证明它的可行性。

事实证明，这确实是可行的，但也确实是麻烦的。

因为我不仅遇到了为玩家升级，还碰到了为英雄升级，为技能升级，装备技能，操作队伍等一系列的测试辅助需求。

我想朝着这个方向继续简化，却一直没有头绪。

随着这两年我对游戏服务器理解的加深，以及见到了不一样的GM创号思路，我发现我终于可以简化这一流程了。

首先，我之前为每个testcase保存一份配置表是没有必要的。

一般来讲，每个模块只会需要有限的几个表或几行数据。

我们只需要在测试框架中提供修改配置表的能力即可。

在运行测试代码前，可以直接将配置改成测试代码需要的数据即可。

其次，为了解决模块间的数据依赖，使用辅助函数达到本模块要求是可行的，但不是必要的。

据我这两年的观察和反思，模块间的依赖其实没有那么紧密，大部分情况下只要分为达到和达不到即可。

比如我需要玩家等级为30级，那么100级也是满足的。

因此提供一个GM指令，创建一个足够高级的号就足够了。

如果恰好我们需要测试的模块也被高级号给初始化了，我们的testcase代码可以直接操作数据库，清空这部分数据，然后重新登录即可。

lua在测试模式下导出一些API用于感知当前luaVM的内部状态，也给了我一些启示。

我们可以增加一个指定GM指令用来获取玩家或全服的状态，用于我们在测试代码中感知游戏服务器进程中的准确状态。

如果游戏服务器采用了分布式技术，还需要提供一个透传GM指令，用于获取分布式系统中某个服务进程中的状态。

除此之外，测试框架还需要提供重启集群和动态修改时间的能力。

总结如下，测试框架只需要提供如下能力即可满足绝大部分测试需求：

1. 创建高级号的能力

2. 直接访问数据库的能力

3. 修改配置文件的能力

4. 修改服务器时间的能力（包括进程运行时修改）

5. 重启集群的能力，用于每测试一个用例，都清档重启

6. 感知集群内进程状态的能力

至此，经历七年的思考，我认为这个测试方案终于达到了可以实践的阶段。

ps. 本文是我在实践2个月之后写出的，基本上可以确定心智负担极小。

pps. 让我们将视野拉高，由于每次测试都将数据库清空，因此数据库中的数据也可以等价于内存结构。与此同时，很多单元测试的技巧也可以拿来使用。比如要保持测试用例尽可能的小（一旦测试用例过于复杂，测试用例的正确性就不能得到保证）等。

最近终于给silly实现了etcd driver。

下一步就要基于etcd来实现我去年提到的分布式框架了。

但在此之前，我需要知道etcd的边界在哪里，他是如何保证一致的，是否有幻读等问题。

由于etcd采用了raft共识算法，所以我需要了解raft的一些基本概念。

最近懒得阅读英文文章，因此在学习raft之前，我先查了一大堆中文资源，最后我都不太满意。

最终只能去啃CONSENSUS: BRIDGING THEORY AND PRACTICE, 于是就有本文。

CONSENSUS: BRIDGING THEORY AND PRACTICE中几乎介绍了需要实现raft中的方方面面，但我并没有看完，因为我只是想了解raft算法的边界。

因此本文只是按我的理解，从leader选举、日志复制和安全性三个方面来描述一下raft算法，其中我会着重描述安全性。

因为我查到的所有中文资料中，对安全性的描述，我最不满意。

raft使用心跳机来触发leader选举，选举机制如下：

进程状态分为follower、candidate和leader三种。

所有服务器启动时都默认是follower状态。

当follower接收到leader或candidate进程的有效RPC请求时，会保持在follower状态。

leader会定时向所有follower发送心跳包(没有日志条目数据的AppendEntries RPCs即为心跳包)来保持他的权威性。

如果follower在election timeout时间内没有收到心跳包，那么follower就会发起一次选举，来选择新的leader。

整个选举流程如下：

1. 一个folllower增加它的当前term(任期)并转换为candidate状态。
2. candidate给自己投票，并向所有其他服务器发送RequestVote RPCs。
3. candidate 一直会保持在candidate状态，直到以下三种情况之一发生：
   • 得到了超过一半的服务器的投票，此时candidate会转换为leader状态。
   • 另一个candidate赢得了选举，此时candidate会转换为follower状态。
   • 选举超时，此时candidate会增加term并重新发起选举。

每个服务器在给定的term(任期)内按照先到先得(安全性部分会增加一些额外的限制)的原则, 只能投出一票。

超过一半原则会保证在一个特定的term内，只有一个candidate会胜出成为leader。

一旦一个candidate胜出选举，他就会成为leader，并向所有服务器发送心跳包，来宣布他的权威性，并阻止新的选择。

在等待投票的过程中，一个candidate可能会收到其他服务器S发送AppendEntries RPC消息来声明服务器S(自己)成为leader， candidate就会检查服务器S发送的term是大于等于自己的term。

如果是，那么candidate就会转换为follower状态，否则就拒绝这个RPC请求，然后继续保持在candidate状态。

可以看到整个选举过程，本质上就是使用paxos算法就term的值达成一致的过程。

正如paxos一样，raft的选举过程也会产生活锁, 即永远都无法选出leader。

raft为了解决这一问题，引入了随机化选举超时时间，这样就最大话限度地避免活锁。

再来看看日志复制是怎么进行的，自此raft就和paxos没有任何关系了。

raft的日志复制是基于quorum来保证可靠性的。

一旦一个leader被选出，他就会开始接受客户端的请求。

每个客户端请求包含了一个由复制状态机执行的command。

复制状态机可以按日志写入顺序，从前往后执行日志中记录的command，以得到最终的结果。

例如：复制状态机按(set x=1),(set x=5)的顺序执行完command, 那么x的最终值就是5。这也意味着只要集群中各节点中日志一致，各节点中关于某个变量的值都是一致的。

leader先将这个command作为一条新的日志(log entry)追加(append)到自己的日志中。然后对其他服务器并行发出AppendEntries RPCs，要求他们也将这条日志追加到自己的日志中。

当有超过半数的服务器都成功的将这条日志追加到自己的日志中，那么leader就会将这个日志条目应用到自己的状态机中（这就是大名鼎鼎的quorum）。

此时这条日志就处于committed状态, leader已经可以将状态机中的结果返回给客户端了。

在将结果返回给客户端之后，leader会不停的使用AppendEntries RPCs来重试直到所有followers最终都保存了所有的日志。

需要强调的是，这个committed状态是针对leader来说的，当一条日志处于commited状态，就意味着这条日志产生的结果可能已经被返回给客户端了，因此不能丢失。这一点对于后面理解安全性部分很重要。

raft保证所有处于commited的日志都会持久化，并被所有可用的状态机被执行。

整个log的组织方式如下图所示，每条日志(log entry)都会有一个惟一id, 这个id由term和log index组成，其中term就是产生本条日志的，当期leader的term值。

当一条日志处于commited状态时，leader会将这条日志之前的所有日志都commit, 包括前任(整个集群中所有之前的)leader所产生的日志。

leader会始终记录当前已经处于committed中日志最大log index(max_log_index)，这个索引会通过下一次AppendEntries RPCs(包括心跳)发送给followers。

当一个follower知道一条日志处于committed状态时，他就会顺序的将这条日志之前的所有日志都应用到本地复制状态机。

这条规则对于一致性没有任何帮助，只是为了防止当leader宕机时，follower成为leader后，follower能够快速的将自己的状态机和leader的状态机保持一致。

raft的日志机制会使得不同服务器间的日志保持了高度一致，这不仅会简化系统行为，而且会使结果更加可预测，也是确保安全性的重要组成部分。

raft日志有如下属性：

1. 如果在两个服务器中的日志有相同的log index和term，那么这两个日志包含相同的command。
2. 如果在两个服务器中的日志有相同的log index和term, 那么这两个服务器中，这两条日志之前的所有日志，都是相同的。

第一个属性来源于这样的一个事实：leader在一个term内，对于给定的log index最多只能产生一条日志。

第二个属性则被AppendEntries中执行的一致性检查来保证。当发送一个AppendEntries RPCs时，leader会将紧接着本次新增日志(可能有多条)的上一条日志的log index和term，发送给所有follower，如果follower发现自己不存在同样的日志，则他会拒绝这条新增日志。

举个例子，当leader发送了一个(last_term=2, last_log_index=1, entries=((term=2, log_index=2, command="x=1"),(term=2, log_index=3, command="x=2")))的AppendEntries RPCs时，follower会检查自己的日志列表，如果发现自己的日志列表中不存在(term=2, log_index=1)的日志时，follower就会拒绝这个RPC请求。

正常情况下，raft的leader和follower之间的日志列表是一致的，但是当leader和follower之间产生一系列的crash之后，日志列表可能就会变得不一致。

下图展示了一些leader和follower之间的日志列表不一致的情况， 一个follower可能会丢失已经存在于leader日志列表中的日志，也可能会拥有不存在于leader日志列表中的日志。

在raft中，leader会通过强制所有follower来复制自己的日志列表来保证一致性。

当leader向follower中的AppendEntries被拒绝时，leader会不停的向历史日志回退，直到找到第一个和follower相同的日志(term=T,log_index=L)，然后使follower删除日志(term=T,log_index=L)之后的所有日志，并复制从leader中日志(term=T,log_index=L)之后的所有日志。

leader会通过找到和被复制的follower中最新一条相同的日志，然他开始往后复制，直到复制完leader中所有的日志，至此leader和follower的日志列表就保持了一致。

上面的日志机制只保证了可以leader和follower之间的日志列表保持一致，但是并不能保证已经处于committed的日志不会丢失。

下面来看看安全性是怎么做到这一点的。

raft规定，如果一个caididate没有包含所有已经处于committed的日志，那它就不可能在选举中胜出。

一个candidate为了被选举成功，必须要联系超过半数的服务器，这意味着，所有已经处于committed的日志至少会存在于被联系的一台服务器之中(同样基于quorum)。

这里需要重申一下，这个处于committed的日志仅仅指，他被前任leader已经应用到状态机并将结果返回给了客户端的日志。

并不是leader通过AppendEntries RPCs同步过的，已经处于committed中日志最大log index(max_log_index)。

这一点需要思考一下才能得出结论，也是所有中文资料最模糊的地方，也是很关键的地方。

我们来看一个反例：

假如所有的follower都维护了一个committed index, 这个committed index来源于每次leader发送的AppendEntries RPCs中的最大的已提交日志的log index。

整个集群中日志内容如下， S1为leader, 他已经将(term=1, log_index=2)复制到了大多数服务器中，因此S1已经将(term=1, log_index=2)标记为committed，并且为客户端返回了结果。

S1 (term=1, log_index=1, command="x=1"),(term=1, log_index=2, command="x=2")
S2 (term=1, log_index=1, command="x=1"),(term=1, log_index=2, command="x=2")
S3 (term=1, log_index=1, command="x=1"),(term=1, log_index=2, command="x=2")
S4 (term=1, log_index=1, command="x=1"),
S5 (term=1, log_index=1, command="x=1"),

根据规则，本次提交的log_index将会通过下次AppendEntries RPCs同步给所有follower。

因此S2,S3,S4,S5服务中，此时leader已提交的最大的id为(term=1,log_index=1)。

如果此时S1 crash, S5当前持续的最大日志id为(term=1,log_index=1)，是大于等于S2,S3,S4的最大日志id的，因此S5有资格成为leader。

这种情况下已经处于committed状态下的日志(term=1, log_index=2, command="x=2")就会丢失。

因此，如果一个caididate没有包含所有已经处于committed的日志，那它就不可能在选举中胜出只是一个必要条件，并不是用来实现的充分条件。

事实上，当一个candidate发出一个RequestVote RPC时，他会带上自己日志列表中最新日志的(term,log_index), 而集群中别的服务器收到RequestVote RPC时，会拿这个(term,log_index)和自己的最新日志(term,log_index)进行比较，如果发现自己的日志比candidate的日志新(通过比较(term,log_index)二元组来确定），那么就会拒绝这个RequestVote RPC。

由于RequestVote RPC会发给半数以上的服务器，因此当candidate胜出时，他必然会已经包含了所有已经处于committed的日志，不然他就收不到超过半数的投票。

之所以上面说是一个必要条件，是因为candidate也有可能包含超过已经处理committed的之外的日志，这些日志是否需要恢复会产生一个更微妙的问题。

这就需要再次增加一个限制条件来达成一致性，leader只能通过当前日志是否已经在集群中被复制超过半数来判断是否应该提交自己的当期日志，而不能用来判断是不是应该提交前任的日志。

下图展示了为何leader只能主动提交自己当期的日志。

假如在图(c)中，S1过度到term=4，并且继续提交(term=2,log_index=2)，此时(term=2,log_index=2)在整个集群中的复制数量已经超过半数，因此S1可以将这条日志标记为committed。

然后S1生成了一条新的日志(term=4,log_index=3), 在还没有来得及复制给follower之前crash掉了，此时S5以term=3的情况成为leader, 由于他本地最新的日志为(term=3,log_index=2), 因此他可以胜出获得超过半数的投票。

此时他会强制所有follower来与自己保持一致，会覆盖掉已经处理committed状态下的日志(term=2,log_index=2), 这违反了raft的保证。

这里其实还隐含了一些更微妙的问题。在刚开始阅读原文时我没有注意到。

从图(c)之后，假设S1接受了(term=4, log_index=3)的请求并开始复制，他会先复制(term=2, log_index=2)，然后再复制(term=4, log_index=3)。

如果在集群中机器超过半数都已经复制到了(term=4, log_index=2)， 但是在复制(term=4, log_index=3)时，S1再次crash了。

虽然(term=2, log_index=2)在集群中的复制数量已经超过了半数，但是由于(term=4, log_index=3)还没有处于committed。

因此(term=2, log_index=2)还不能被标记为committed, 因此(term=2, log_index=2)是可以被别的leader覆盖掉的。

至此，raft的leader选举、日志复制和安全性三个部分算法总算描述完了。

在游戏服务器的分布式设计中，我们通常避免将密切交互或存在数据强耦合的两个模块分别实现在不同的进程中。

然而，在某些情况下，我们不得不通过RPC在不同进程之间进行通信。例如，在处理玩家请求时，A进程可能需要与B进程进行资源扣除，并继续执行逻辑。

由于网络的不稳定性，A进程向B进程发起的RPC可能会有三种可能的结果：成功、失败或超时。

在分布式设计中，超时问题是最具挑战性的，因为超时可能是由于B进程未收到请求，也可能是B进程执行后的响应未被A进程接收到。

因此，在重试超时的RPC时必须非常小心，因为有可能这个RPC已经执行成功了，只是响应包丢失了而已，这样就会多次扣除玩家资源。

幸运的是，同一个游戏服务器的一组进程通常位于同一个子网下，并且在停服维护期间也是同生共死的。因此，RPC超时的概率通常不会很大，除非服务器超载。

在这种前提下，针对RPC的超时情况，一般的做法是在调用方和被调用方打上详细的日志。如果真的发生了超时，可以根据日志给玩家进行相应的补偿。

最近我遇到了一个有点棘手的需求，经过简化后的内容是这样的：

我们需要在"跨服"给玩家定期（大概几十秒到几百秒不等）产出一定的资源到"本地服"，这个产出的资源需要玩家手动领取。在玩家没有领取之前，只能暂存N个周期的资源产出，到达暂存上限后就停止产出，直到玩家手动进行领取之后，再继续产出。

这个需求的棘手之处在于，在维护时，"跨服"的生命周期很大程度上和"本地服"不一样，也就是说数据包丢失必然会发生，被丢包的玩家必然会丢失这一周期产出的资源。

这种情况下，就不能只打印日志了，因为这是一种必然会发生的事件，而且影响范围是所有玩家，每次维护后手动处理是不能接受的。

经过仔细思考后，我认为要将"跨服产出到本地服"这个行为拆成两部分来实现。

第一步是先将资源产出到"跨服"，这一步在进程内完成，如果跨服进程被关闭，就直接不会产出，下次启动后根据时间戳可以自动恢复出相应需要产出的资源。

第二步是将"跨服"进程中暂存的所有资源同步到"本地服"。同步数据包可能会丢失，但是由于每次总是同步当前玩家暂存的所有资源，所以重试这个同步操作是幂等的。

如果仅仅是产出重试这一问题，到这里问题基本上已经解决了。但是，现实往往是复杂的。

玩家领取资源时，还需要将产出的资源扣除以便"跨服"可以继续产出，而只要行为是"扣除"，无论怎么设计这个RPC请求都不可能被重试。

所以需要进一步改进"跨服"产出逻辑。

"跨服"记录的不再是暂存的资源数量，而是从玩家参与这个玩法时到现在一共产出的"总"产出周期（TotalCycle）和"总"产出资源（TotalResource），这两个值都是只增不减的。

"本地服"同样记录收从"跨服"收到的最新的TotalCycle和TotalResource。

"本地服"每次收到"同步"包之后，根据同步包中的TotalCycle和TotalResource减去"本地服"中的TotalCycle和TotalResource，就能得出本次同步一共产出了多少周期和多少资源。再将本次同步产出的周期和资源合并到"本地服"的暂存周期数（StashCycle）和暂存产出资源数（StashResource）。

当玩家领取奖励时，"本地服"只需要将存储的TotalCycle和StashCycle同步到"跨服"，跨服就可以知道当前还有多少周期的产出资源未被领取。具体公式为：(StashCycle + 跨服.TotalCycle – 本地服.TotalCycle)。

这样在玩家领取奖励时，从扣除暂存资源到加入玩家背包又是在进程内完成的，通知跨服可以继续产出的行为又变成了幂等的。

在整个问题的解决思路中，其实无非就是一点。将一些分布式行为拆分成本地行为+ "同步"行为（同步是指幂等的行为），在拆分过程中，"单调"会是一个很有用的武器。