MMO的架构设计

MMO = Massively Multiplayer Online Games

    • –  几乎所有玩家在所有时候都在与服务器、与其他玩家交互,并行非常高;
    • –  设计MMO系统架构的首要需求:必须具备伸缩性,以满足大量的玩家,且 玩家的性能体验(流畅性)不能降低。

 

关于MMO的几个特征:

  • –  针对伸缩性而设计的架构,通常使用多台server构成集群,通过并发完成大
       量请求;当玩家数量增加时,通过扩展集群的规模来保证性能;
    
  • –  超胖的客户端+相对很瘦的服务器:与传统web应用相反(瘦客户端+胖服务器);
  • –  客户端任务只访问服务器上的少量状态数据,但其中50%被改写:与传统web应用相反(90%的数据访问是只读的,只改写少量数据);
  • –  当客户端性能和吞吐量之间产生矛盾时,应尽可能减少延迟,哪怕以牺牲吞 吐量为代价。

基于分层、缓存、异步、分布式/并发四种架构设计思想,分析MMO的架构设计所面临的设计决策:

  • 为提高伸缩性而设计的集群会是什么样子?集群内各服务器按何种标准进行 分工?
  • 客户端与服务器之间:事件驱动方式(异步请求) vs 调用返回方式(同步请求)? – 客户端与服务器形成C/S结构,它们如何划分功能?
  • 游戏相关的数据分为几类?它们各自会存储在客户端还是服务端?

架构猜测

同时负载均衡服务器具有集群伸缩的功能.

同步与异步

使用消息队列的异步请求.MMO显然是高并发的情况.

数据存储和功能划分

MMO和虚拟世界的环境始于一个非常胖的客户端:它通常是顶级的PC、具有最强劲的CPU、很大的内存,以及本身计算能力就很强的显卡。它也可以是一台游戏机,专门为图形密集的、高度交互的任务而设计。只要有可能,数据就会存放在这些客户端,特别是那些不会改变的信息,如地理信息、材质贴图和规则集。服务器保持尽可能的简单,通常只保存非常抽象的世界表示和其世界中的实体的表示。而且,服务器的设计目标是尽可能少地进行计算。绝大部分的计算留给了客户端。服务器的真正工作是保存共享的世界真实状态,确保不同客户端对世界的看法差异可以根据需要得到纠正。真实状态需要由服务器来保存,因为控制客户端的玩家很有兴趣让他们的表现变成最强,所以可能会受到诱惑,根据他们的喜好修改共享的真实(如果他们可以)。在一般情况下,如果有可能,玩家就会作弊,所以服务器必须是共享真实的最终来源。