一些战斗方案思考

1. 帧同步战斗服相关

1. 弱网下测试同步问题， 测试工具（network link conditioner）

2. 断线重连，战场重入

3. 战斗结果验证，客户端需要屏蔽掉违规操作

4. jni战斗复盘压力测试

2. 服务器自动推荐策略问题

• 需求

1. 玩家进入游戏直接分配服，没有选服列表

2. 游戏内完成新手引导后可以切服务器

3. 服务器列表状态需支持手动修改

4. 运维手动控制开服

• 解决方案

1. gs 推送数据（在线人数，注册人数）到服务器列表所在的服务器。

2. 服务器推荐分优先级别分为首推荐服，和次推荐，同时首推荐服务器和次推荐服务器要有边界限制，不能无限推荐。限制条件参考：在线人数，注册人数，时间段内推荐次数，待详细列出

3. 客户端拉取服务器列表的时候返回数据：服务器列表，主推荐服务器，次推荐N个服务器。推荐服务器进入失败-->次推荐服务器随机--->开服日期从近至远尝试

3. 服务器战斗消峰策略

1. battle验证分成同步验证（战斗完立刻验证），异步验证（battle服务器不忙的时候验证）， 本服验证（仅仅验证上阵数量和战力等简单方式），和不验证（这个就是完全不管了） 四种。

2. 竞技场验证前N场战斗不走battle验证服务器，game服简单验证一下。

3. pve副本前n节闭着眼睛都能打过的，game服简单验证一下，上阵的英雄数量就算过。

4. 有一些稍微关键一点的副本节点异步验证。

5. 如果验证发现玩家作弊的可以适当提高验证等级，对于没有发现作弊的走正常流程。

4. battle复盘策略

1. 战斗服务器全验证，对于战斗耗时比较小的battle，战斗服务器可以跑battle验证
2. 当战斗时间比较长，人数比较多，这种战斗battle服务器验证起来耗时太长，所以不应当走正常的验证逻辑

• 客户端战斗中记录关键点，帧号+谁生谁死等关键事件，或者事战斗log（所有玩家一致，本地结果有效，不用战斗服务器验证）
• 战斗服务器跑到前n个事件，如果一致，战斗就结束，不全跑完就结束（战斗服务器半验证）。
• 抽帧hash验证， 战斗服最多跑200ms，如果跑不到关键点日志就验一次这个hash，退出战斗。（战斗服务器半验证）。

5. 中转换服务器节点消峰策略

1. game适当缓存一些数据，减少中转服务器的请求次数，比如好友推荐打开界面的时候，不直接走全区推荐，先走本服推荐。 玩家主动请求的时候才开始走区推荐，同时加cd。

2. 协议合并。对于实时性不是很强的协议，可以考虑是否可以合并。比如玩家之间一键赠送友情点，中转服务器做了一下cd，通过协 议合并，把相同game的玩家一次性转发过去，不是实时转发。

6. 全区全服的玩家数据更新消峰策略

1. 批量上传数据，单条数据加数据上传的门槛，同时加上传cd，避免开服所有玩家都可以频繁的上传数据。
2. 上传玩家的简要信息部分还需要根据需求重新整理一下，当前为临时需求。
3. 批量上传一次数据上传的量和上传时间间隔需要知道集群的性能后才能定下来