1. 转档之前策划要和程序、运营一起商量制定周详的转档方案,
要三方根据自己的专业知识和经验来统计出哪些数据需要转档,
怎么转比较平滑和完美,能够尽最大努力照顾到每个玩家的利益,
但又不至于实现成本太高,总之转档数据要全面,不要有遗漏,
特别是和其他系统有交互的数据,更要注意,还有就是综合权衡,
制定出一个最优方案;
2. 转档程序实现尽量用mysql语句和存储过程来写,
因为这样转换速度比较快,而且稳定。
不过有些数据转档涉及到复杂的逻辑运算,
比如我们的装备有些属性需要根据各种基础属性根据一定的数学模型
来算出,中间还有随机概率,
这种用mysql存储过程写就比较难写,
直接用游戏代码来转就更加容易。所以我们制定的原则就是:
尽量用mysql存储过程来写转档脚本,
mysql脚本很难实现的才用游戏代码来转;
3. 要想办法提高转档的速度,减少转档的时间,
这样就能减少停服维护的时间,给玩家更好的体验。
外网经过一段时间的运营后,玩家的数据就会越来越多,
经统计数据最多的几个表是:物品表、角色表和武将表,
数据量大的话转档时间就长。提高转档速度的方法是并行处理,
具体为:(1) 水平拆分数据库表,就是把数据库表按记录数拆分成多个子表,
这样可以在多台机器上同时处理这些子表;(2) 装备是用erlang程序来转的,可以开多个进程,
每个进程各转换一部分玩家的装备数据,这样多进程可以并行处理,
这样如果转档的消耗主要是在计算上的话,通过打开SMP,
可以在多个核上并行的进行转档处理。我们做了测试对比,
如果开2个进程,装备属性转档总共需要20几分钟,
将近半个小时;如果开50个进程,转档时间就减少到4分多钟,
效率提高了6倍;
4. 转档前要备份数据库,这个很重要!有了数据库备份,
即使转档出现问题,用备份重导下数据库就恢复了。
如果没备份遇到这种情况就欲哭无泪了 :-)
5. 转档完成后要有机制来验证转档数据的正确性,
几十万上百万的数据,不可能一一通过进游戏测试验证,
QC测试也只能随机选一些玩家帐号进游戏测试,
但这种测试方法不能确保所有玩家的数据都正确转档了,
比如有可能会漏掉一部分玩家的转档。
所以我们需要想出一种自动化验证转档数据正确性的方法,
我们的方案是写脚本通过不同的途径来获取数据,
和转档的实现方案进行匹配,如果完全匹配,
说明转档出来的数据是正确的。
比如装备转档其中有一项是将旧的类型ID转换成新的类型ID,
那我们转完档后,
可以通过查找数据库中还有没有旧类型ID的装备,
来确认是否所有装备都已转换;
6. 转档时mysql要大批量的读取和写入数据,
会产生碎片和内存占用的增大,这样会影响mysql的性能,
所以转完档后要对mysql进行整理,让它恢复到最佳状态。