《点兵三国》游戏服务器上线遇到的一些问题
最近比较忙，一个人做游戏服务器真的好累，主要是杂七杂八的事情太多，不过还是要抽点时间出来总结下：
首先，我们是一个回合制实时对战类的手游，腾讯云租的服务器12核60G内存40M带宽。
一，刚开始和前端协商好的战斗机制就是，前端处理逻辑，服务器仅仅转发，而且不开房间线程，也就是说A，B两玩家对战，转发战斗信息是由各自的玩家线程去
操作，这样做法效率会比较高，不需要开个房间来专门转发他们的数据，也比较省流量。但是弊端也很明显，一旦一个玩家掉线了，重连回来的时候，就要依赖
另一个玩家恢复战场数据，而且移动端的网络很不稳定的情况，问题就会很复杂，客户端做起断线重连，恢复战场就很麻烦，因此现在的战斗问题还是比较多，
丢包或者延迟都会影响到战斗流程，又不知道哪个一个客户端才是正确的。而且如果想扩展做到观看战场，没有房间的概念，很难做。
优化措施：每一场战斗给AB玩家开一个房间线程，如果服务器不想参与战斗逻辑计算里面去，AB除了每操作一步把信息发到房间，由房间来转发，还隔一段时间就
把场上状态发给房间，房间线程会存起来这个数据，和客户端商议多长时间同步一次，一些关键的操作由服务器来控制，例如切换回合，断线重连，战场数据恢复，
这种做法会比较耗流量。
二，后台在发邮件的时候，发错了，不小心给全服玩家发了50w元宝，我勒个擦，6千玩家，相当于发了3亿rmb！！！还好刚发完就发现了。
处理方法：
1.立即kill掉游戏节点，以防玩家数据回写数据库，因为我们机制是，玩家下线时会回写数据库，或者每5分钟回写一次数据。
2.把全服玩家的这类型邮件从数据库里全删掉。
3.查找全服玩家，元宝大于50w的，基本都是好精明的玩家，领了邮件就立即退出游戏，保存到数据库了，查找到总共有2个这样的玩家，然后把他们的元宝扣除
元宝。
最后，确保没什么问题了，再重启服务器，真的好惊险，吓出一声冷汗！！！
三，匹配线程出问题，无法匹配到人，这是因为在青铜段位的匹配列表里，有一个僵尸玩家，这玩家不在线了，但是一些未知原因导致他依然残留在匹配列表里，所以
青铜段位的某些玩家一旦匹配到该玩家，就无法正常进入战斗了。
处理方法：
因为匹配列表的玩家数据都是依赖玩家点击退出匹配按钮，或者直接退出游戏或者掉线的时候，服务器操作匹配线程，从匹配列表删除该玩家数据，但是或许还有一些比较
特殊的原因导致，服务器操作不成功，或者客户端通知不成功。所以需要在玩家查找匹配的时候，一旦遇到某个僵尸玩家，再通知线程去删除这个僵尸玩家，确保万无一失，
外服网络环境比较复杂，很多东西可能不是按照套路来出牌，所以在一些数据使用的时候必须判断一下合法性，并且在不合法的时候，还要有一个合理的解决方案。
四，开新服的问题，刚开始我们是想着做大世界的服务器，结果运营商那边要开新服，本来开新服没什么，但是遇到两个问题
1.我们团队是没有专门做http后台的人员，所以当初的充值，都是游戏服务器直接写的url充值回调，而且是针对第一个游戏服的ip地址写的url，渠道包那边只会给我们配一个
充值回调url，所以我们要开新服，充值地址肯定是会变化的，但是所有的渠道包都只配了我们第一个服的充值url。
按常理来说，如果有后台http，这些都不需要游戏服务器去处理的，因为渠道只管配一个我们后台的http充值地址，然后后台那边根据这个url地址里的透传参数是哪个服，然后再
路由到具体各个游戏服务器，譬如：
透传参数是1， http://127.0.0.1:8001
透传参数是2， http://127.0.0.1:8002
然而，我们并没有后台，没法自己写了个rpc：call的回调，将第一个游戏服务器同时也作为一个充值汇总点，渠道包所有的充值，先跑到他们配的那url回调，即第一个游戏服务器，然后
根据透传参数，确定充值的是第几个服务器然后再rpc：call 远程连接到目标服务器进行充值，真可谓是分布式充值啊，以后哪个服务器都能单独停，唯独第一个服务器不行，因为其他服
务器都得依靠它。
五，开新服的时候得注意，当初设计的一些全局进程，因为刚开始是按照大世界的服务器来设计，为了应付分布式节点因此很多进程是global的形式，做分服的时候就会出现数据紊乱，后面全改为local了。
总得来说，还算基本顺利，服务器没试过宕机，性能消耗极低，cpu平均利用率不到1%，峰值也就8.9%，而且我们是12核，算下来是很低的了，内存利用率不到3%，而且这个linux机子里面开了
两个对外游戏服，两个内部测试服。
最后，必须注意的一点是，游戏上线在即，服务器配置人员最基本需要2+1， 即2个服务器开发（主程负责开服，性能，处理线上问题，小弟负责后续逻辑开发，找bug），还要1个后台，做充值，统计数据等等。
我就是招人时太不坚定了，导致游戏上线都还是一个人，累成狗，主要还是杂七杂八事情太多，容易遗忘！
