监管码服务器维修,云风的 BLOG

我们的目的是尽量把每个部分做的简洁清晰，功能单一。游戏逻辑服务器可能是有最复杂的处理流程，所以我们务必减少它处理的事务。比如 聊天等。

那么还有什么可以剥离的事务呢？其实对于作弊检测，监视数据交互等都属于这一类。比如，如果我需要得到所有 player 所在的坐标的地图，直接向逻辑服务器索取，对这台服务器的负担就比较大。

现在想到的方案是，由连接服务器把需要传递给逻辑服务器的数据 clone 一份，发到另一台广播服务器上(暂定名)。这台广播服务器只负责接收数据，而不会有任何数据反馈。这样，不会给连接服务器带来过大的负担。

广播服务器可以选择把数据筛选再广播到更多的服务器上，让每个服务器处理更细致的任务。例如 player 的坐标，可以通过筛选出所有移动相关的数据包得到。并且可以根据这个有限的检测出速度作弊。GM 也可以连接到这里，获取整个游戏世界中 player 的位置分布图而不需要担心这个操作增加逻辑服务器的负担。

广播服务器应该是可以随时连入随时断开的。如果支持这个特性，那么它还是需要跟逻辑服务器通讯。我们的逻辑服务器跟连接服务器是用脉冲(或者心跳)保持通讯的节奏的。所以，广播服务器在接入连接服务器时，连接服务器只用通知它脉冲号是多少。然后广播服务器再向逻辑服务器索取初始状态，就可以随时和逻辑服务器同步了。

例如，广播服务器在第 100 个脉冲接入连接服务器，那么它就具有了第100个脉冲之后的所有 client 发过来的数据包。之后它跟逻辑服务器建立联系，假设逻辑服务器在 110 个脉冲的时候通知广播服务器所有状态数据(逻辑服务器可以 fork 一个子进程慢慢发这些数据)。下面的工作，广播服务器可能在 120 个脉冲接收完所有这些状态数据。它可以丢弃掉 100~110 之间的数据包，并把 110~120 之间的数据包作用于 110 那个时候的状态数据上，得以跟逻辑服务器同步。

有了这台广播服务器后，我们可以多出很多运用，这里就不一一展开讨论了。