MMO游戏终极内测开服一周，问题记录

阅读更多

BUG方面： 

1)逻辑BUG不可怕，都可以修改完

2)逻辑BUG不能影响到游戏的流程，导致玩家无法继续

3)出BUG的时候，如果无法一下子找到原因，要倾向如何维持流程正确性

4)记录日志时，并不是记录最后一步为什么失败，而是要记录一些，能够推断出大致流程的原因

数据库：

4)数据库压力。没想到压力居然出现在了数据库。

现有方式如下：

上层提供写库、写缓存等种种接口。结果到后面，都变成写库。（改到后面觉得重要数据太多了，而且逻辑修订起来也很繁琐）。开服测试的时候，1000的在线玩家，几乎每人都在游戏（比如打怪，做任务）。具体的数据我没拿到，这时候MYSQL已经有点顶不住了。

这种方式用的是应用层单条语句以及接口上对程序员要求较高。其实我很喜欢以前TL的方式。除了RMB相关的及时写库，剩下的定时以及上下线的时候刷一次库。但是刷库的时候又涉及到库的结构方式。比如一些按模块化存储的，最后又得拆分成一条条一句。（但是我想，如果在高级MYSQL里，用事务存储，应该会快很多吧？）

总结，最好不要把数据库语句这种概念抛到逻辑上层，否则会造成语句很零散，而且底层对此很难优化，因为他很难知道这些语句是不是同个玩家的。上层只管改变值，而写库的阀值、时间与否，应该由另外个模块去量化执行

  

团队：

没啥好说的，保持正常的心态，分配好资源，分配好问题，联合攻破。 

 

 

（其实我没做啥，也没做什么很重要的事，尽力看时机和场合发挥自己的光热。）