一个不分服的游戏服务器设计问题？

一个不分服的游戏服务器设计问题？
最近自己想设计一个游戏，类似coc或者海盗骑兵，玩家不用选择服务器。
游戏主要需求：
整个游戏世界有很多村落组成，村落里是若干玩家(比如上线10人)组成，若干村落组成国家。
战斗包括整个村落和村落打，及玩家和玩家打，还有玩家和系统设定的npc打，玩家之间可以相互组队去打副本。
所有玩家之间都可以加好友，聊天，组队聊天，世界聊天等。
游戏中没有场景的概念，不是mmorpg。
玩家之间的战斗可以在双方同时在线下进行，不像海盗骑兵只能打离线玩家。

由于玩家可能比较多，单服的架构不合适，要做到较强的扩展(不需要理论上的无限扩展)。设计上玩家上线是1000万，同时在线是10w。
语言可以先不考虑(本人熟悉java，nodejs以及lua也可以考虑)


其实没有你想的那么难，现在日本的大多数手游都不分服了（对玩家而言），国内迟早也是这个趋势。因为手游的用户行为不适合做强在线交互，所以不分服在玩法设计上能提供很大的空间。

那么具体怎么做？具体的你得自己去研究。我说一个大致的思路。

实现上其实是分布式的服务器，不分布计算的话就谈不上可扩展性了。当然结构搭好了，要不要扩展完全可以根据产品的实际运营情况来定
那么既然游戏服务器是分布式的话，怎么让玩家感觉不分服呢？很简单，入口是唯一的就可以了。这个唯一的意思可以是唯一的登录服务器，也可以是唯一的游戏服务器连接机制。
那么既然玩家散落在各个游戏服务器里面，怎么能够让他们象在一个世界里那样产生交互呢？这个是实现里面比较难的地方。在规模有限的情况下，只要保持有一个高效的数据持久层通信机制（在小规模下 redis 就够了）就可以解决90% 的问题。当规模上去了以后，可以考虑 阿里云 或者 腾讯云提供的服务。


需求层面先要确定的一个事情，
是否需要显示地图版面资源占用情况，这个涉及到全局数据，如果存在，对于版面的信息更新频度问题，如果说存在，那么显然一个全局服务器可能不太好适应，如果没有，一切都好解决。
1.设计是否靠谱，需要测试你的各类服务器对于承载是否能够达到预期。全局服务器不可忽视的一个问题就是广播消息，拿你的聊天服来说，如果说，全服共用一个聊天服，考虑下在用户同时在线峰值时消息转发会带来多大的压力，虽然消息转发的逻辑处理简单，承载也高，但是更多是些无意义的需求，所以还是基于有效需求做一些划分，比如以国家为基础单位加载至聊天服，保证国家内成员处于同一聊天服。
2.当你的所有服务器组都处于内网之中时，服务器组的通信的效率基本上不需要担心。
3. 建议还是添加网关服，用于管理客户端连接，而你的游戏服，可以看做是业务逻辑计算结点，世界服就是一个中心服务器，管理一些状态，不做过多的逻辑计算。至于玩家对网关的选择，先让玩家请求网关负载均衡服（可以是一个web页面），然后告之玩家可连接的网关，至于分配方式粗略的可以直接基于网关的承载（如果你的业务逻辑计算结点所有数据都是从数据中心拉取）。通信消耗，游戏的类型及需求决定了游戏不是需要高响应的，同时手游通信环境的影响，这点内网通信消耗我觉得还是能够容忍的。
4.同3所说，世界服不做过多的逻辑，减少单点故障可能性，国家之类的，根据具体情况分析了，尽量是放在逻辑计算结点上来进行。始终会存在不可抗因素，所以单点故障的可能性始终存在，如果真的需要，那么粗略的考虑就是做主从，主服务器挂了，立马转接到从服务器。
5.基本上是这样，已修改数据定时回写。玩家离线不清除，主要解决在大量玩家重复上下线操作的问题。
6.资源争夺这里麻烦最多，最好的办法是任何会改变共享资源的操作都为同步操作，这样保证数据不会出现问题，我记得COC里面好像是不能攻击在线玩家，这样就从根源上解决了问题，如果需求执意要对在线玩家也可做操作，那么只好把操作理清楚了根据情况做限制。

=================================================================


可以统一出口网关，用LVS做TCP端口均衡负载，这样可以扩展足够多的接口服务器去满足在线人数需求。（技术人员少的话可以直接用青云、阿里云的均衡负载服务）

一些热数据或者经常更改的数据，例如你说的“我战胜了玩家A，我会抢他资源”：全部写入redis集群，定期将redis数据同步到数据库中。为了避免单点可以在架构和后台服务编写上“标记服务某个用户的reds服务器”并记录到数据库中，并且做到可用脚本热切换。