年后一直在做手游服务器开发，之前做了一个系统，新加了一个数据库表，但是忘记修改合服工具了，合服的时候该表漏合，导致运维部门的同时忙活了大半夜。第二天早上我8点到公司的时候(离公司近，每天7点起床)，发现运维部的同事已经到了，之前我每天早上到公司的时候，除了内务部的阿姨，就是客服部的小伙伴们，所以，我也惊呆了。聊着聊着发现运维部的同事晚上通宵了，根本没有回家，然后又得知是合服工具漏合了一个表，但是这个表是我加的。唉，我赶紧连说了几声抱歉。所以赶紧整理下合服相关的知识。
注：本人并没有真正合过服，一下想法是自己总结的，当然也请教了老员工，如果有错误，一定要指出来，谢谢。
1、合服是个概念简单，但是操作复杂，必须十分谨慎的细致活
合服就是把两个或者多个数据库的数据合在一起，从而使多个游戏服组成一个游戏服，之前的多个游戏服中的玩家能够在同一个游戏世界中玩耍，提高游戏内人气。但是每个服的数据库中都存储这大量的表，大量的数据，表与表的结构未必完全一致，游戏持久化的对象ID冲突等都导致了合服是一个让人心惊胆颤的事情。所以在网上能够搜索到很多“合服后,站立下降了，物品丢失了，元宝变少了等各种奇葩的问题”。
但是庆幸的是，基本上都是相同版本的服务器之间才会合服，如果A服现在是1.1的版本，B服现在是2.2的版本，C服现在是3.0的版本，那么就没有需求把A,B,C三个服合起来，如果强行把ABC三个不同版本的服合起来，不是运维傻，就是老板傻。所以相同版本服务器的数据库结构差异基本上都比较小。
2、合服时，要清掉一些不必要合的数据
现在大部分的手游每个服火爆的时间不过数日，这就导致了每个服里面存在这大量的垃圾号，例如等级很低，登陆时间很短，已经N久没登陆，没充过值等，合服前要把这些数据清掉，既加快合服速度，也减少了合服后的僵尸号。
另外还有数据库可能会存储一些配置项，例如我们就专门建了一个config表，存储各种逻辑无关的配置，这些数据就没有必要合了。
3、生成持久化对象ID的时候，一定要主要不要冲突
如果A服玩家ID从1开始分配，B服玩家ID也从1开始分配，那么合服的时候就等着哭吧，不是随随便便修改A的玩家ID就行的，因为这个ID也可能会在别的表里面存储。
举个例子：
t_faction：存储有玩家ID
t_friend：存储有玩家ID
t_mail: 存储有玩家ID
XXXXX，基本上持久化的ID都有可能在别的表里面存储。
所以每个持久化对象的ID尽量不要使用自增列，如果使用自增列也一定要每个服制定一个独一无二的区间。
我们现在的服务器定死每个服上限注册角色是20万个，超过就不让再注册了。所以就可能给每个服指定一个ID区间，这样合服的时候就不会冲突。
但是我觉得最好的办法是顶一个一个GUID生成规则：
64bit GUID = 32bit时间戳 + 14bit区号 + 6bit类型号 + 12bit自增号
32bit时间戳：这个不解释
14bit区号：一共可以表示16384的区，一个游戏如果能开这么多个区，那就在梦里笑醒吧。
6bit类型号：可以表示64种类型，Player/Npc/Monster/掉落物/子弹等，足够用了
12bit自增号：表示一个时间戳内能够生成的ID个数，2^12 = 4096，如果一秒内生成4096个ID还不够用，那你也等着在梦里笑醒吧。
按照这种生成规则，合服的时候，任何的持久化对象id都不会重复。但是有个缺点是，拿到一个ID，一眼看不出来这个ID表示一个玩家，还是一个npc，或是一个monster？
4、合服工具一定要有服务器开发人员维护
服务器开发人员最整个游戏系统最熟悉，最了解数据库的信息。并且要做好合服工具，把合服中遇到的警告，错误要及时反馈给运维人员。
5、服务器开发人员改动数据库的时候，一定要考虑到合服
首先应该确保自己对数据库的修改能够合服，其次一定不要忘记修改合服工具，之前正是因为我的疏忽，才导致了运维同事的通宵。