告别合服的苦恼

当我还没有游戏开发运营经验时，我领着一班和我一样无甚经验的兄弟们写下最初的游戏程序代码。

出来混，总是要还的。当合服近在眼前时，我发现时间全部花费在了开发和debug上，对合服没有任何思想准备，更谈不上什么工具。让我感到麻烦的是我们的数据库和游戏世界一样是独立的，一服一世界，一服一DB。代表玩家的数据在每个数据库里都是从0依次增长的。这就意味着多组服务器合并，就要把多个数据库里的数据也合并在一起，不能丢失，并重建id和索引。

这不是大问题，问题在于要用短时间完成这个合服的运维任务，尤其是当一次要合并多个服务器时。很多事情都不是问题，那是没有时间的约束。

我不断优化合服工具，但是数据合并注定了有些耗时耗空间操作不能忽略。

能不能将所有服务器的数据全局化？

所有应用服务共用一张数据表。理论上是可行的，但是，这个数据库服务器需要什么样的配置呢？一贯花小钱办大事的资方能同意吗？如果不能在一个空间存储不同应用服务器的数据，那么换个思路，我们的id分配能不能全局化呢？

建立一个分配服务，为不同的应用服务提供一定量的id，应用服务在自己进程内分配这个id到不同的玩家身上。应用服务将id使用完毕再次向分配服务申请id。这样虽然没有在物理存储上全局化，但逻辑上所有玩家id都是唯一的，合服时只需要将数据导入即可，无需重新分配id。

没有一条路是平坦的，这种设计要求id分配服务不可中断，分布式的一个假设就是机器物理不可用是常态，必须保持这个服务的高可用性。

哦，这样看来合服简单了，但整体的架构设计和开发有麻烦了。

怎么选择呢？真操蛋。