首页滚动字
http://dev.mysql.com/doc/refman/5.1/zh/optimization.html#design-limitations
http://www.tudou.com/playlist/id16545861.html
公司的名字叫 東海旅行,用绿色的字体
電話:81662673008 FAX:81662673009
网页游戏 合服技术分享
我们的游戏上个星期经历了第一个数据合服。简单说,就是把2个数据库合并在一个数据库,让2个服务器的玩家一起玩。
过程简直是惊心动魄,最终还是安全完成任务。
本文就分享下合服的各种技术细节。
需求说明:
--------------------------
要把2个服务器玩家合并,首先外部对玩家而言是不变的,包括了登陆游戏的URL,游戏中的角色等;但是物理上,确是一台服务器一个数据库。
简单的说,一服的玩家用一服入口登陆,玩一服账号;二服的玩家用二服入口登陆,玩二服账号;
即使我只有1个账号,但是不同入口登陆,依然能使用不同游戏账号进行游戏。
数据库设计
--------------------------
要实现合服,首先表主键必须全部使用代码生成,并用服务器编码作为前缀。
例如我的一服表主键就是 001GMxxxxxxxxxxxxxxxx。 二服就是002GMxxxxxxxxxxxxxxxx。这样合服的时候,就不需要对数据进行预处理了。直接导入。
其次,使用平台用户使用一个账号,登陆不同服,要获得不同账号,因此在游戏的玩家表,要通过服务器编码进行区分,例如:
Usr_Profile
:usercode 主键
:username 平台账号
:servercode 服务器编码
这样,根据传入的username+servercode就知道应该获取什么服务器账号了。
游戏中,玩家通过昵称识别对方,因此合服的时候,必须对昵称进行修正,防止重复,因此所有昵称都要添加后缀。我们最终方案就是添加 .x服 这个后缀。
有了这3方面保证,合服就变得简单了。(简单个屁。。。)
合服流程
--------------------------------
1. 数据库分析准备
做事前都要先准备。因此首先要对数据库表结构进行分析,判断什么表结构需要合服,什么可以忽略。
我们游戏有60多张表,其中仅仅27张表需要合并,其他的都是配置表、日志表,都不需要合并。
2. 数据备份
这部不用说了,首先要对数据库全备份,防止操作失误,导致数据丢失了。一般就在本机MySQL新建一个backup数据库, 然后使用bult insert进行复制,速度很快。当然,备份的时候,对于体积很大的日志表,可以跳过了。
3. 数据删减
这部分很重要,一个网页游戏有接近80%的账号是死号,因此合服的时候必须先过滤掉死号。规则如下:等级小于10级、没有充值、最近登录时间大于30天的,全部清除。
然后,就是上文提到的27张表中,与被淘汰账号相关的数据,也清除。
这个清除量实际上非常大的,我有张数据表接近30W数据,结果一清就清了20W,超级舒服。
4. 数据检测
这部分也很重要,因为我们第二个服务器当时配置错了,没有使用服务器编码作为主键,导致与一服数据存在冲突的可能,因此需要对27张表的主键进行检测,判断前缀是否002,如果不是,就要进行手动修正了。
5. 数据修正
这块主要针对存在主键冲突的数据进行修正,一般用SQL即可,大概耗时30~60分钟,我就用个SQL,例如 update xxx set pk = concat('001',substring(pk,4)),进行数据修复。
当然,修复前,需要对表结构进行分析,不能出现遗漏,特别是外键关联。
6. 数据导出
不要尝试使用代码等方式进行合服,速度太慢了。我使用SQLYog,对所有表进行导出,其中插入配置为Bult Insert,导入速度非常快。
7. 数据导入测试
最终导入的时候,要测试,看看导出的SQL是否存在问题。
8. 导入。
这部完成,合服成功了。
貌似非常简单的步骤,实际上却问题多多。接下来我将说明实际部署中存在的陷阱。
合服 生存大考验
------------------------------
1. 合服的表结构不匹配
当时我合服的时候,发现表总是导不进去,提示主键重复。不可能的啊。。从一个不重复主键的表导入会提示重复?
检查了很久发现,服1的主键是21位,服2的主键是22位,结果导入的时候22位的主键自动省略了最后一位,自然会产生了主键重复。。。
2. SQLYog该死的bug
SQLYog改表结构竟然和实际表结构不对应。我明明修改了char(100),可是数据库一看,还是char(21). 最终只好用命令行修改。。
嗨。关键时候,这些工具总是找麻烦。
3. SQLYog导入出错竟然没有提示
也是该死的工具问题,最后我使用navicat配合SQLYog进行操作。
4. 部分动态生成的数据,无法批量导入
例如竞技场排名,不允许出现相同排名。所以这块数据需要在玩家登陆的时候自动生成。此类型数据都是动态生成的,无法通过批量修正,都需要通过游戏逻辑进行补全。
因此,合服的时候,这块数据将不参与合并。
合服历险记
------------------------------
说了这么多理论知识,接下来就说说那天我合服的经过。本来在测试机上一切顺利的,不到2个小时就合并了。可是真正操作起来, 却用了8个小时。。。。
开始还顺利,3个多小时就做好了数据备份、删除、修正。可是导入的时候发现总是提示主键冲突,于是不断找原因,1个小时过去,才发现原来表结构不匹配。晕死。
接下来导完数据,4个小时过去了,开服。一运行,玩家就投诉了,说中文乱码、丢失装备、丢失武将。
丢失装备、武将问题,我又花了1个小时检查,原来是潜在部分主键仍然丢失最后1位,导致找不到。这个时候,我不能停机,因此我对比2个数据库有差异的表,生成一堆update的SQL,然后手动操作。可是发现SQL多了,SQLYog会卡死,游戏也会卡死。我只好开了10多个SQLYog,采用并行方法,把SQL拆分成50一组,进行手动操作。。累死了。
对于武将名字乱码,是当时生成SQL文件的时候,编码格式错误了。可是武将数据接近有3W条,不可能进行手动更新了,因此我写了个更新程序,进行后台更新。这块就花了1小时。
终于游戏Exception少了,本来可以歇口气了,结果运营说,玩家充值失败!我检查代码,原来充值接口没有使用servercode去区分玩家账号,又是疏忽。
第二天,运营又投诉说,商会采集资源失败,回去检查,才发现原来漏了对账号中商会主键进行修正,又是疏忽。
小结
----------------------------
本来已经提前预演了2天,没有问题,可是上到战场还是错漏百出。
如果准备过于详细,会导致发展缓慢。如果准备不充分,又会很多问题。这个是个进退两难的情况。最终,我偏向了迅速准备,快速修正的方案。
毕竟,预演的时候找不到的问题,给再多的时间也不一定找到。还不如直接上战场,随机应变。
使用cocos2d-x引擎的优势在于便于移植性。其开发出的C++代码只要在各平台上只要稍加改动就可以使用。而单使用ECLIPSE或Xcode环境使用的语言分别是java和Object-c,如果直接让它们相互转换难度肯定要大的多。用win32平台做cocos2d-x开发的话就用vs,用IOS的话就用xcode,因为它们都是在对应平台上的开发工具。但它们开发出来的C++代码都可以通用,但也有个别c++函数库不一样,但不影响移植性。如果你做Android开发的话,就用win32平台和vs就可以了,如果是IOS就用xcode,编出来的代码如果要移植只要把class里的代码拷贝过去重新编译就可以了
什么时候使用 Xcode, 什么时候使用Eclipse?
现在,你有两个项目了,那么问题马上就出来了,我们到底什么时候该使用哪一个呢?
使用cocos2d-x通常的开发策略是,首先在ios上面通过xcode来测试,确认没问题后,再通过eclipse来测试。只需要在心里记住下面几点就行:
1. 经常测试.开发完一个小功能之后,就应该在andriod上面测试看行不行。这样的话,就不至于遇到问题找不到了。
2. 在多个设备上面测试: 现在市场上面有大量的android设备,而且它们的差别很细微,所以,你要尽可能多地测试多种不同型号的设备。
当然,你也可以先在andriod上面测试,然后再在ios上面测试。但是这样肯定会降低你的生产率。因为xcode比eclipse反应速度更快,而ios模拟器比android的模拟器的启动速度也要快一些。