刺鸟原创文章,转载请注明出处 在前面的文章中,我们已经开始了不少逻辑功能的开发,在这期间也有不少可以分享的经验点,这个我们以后慢慢道来。今天,我们主要讨论下如何让服务端能进行分布式部署和工作。 一:为什么要支持分布式部署和开发 众所周知,python是单线程的语言,存在GIL锁、无法利用多核CPU等诸多限制,为了能让服务端能承载更多的用户,我们必须让程序能在逻辑上、甚至物理上分开,当用户达到一定数量的时候,我们能新开一个进程来响应请求,或多加一台服务器来处理请求。这样就能达到理论上无限扩展的可能性。 二:如何让程序能达到上述效果 我们简单分析下我们的服务端要实现的功能: 战斗服务器: 通过之前的文章可以知道,我们的战斗是类似回合制的战斗模式,每场战斗之间的数据是无关联的,仅需要处理战斗中各玩家之间的数据交互即可,这很容易可以让逻辑分开处理。 地图服务器: 每个地图之间的玩家,在大部分时间里,也是不需要交互的,因此我们可以按地图来处理逻辑,在切换地图时,若下一张地图的服务进程在其他服务器,则先将当前地图的数据保存到memcache,连接到下一个服务器的时候,在从memcache中将数据取回即可。 聊天服务器: 在不同的地图的玩家,会存在聊天的交互(比如:私聊,世界频道,公告频道等),因此所有的玩家都需要连接至一个公共的聊天服务进程,来达到数据交互的目的。 三:源代码 下面,我以战斗服务器为例来看看,首先,得有一个主调度进程,客户端在进入战斗前,先连接该进程,该进程在收到请求后,根据各战斗逻辑进程当前玩家的数量,来判定是否需要开启新的进程,并返回当前人数最少的进程的IP:PORT。 我通过以下方法来开启战斗进程:
新建一个调动服务进程,在dataReceived时处理:
在进入战斗前,连接调度进程的端口,并发送'get',调度程序会返回一个战斗进程的port,客户端连接该port,连接成功后,向调度端口发送'add|7001',战斗结束时,向调度端口发送'del|7001'(其中的7001为战斗服务器监听的端口),这样即可达到在同服务器分布的目的,实现了这一步,那跨服务器的分布也就变得很容易了。 对于地图服务器也可以采用类似的处理方法,完善以上功能后,我们的服务端就变得更加强壮了,承载人数方面可以也可以多了一个保障。 |
|