在Facebook应用程序和云计算时代,我正在重新思考大型多人游戏.
假设我要在现有的开放协议之上构建一些东西,我想为1,000,000个并发播放器提供服务,只是为了解决问题.
假设每个玩家都有一个传入的消息队列(用于聊天和诸如此类),平均有一个传入的消息队列(公会,区域,实例,拍卖......),因此我们有2,000,000个队列.玩家将一次收听1-10个队列.每个队列平均每秒可能有1条消息,但某些队列将具有更高的速率和更多的侦听器(例如,级别实例的"实体位置"队列).假设系统排队延迟不超过100毫秒,这对于温和的动作导向游戏来说是可以的(但不是像Quake或Unreal Tournament这样的游戏).
从其他系统,我知道在单个1U或刀片盒上为10,000个用户提供服务是一个合理的期望(假设没有其他任何昂贵的东西,比如物理模拟或诸如此类的东西).
因此,使用交叉开关集群系统,客户端连接到连接网关,然后连接到消息队列服务器,我们每个网关有100个用户,有100个网关机器,每个队列服务器有100个消息队列,有100个队列机器.再次,仅适用于一般范围.每台MQ机器上的连接数量很小:大约100,与每个网关通信.网关上的连接数量会更高:客户端为10,100,连接所有队列服务器.(除此之外,为游戏世界模拟服务器添加一些连接或诸如此类的东西,但我现在试图将它保持分离)
如果我不想从头开始构建这个,我必须使用一些存在的消息传递和/或排队基础结构.我能找到的两个开放协议是AMQP和XMPP.XMPP的预期用途更像是这个游戏系统所需要的,但开销非常明显(XML,加上冗长的状态数据,以及必须在顶部构建的各种其他通道).AMQP的实际数据模型更接近我上面描述的内容,但所有用户似乎都是大型企业级公司,工作负载似乎与工作流程相关,而不是与实时游戏更新相关.
有没有人可以分享这些技术或其实现的日常经验？