云风的 BLOG

具体 bug 是这样的：

在客户端登录后，服务器会推送个玩家背包的信息，客户端应根据这些信息初始化背包对象。

在场景中的某些掉落品会自动进入玩家的背包，客户端会根据这类信息修改背包的状态。

一般情况下，推送玩家背包信息的网络包一定会先抵达。但是由于一些有关断线自动重连的设计，导致了后一种掉落品信息包抢先在了初始化过程之前。

固然，这个 bug 有简单的解决方案。比如在 UI 系统中 model 和 view 完全分离（我们现在的确是这样做的），而 model 应该先由默认值初始化，不必等待登录完成再触发背包的初始化流程。

但我认为，应该在一个更高的抽象层面来看待这个问题。

物品掉落自动进入背包这条消息是服务器推送过来的，但是这条推送到底意味着什么？

如果是一个银行的客户端。当你的账户下发生了转账行为，别人向你转了一笔钱，如果你刚刚查询过账户余额，那么转账信息抵达后，是否应该由客户端将转账事件中的金额和上次查询的余额合并，自动计算出新的余额？

通常银行客户端软件绝对不会这样做，只会提供一个余额查询的功能。用户收到转账信息后，会再次查询。

这个例子或许并不恰当，账户转账发生并不频繁，用户对余额的关心也没有太多的实时性需求。但是它可以说明一件事情：事件的发生、即使事件会导致状态的变化是双方的共有知识、它和状态的变化本质上还是两件事。

对于网络游戏来说，玩家需要了解虚拟世界中发生的事件，也需要了解和他相关的对象的当前状态，这其实是两个不同的需求。

固然，如果依靠一些预先设计好的规则，客户端和服务器可以达成共识，根据虚拟世界中发生的事件，以及对象的初始状态，就可以同步对象的当前状态。很多网络游戏都基于这个方法设计，但我们应该认清本质：事件传达和状态同步是两件事，之所以选择这样的做法，其实是一种优化手段。因为我们只需要传达事件，省去了状态同步的网络流量。这个方法能成立，基于的是事先部署好的规则共识，以及事件的完整性。

MMORPG 类型的游戏的不同点在于，MMO 的世界很大，几乎不可能做全状态同步，也不可能传达世界中的所有事件。每个客户端都只关心整个世界的极小部分。所以 MMORPG 的设计中，几乎不会采用完全的初始状态 + 所有事件 的方法来同步世界状态。

也就是一部分事件仅仅只用来传达字面的意义，比如“ A 用 X 技能攻击了 B 造成了 Y 点伤害” 这种消息，可能仅用来做视觉表现以及文字 log 在屏幕上传达给玩家，而不会真的和服务器一样执行完全一样的逻辑（在 MOBA 类游戏中，参与人数较少，则可能采用完全逻辑去计算）。比如这个 X 技能导致 B 不能移动，很可能是单独的消息通知的，这样可以避免服务器和客户端由于了解的信息不对等而产生差异。

很多设计者对 “事件通知” 和 “状态同步” 这两个问题认识模糊，导致设计上含混不清。有的地方利用 “事件通知” 去计算状态变化，有的地方又单独设计状态同步协议，是很多 bug 的根源。

我的观点是：应当把 事件通知 和 状态同步 在设计层次严格分离。所有事件通知的网络包都是可以丢弃和乱序的，它仅作为客户端的视觉呈现使用；而状态同步则是应该根据客户端的实际需求来严格同步，客户端处于什么状况，需要关心哪些对象，多少对象，根据这些需要来同步 MMO 世界中的一个子集。这些需要同步的对象既包括玩家自身的数值、背包，也包括了玩家所处的场景，他附近的其他玩家和 NPC ，还可以包括聊天频道信息、任务、排行榜、拍卖行信息。

例如，玩家受伤（HP 减少），自动拾取物件，这些都是事件，如果客户端收到这些事件，可以做出对应的动画表现；而当前玩家的 HP ，背包里有些什么物品则属于状态同步管理的范畴。我们应该使用合适的同步策略来做。可以是客户端推断出状态会发生变化去查询一次和上个已知版本的差异，也可以是向服务器订阅对应的对象的状态差异变化，还可以是简单的请求对象的全量状态数据。采取何种同步方案就属于设计和优化细节了。

如果因为网络流量问题，我们需要做出限制的话，事件通知是可以按信息优先级丢弃或推迟送达的。怎样丢弃可以由设计人员判断信息丢失后会给玩家客户端的视觉表现造成怎样的影响。即使全部丢弃了，客户端也不应该出错，并保持基本可玩。

状态同步应该在一个更高的抽象层面设计实现。所谓同步，无非是将服务器上的一个数据结构复制到客户端。最粗笨的方法是客户端提起请求，服务器全量返回序列化后的数据结构。最早期的 web 服务都是这样做的，相当于玩家不断的在一个他关心的页面按 F5 刷新页面。在这个基础上，优化是必须做的。

我们有很多方法来做差异更新，我在 “如何只基于请求回应模式实现 MMO 级别的场景服务” 一文中提出过我的方案。这未必是唯一的方法。不依赖客户端请求，服务器直接推送差异也是 MMORPG 用的比较多的方法。我认为这些都是针对状态同步的具体优化，可以结合具体情况具体考量。基于客户端请求和服务器直接推送的区别仅在于：基于客户端请求需要消耗更多的客户端上行流量、而服务器直接推送则需要消耗服务器额外的开销去维护客户端到底需要同步哪些信息。至于同步延迟的问题，两者没有什么区别。因为即使是基于客户端请求，也可以提前发起请求，只在状态变化的时候服务器再回应；而不必等到客户端需要时再请求状态差异。

例如大多数 MMORPG 服务器都会在服务器计算玩家周围的对象，并在周围对象移动时推送这些移动信息。我个人认为在流量有限的时候，在场景中树立若干灯塔，灯塔管理灯塔范围内的玩家 id，再由客户端主动查询灯塔要好一些。可以避免服务器在计算每个玩家周围的对象时陷入一个 O(n^2) 的复杂度，也能回避无脑推送巨量的消息。玩家可以跟踪一个灯塔的状态，然后再根据一个玩家列表，进一步选择同步有限几个玩家的坐标（不同设备和不同网络条件下能同时观测的对象数量是不同的）。这样可以更加有效。

回到文初的 bug 。由于断线重连问题导致物品掉落自动拾取和背包初始化乱序的问题。那个自动拾取的消息推送就只会显示一段拾取动画、在屏幕上显示一行 log 文字，最多触发一次背包状态更新的查询，而不会去操作一个未初始化的背包对象了。