合服导致 globalserver 起不来的问题

globalserver 报错 RMIInitArmyBackObject InitError

根据报错信息一路追查下来，发现某个帮派的数据解析 json 的时候报错。监视变量，找出这段字符串，大致结构如下：

{
"army_name":"\u98ce\u4e91\u805a\u53d8",
"army_level":1,
"notice":"\u6b22\u8fce\u5404\u4f4d\u52a0\u5165\uff0c\u07d8\u01b0\u07d8\u01b0\u07d8\u0180\[email protected]"
}

继续跟踪 json_c_0.9 的代码，解析到 \f 的时候出错。

估计是后台那边合服处理数据库的代码有问题

时间： 2024-11-08 08:27:02

合服导致 globalserver 起不来的问题的相关文章

游戏服务器合服相关

年后一直在做手游服务器开发,之前做了一个系统,新加了一个数据库表,但是忘记修改合服工具了,合服的时候该表漏合,导致运维部门的同时忙活了大半夜.第二天早上我8点到公司的时候(离公司近,每天7点起床),发现运维部的同事已经到了,之前我每天早上到公司的时候,除了内务部的阿姨,就是客服部的小伙伴们,所以,我也惊呆了.聊着聊着发现运维部的同事晚上通宵了,根本没有回家,然后又得知是合服工具漏合了一个表,但是这个表是我加的.唉,我赶紧连说了几声抱歉.所以赶紧整理下合服相关的知识. 注:本人并没有真正合过服,一

合服日志 2015-11-25

电信一服合并至双线二服,改名为碧水云天 合服时间:7:00~9:30 合服工具新加功能: 查看两个服务器中被领取的冲级经验奖励数量,同样50级奖励,哪边被领取的多以哪边数量为主记录. 涉及到的表:tbl_JoyDock, tbl_JoyDock_rbhlv_limit_blimit. 出现问题: 1. 测试发现合服后,角色在不同账号下. 出现原因:测试方法的问题,所有Account的dbid都是运维服务器发过来的.即使合并服务器Account.dbid也不会出现重复的可能.18测试服务器是未开启

合服日志 2016-1-27

双线一区合并至双线二区 合服工具新加功能: 合并商城购买上限(哪个服务器购买上限高以哪边为主) 修改tbl_JoyDock_jmallbuylimit_buylimit 出现问题: 合服结束后,国家结盟状态未清除.原因是之前增加的表tbl_ClanDock_allyCampsB未处理.而handle_clan.py是将tbl_ClanDock表分开处理的.未特殊处理的表格就被合并了. 数据信息(截止到2016-1-11): 双线一服: 2016-1-11当日登陆账号数量:5332 总角色数量:1

合服测试（二）

很久没在这里写了,把其他地方自己写的也进行了搬家. 这里主要还是介绍业务层的,进行这些测试后就简化的完成本次的合服测试. 合服 测试情况 xxx内网测试数据清除 pass xxxx合区后测试(随机区间服务器配置账号登陆和平台发邮件代替充值) 进行中 xxxx二次合区接口测试 pass xxxx合区后测试(每个合服区间的服务器配置账号登陆和平台发邮件代替充值)进行中 平台迁移测试 计划 阶段一:新平台的测试(注册,登陆注销,跳转用户中心,充值)pass 迁移后 未开始 --基于渠道(A) xxxx

合服技术总结

--蔡剑彬 C++服务器开发工程师 ([email protected]) 合服技术的核心,就是将几个服的数据库合并,是十分简单的.但具体要注意的细节也是很重要的,比如如何从两个服务器入口进入到同个服务器?如何区分同一账号在两个服创建的角色?下面就按照玩游戏的流程来解决这些问题. 首先打开客户端时,有选服的功能,这个其实是让客户端选择要连接的服务器的IP地址和端口号.点击"进入游戏"时,就会通过socket连接,建立客户端和服务器的连接,此时服务器和客户端便可以通信了.基于这个原理,在

合服测试（一）

1)提前在内网进行一些业务的预演,比如等级or积分排行榜信息,pvp数据,pve关卡排名等.<--根据游戏业务来 2)在内网里建立起码2个库,执行脚本合并. 3)预演一场断开,脚本失败后,再次执行是否数据出现异常. 4)提前准备好外网所需要用到的区服账号,记录roleid,区服信息,渠道账号.密码. 字段名都被引用,需要根据实际 1)归集合并的游戏库到同一个mysql服务器, 以下假设是1,2,3三个区合并, 数据库名字分别是gm1,gm2,gm3. 2)建立和现有游戏库相同结构的空库,空表.

mysql合服 更新相同的用户名前追加服务器编号

表结构: 1 CREATE TABLE IF NOT EXISTS `user` ( 2 `user_id` int(11) NOT NULL COMMENT '主键', 3 `user_level` int(11) NOT NULL DEFAULT 0 COMMENT '等级', 4 `user_name` varchar(32) NOT NULL DEFAULT 0 COMMENT '名称', 5 `server_id` int(11) NOT NULL DEFAULT 0 COMMIT '

[游戏]服务端的逻辑分服与物理分服

背景 工作室也经历过好几个游戏了.服务端的架构跟实际业务需求出现过不少的冲突.导致后来花了挺多时间去擦屁股的.以最近的一个游戏举例,原本的世界观设想是一个大服的世界观.也就是只有一个服,撑下百万用户,数万同时在线的设计.而后随着业务变化和线上表现,原本大服的设计并不能满足,最终变成了滚服玩法.由于大服变滚服,在原来的服务器架构约束下,对于后续增加的跨服玩法和合服实现都带来了比较大的麻烦和不少的工作量. 物理分服 原来的架构是按照大服设计的,所以在数据库上面的设计一个服对应一个数据库.假设我们滚了

redis合库

玩家数据全部保存在redis,对合服来绝对是个坑.因为一直都是做开发,合库这事还是第一次操作. 首先,合服要做哪些事情,当然不同的游戏肯定不一样.合服的目的是为了增加同个服务器上活跃玩家的数量.合服有另外一种叫法数据互通,按这种理解就是要合并的那几个服务器,玩家可以进行交互,主要指排行榜数据和一下全服玩法.数据互通很明显前端的入口是不变的.有一个问题就是要合并的服务器,同个玩家不同角色的数据是否要删除.这次合并是按照不删除的做法进行的.这个根据不同的游戏采取不同的策略. 其次,数据合并.这次比较