三界跨服实现方案

返回阵容信息

获取城池内玩家列表

返回

本服服务器3

跨服服务器

定时执行结算逻辑

战斗，并返回战报

发送奖励事件

启动后，向跨服服务器注册本服务器

城池探索协议：

通知在线玩家，收到新邮件

发送奖励邮件

本服服务器1

常见问题：1.跨服服务器存储哪些数据？答:由跨服玩法产生的新数据都由跨服服务器负责管理存储，其他功能模块产生的数据都在本服服务器中维护。 如：跨服分组数据，地图城池数据，留言板，各个跨服排行榜数据，玩家在跨服玩法中产生的如 体力，威望，士气，攻守记录，破坏令，征服值，天兵，信徒分配等2.跨服服务器某些玩法中需要拿到玩家非跨服数据怎么办？答： 方法1:通过\"通信组件\"从本服服务器内存中拿 方法2:跨服服务器保存一份数据副本，且需要对此数据做同步 两种方法视具体的业务功能取最佳实现方法，一般来讲跨服中使用多的，取方案2。 如玩家的VIP等级，等级，昵称，神力等数据，采用方案2获取 如玩家的武将阵容数据，金币钻石经常会变动，采用方案1获取。3.跨服中需要对玩家某些数据做修改怎么办？如玩家金币，钻石，邮件等答： 跨服服务器不直接修改玩家数据，只向本服服务器发送触发的玩家事件，由本服服务器对事件进行实现处理。 如：收到一份新邮件，向本服服务器发送“收到新邮件”事件，本服调用本地API进行发送邮件操作。 如：领取奖励，向本服服务器发送“收到奖励”事件，本服服务器调用本地API进行添加物品操作。4.本服其他功能模块有可能会用到跨服玩法中的数据，怎么办？答： 因为跨服玩法与其他功能模块耦合度不高，此种情况出现较少，如需要参照“问题2”实现方法。 如：跨服玩法中，天兵属性会影响到竞技场，王者荣耀玩法，取方案2即可。5.本服其他功能模块会不会修改跨服数据？答： 不会。如有参考“问题3”。

城池探索

常见功能流程示例：

整体思路：

玩家1

获取玩家阵容信息

通信组件

本服服务器2

新建一个跨服服务器，跨服相关的请求协议都通过本服服务器转发至跨服服务器，由跨服服务器独立处理跨服相关的业务逻辑以及负责维护相关数据。

转发消息

获取三界争霸开启状态协议：

DB

本服服务器n

跨服方案比较:1.利用redis做数据共享方案优点：开发相对简单缺点：a.在多个服对redis数据同时做操作时，会产生同步问题，加锁较麻烦，且开发者容易忘记。 b.跨服排行榜结算，比较麻烦。首先要考虑结算程序争夺问题，其次结算后发送邮件，不能实时发给在线玩家，且还需要玩家主动获取，实现上绕了一步。 c.世界聊天，势力聊天，不能很好的实现 d.实时获取其他服玩家阵容数据，不易实现，如果放redis，数据量较大，且需不时同步，影响其他功能处理效率。2.服务器转发方案优点：能很好的实现跨服需求，实现方式相对友好缺点：编码量增加。总结： 利用redis数据共享，实现跨服，真正意义上不是一个\"真\"跨服，在某些功能实现上需要走弯路。利用服务器转发到同一跨服服务器，这种方案是一种较好的跨服实现方案，因为其设计初衷就是将所有玩家集中到一台服务器进行交互，且其更易维护，更易扩展，更易满足更高级别的交互需求。

......

选择某个玩家战斗

获取三界争霸开启状态

攻击协议：

跨服排行榜结算流程：

获取城池内玩家信息协议：

查询玩家阵容

通信组件设计：通信组件是一个简单的远程通信长连接框架，底层基于Netty实现TCP通信，内置的消息协议采用简单长度帧结构，传输数据格式为JSON。启动后，通信组件会在两端间自动建立一条长连接，且两端间只会存在一条长连接。通信组件内置对此长连接的维护，断线会自动重连，且有心跳包机制，长时间无响应会自动重建等。通信组件实现了同步请求方式，无需异步处理得到的数据，调用方便。通信组件的两端，都采用单线程模型处理接收到的请求。

三界跨服实现方案

玩家2

client

网络模型图：