一种适合竞技和MMO的无单点游戏服务端集群模式

一、众所周知，在大厅+子游戏模式中，最容易现实集群的部分，就是子游戏部分。 我们只需要在创建房间的时候使用负载均衡算法选择适合的服务器进程就行。常见的集群模式有下面两种情况 。

1、中央集群模式，消息通过中央服转发

                                    
 
中央集群式的优点就是架构简单，每个进程只需要维护与中心服的连接就行。中心服还能够实时监测各进程状态，并向所有节点广播。

中央集群式的缺点就是这个中心服单点。中心服故障，或者压力过大时，都会出现整个系统架构不稳，响应迟缓等问题。

2、进程直连式 

                                          

直连式的优缺点和中央集群式刚好相反。

直连式的优点就是每一个进程都是直接相连，不需要中间服务器转发，可以第一时间响应。并且可以承受比中央集群式量级更大的负载。

直连式的缺点是，系统需要维护NxN的内部连接。当系统进程过多时，内部连接数量庞大。稳定性会下降。并且每一个进程都要承担负载均衡策略，如果要修改负载均衡策略，则需要重启整个集群。

 

3、中心服集群的中央集群式架构

                                    
 
我们设计服务器除了考虑负载以外，更多应该以稳定性优先。因此有大量的解决方案是基于中央式集群演化而来。

常见的解决办法有以下几种

1、使用成熟的MessageQueue中间件

成熟的MessageQueue中间件的吞吐量一般都比普通进程高，能够胜任一定的量级。

但此类中间件针对的是通用性问题解决方案。且消息调度机制复杂。很容易因为配置不当出现瓶颈。

2、根据业务划分中心服。

并不是所有业务都需要连接到同一个中心服，有一些业务之间是完全不会来往的。此时可以新开一个中心服，用于收集此类业务请求。

网关服再和这类中心服连接就可以了。 

3、中心服多进程

中心服多进程机制可以在一定程度上解决此问题。唯一要确保的就是A到B的消息，先发的先到，后发的后到。为了保证这个情况，我们只需要确保，A发消息的中心服唯一即可。这个问题，我尝试着解释一下，这也是许多消息中间件需要解决的核心问题。

假如A要发三个消息（设为M1,M2,M3）给B。而我们有C1,C2,C3 3个中心服。

如果不做处理，采用随机分配，则可能出现如下情况 。

A -> M1 -> C1 -> B

A-> M2 -> C2 -> B

A-> M3 -> C3 ->B

这样导致的结果就是，如果C1，或者C2因为要处理其它服务器的消息，导致M1,M2派发晚于C3派发的M3的话。那么消息到达进程B的顺序就未知了。 M3,M2,M1,M2,M3,M1等都有可能。 这在系统中是不允许的。

为了解决这个问题，我们简单地进行一个约束。

任何服务器进程只会选择一个中心服进行消息派发。

比如我们有A1,A2,A3,A4,A5 5个进程， 有C1,C2,C3 3个中心服。

那么我们可以简单地使用 进程ID % 3 来进行负载。或者启动时，随机选择一个中心服。并且在之后的运行中保持不变即可。

幼麟游戏服务端5.0架构，一开始是方案二，直连式。 目前已升级为方案三， 即中心服集群的中央集群式。

此方案可以使用任何语言轻松实现。并且，此方案不仅适合大厅+子游戏等房间类玩法，也适合下面这种传奇类MMO。

                          

                    
 

 转自https://qilinzi.blog.csdn.net/article/details/104610031