一、目标
能横向扩展，架构要简单，能做到负载均衡，避免单节点负载太轻的资源浪费。
二、数据存储的DB集群
数据存储类型有多种。
（一）非交互性的个人数据
可通过简单的id分段。id为1~10000的玩家个人数据存储在db1，id为10001~20000的玩家个人数据存储在db2，以此类推。
（二）交互性数据
如好友关系等。
（1）如果好友关系可以为单向，那么可以将关系存到个人数据里。
（2）如果好友关系不能为单向，那么需要保证每条关系保持在要么没有，要么两人都认同，记数据上一直，互相有关系。那么需要保证相关的关系操作的一致性。这样可能只保存一份每两个人之间的关系，k-v存储时需要方向查找，不知是否能实现。
（三）全局数据
如全局排行榜之类的。这种放在单独的库里里，专门做全局数据的存储。当到一定规模时，按全局数据的类型再分库。
家族、帮会等，也放单独的库里。如果需要扩展，再按家族id、帮会id来分库。
三、逻辑服务器集群对DB集群的访问
DB集群的路由规则配置到逻辑服务器的config里。当需要热扩展DB时，启动新DB后，给各logic服务器发送GM指定，reload路由规则的config。
DB集群路由规则的config，可以放在一个公共地方，各logic服务器接到GM指令后，去公共地方拉取新的config然会reload。
四、逻辑服务器集群
为了架构的简单，可以每个逻辑服务器进程上都有所有逻辑，扩展时，以扩展逻辑服务器进程数量来达到。
（一）各逻辑服务器上玩家分配
逻辑服务器集群之间的交互。如果逻辑服务器的使用，也像个人数据存储的DB那样id分段——只让1~10000的玩家登陆logic1，10001~20000的玩家登陆logic2时，这很简单，但各id断的玩家活跃度不定的，做不到负载均衡啊。
所以是根据当时的负载情况，来推荐玩家登陆闲的逻辑服务器的。这样需要有个全局映射，知道哪个玩家登陆在哪个服务器上。可以将玩家当前所在的服务器id记录在该玩家的个人数据所在的db里。
（二）逻辑服务器间的通信
目前项目持久化使用redis，最快出东西，就先考虑redis的优势。
逻辑服务器间的通信，通过全局数据存储的redis来做pub/sub转发吧。
redis的pub和sub的实时性不够时，将有实时性需求的玩家都转到一个专门做强实时性的特殊逻辑服务器。
五、PS
公司的项目是Node.js+Redis，业余时间打算用Go写个服务器引擎。
这篇考虑发到精华区，可以得到很多的批评建议。