1. 首页
  2. >
  3. 架构设计

百万用户在线的角色服承载能力分析

一、用户基数的预设

假设整套游戏服务端的架构设计以100万用户在线进行游戏为准,日活(用户每日活跃数量)就是要1000万以上,总的用户量都得1亿左右(呵呵,是不是很夸张,极少公司能做到)。

下面各种进程类型,从CPU、内存和网络三个方面进行分析,如何进行架构设计来承载 【百万用户在线】,【千万日活用户】,【亿级用户量】。


百万用户在线的角色服承载能力分析

二、角色服承载分析

首先,要说明一下,按照分区分服的运营策略,在线人数不可能一下子堆积在少数角色服上。运营的导量策略上,应该保证单角色服的在线用户数不超过1万,当100万用户在线时,至少已经开了100个服。

然后,我们的承载能力分析主要从 CPU,内存和网络三个方面切入,假如这是组成木桶的三块木板,最短的一块就是承载能力的极限。


3.1 CPU

现在的服务器16核,32核,甚至64核的机器到处都是,如果一个进程能充分发挥多核的优势的话,一般来说CPU是不成问题。以 Actor模式为例,假如是一台 16核的机器,可以在一个进程内,分配 15个 RoleActor 来负责不同角色逻辑的处理,每个 RoleActor 运行在不同的CPU核上,如此一来,CPU就能被充分利用。按照以往的经验,只是处理角色自身的逻辑玩法,并且能把压力分摊到不同的 CPU核上进行运算,CPU的压力不成问题。然后就考虑内存和网络长连接的处理能力吧。


3.2 网络

网络TCP长连接方面,按照现代的IO多路复用的模型,C10K问题已经不是什么问题,但是更多就不好说,毕竟网络模块还需要定时维护心跳,数据加密解密等。所以稳妥起见,假设一个进程最多能支撑1万人同时在线,那么说全服100万在线的话(100万个网络长连接),就至少需要100个角色进程,这是一个保底。


3.3 内存

然后内存方面,按照以往的经验,没怎么做优化的话,一个角色内存数据占用3MB是有可能的,就假设一个角色在内存中占用的数据为5MB。100万在线的话,就是 100万 x 5MB = 5000000MB,这就接近 5000GB。这么一算就很清楚了,一个进程50GB那简直就是灾难,运维大佬得敲死你。所以还是10GB是比较合理的,也就是说至少需要500个角色进程来承载。

其实,上面的内存分析还是有问题,只是100万在线的角色数据在内存,没在线的呢?或者刚刚下线不久的呢?很明显,一般都会做游戏数据的缓存,为了避免数据频繁的加载和销毁,都需要设定一个角色下线后的数据缓存时间,具体缓存时间的多少,一般是根据游戏类型来衡量(是否会频繁上下线)。缓存时间可以是半小时,1小时,3小时,6小时,一般来说 1小时就足够了。以日活 1000万来分析,1小时内下线的用户数为,1000万 / 24小时 = 42万人,算它为50万,加上在线的 100万,就是150万人。这个算法是有点乐观了,因为白天的活跃肯定是比晚上的要高很多,以往的经验来看,高峰的时候缓存人数一般是在线人数的3倍。所以,100万用户在线的话,内存方面的计算得以 300万用户缓存数据为准,也就是 300万 x 5MB = 15000000MB,也就是 15000GB。每个进程 15GB的话,就需要1000个角色进程来承载 300万的用户数据缓存。


三、总结

上面的分析主要是以角色服(直接与客户端连接)为视角,以百万用户在线的压力下,网络TCP长连接要求不少于 100个角色进程,内存占用要求不少于 1000个角色进程。在这基础上划分1000个角色进程,以Actor模式来设计进程的并发处理能力,每个Actor占用的内存1GB左右,CPU一般不构成压力。

再具体一些,把服务器的机器性能配置也梳理一下:

在线1百万,日活1千万,总用户量1亿

单个角色数据内存占用 5MB(偏大)
单个角色服连接数 < 1万
缓存的角色数据量为在线数的 3倍
总连接数:100万
总缓存内存占用:15000GB
每个角色服占用:15GB
角色服的每个ActorRole占用:1GB
角色服数:1000
机器配置:CPU 16核,内存32GB,带宽(按流量算),硬盘100GB,价格 1500元/月
机器数量:1000台,每台机器部署一个进程(1000个角色服),每个进程分配 15个RoleActor,进行角色逻辑计算。
机器成本:150万元/月
支撑用户:100万在线,1000万每日活跃,1亿用户总量

流水?每个月至少都得过亿了吧……


本文的分析和估算都是偏向更大压力,实际上要达到这么苛刻的条件,非常不容易,即时达到这么苛刻的条件,承载压力也是能稳定抗住。