《梦幻西游》手游中如何做到200万人同时在线？

qingyou521

整理/手游，小东西很安全

随着手游越来越端到端和重度化，除了传统的留存率、ARPU等，衡量一款手游的数据还增加了PCU（Peak users，最高用户数）等数据。并发玩家）。但同时多人在线对服务器的计算能力和稳定性有很大的要求。在本次网易游戏学院，《梦幻西游》手游主播刘强就《梦幻西游》手游如何实现200万人同时在线，以及如何做到提供稳定高效的MMO手游服务器引擎。发表了讲话。

以下为演讲实录：

一、《梦幻西游》手游引擎级别：市面上唯一单服务器架构过万

刘强：大家好，我是刘强，大家也可以叫我“强宝”。有人问我为什么每个人都在谈论客户端技术而没有人谈论移动端技术。似乎是这样。第一眼看到美女梦幻手游论坛，大家都比较关注，但是服务器端同样重要。所以给大家介绍一下《梦幻西游》手游的架构是什么，我们做了哪些努力来保证架构相对稳定。

服务器架构，我们手游引擎是什么水平？我们的引擎来自玄幻游戏，单服架构2.20000左右，手游引擎稍差，1.50000。但是我们还有很大的优化空间。据我所知，市面上手游引擎不超过10000个。在手游单服务器架构中梦幻手游论坛，当然我们除外。

这是我们的服务器架构，主要分为几个部分，有，，，。首先是访问完之后，验证一些账户，然后根据验证得到一个列表，然后开始访问，和验证过的一起验证，这样可以保证我们可以无限增长。当时考虑到可能负载比较高，所以设计了这个架构。然后，顾名思义，就是被一些gm和语音使用的，因为我们提供语音聊天和语音转文字服务，这应该是社交游戏的神器，必须提供语音服务。这是一款全方位服务的游戏。

引擎线程结构，我们的引擎是多线程结构，划分线程的原因，首先模块是相对独立的，然后是划分好的。虽然我们是多线程引擎，但是开发思路是单线程开发，所以我们的开发效率并没有损失。我们大多数人都与一些 IO 和 CPU 密集型线程分开。主线程主要是游戏逻辑，也是一些基础模块。也就是我们把它分为引擎和脚本。脚本主要运行逻辑，引擎主要运行基本类似播放器。登录，以及 CPU 密集型的东西，在脚本中更合适。

二、MMO手游AOI特点：更多的瞬移，更少的NPC视觉玩法

手游和端游中的AOI有明显区别。有两种算法，一种九方算法，插入和删除节点，速度很快，属于O(1）。但是有一个很大的问题，就是当它有很多带宽网格之间移动时消耗，因为发送了很多无用的信息。交叉链表在移动时节省了带宽，但是长距离消耗了很多CPU。网易这里有实现，他们都试过了，他们熟悉他们。

MMO手游AOI有什么特点？多瞬移属于直接瞬移到地图中间，少走。客户端受硬件限制，同屏显示人数有限。和端游不同的是，你想显示多少就显示多少，所以要显示的人数需要减少，否则手机会卡住。NPC视野中的玩法很少，基​​本可以忽略。也就是说，交联列表对于NPC视野非常好。它所有的NPC都可以选择不同的视野，但是我们手游中基本不会考虑这种玩法，因为没有，所以选择了格子。

这是我们发展到中期，然后做了1万人压力测试的结果。这些都是机器人，还在里面走着。这是我们测试的第一天，没有删除文件，因为没有实现 AOI 优化。的效果图，这是一个真实的玩家，相当于一万多人，效果大概是这样的，压力测试的效果也是一样的，都是人满为患，所以整个世界都充满了各种“吐槽”，所以玩家体验很差，因为客户端卡，在手机上显示这么多角色是很差的表现。

有鉴于此，我们做了一个分层AOI的概念，不同的玩家有不同的战队信息，朋友们有一个很复杂的规则将玩家分成不同的层，当玩家数量增加时，可以动态分层，当玩家数量增加时人少，层数可以合并回来，然后人少的时候能看到几个人，人多的时候还是能看到几个人，所以不会很少。本次优化结束后，这是同一台服务器，效果大概是这样的，你在同一层看到的都是你关心的人。这种感觉很好。

三、基础模块实现：udb和AI行为树

为什么要设计一个udb，udb有统一管理，在定时保存+退出保存，经典的解决保存模式，存在性能瓶颈，当你同服务器最高在线玩家不是很高时，不会遇到这个瓶颈. 定时保存时，您希望同时保存超过 10,000 名玩家。这时候序列化会很慢，消耗CPU很多，还有停机问题。有些人已经退出了存档，但有些人正在等待时机。存盘的时候，机器Down的时候，两个人的DB是不一致的，所以操作上的问题比较多。操作对我们提出了另外一个要求，玩家数据备份是否可以随时到任意点，因为我想拿到那个点的玩家数据进行处理。我们现在为此提供了 UDB 支持。还有一个硬件条件。现在 64 位机器内存足够大，可以缓存所有登录的玩家一周。

AI 行为树，因为我们是回合制战斗，所以 AI 行为树非常适合我们。我们为什么要选择 AI 行为树。因为非数值规划也可以轻松学会写AI，说起来容易，不使用行为树很难，我们甚至可以写一些简单的AI来做文案规划。在当时的项目情况下，有端游或者竞品可供参考，策划工作略小，但程序开发量大，所以能分配到策划的都是写表格或者填写图纸被分配到规划中，这样分工合作可以提高团队整体的效率。

这是我们的一个 AI 行为树的工具图。有四到五种节点。先做什么，再做什么，是很直观的。加上这个之后，所有的AI都搞定了，所以程序基本不关心打架了。

后来，我们做了一些统计。现在我们基本上将行为树用于所有战斗。战斗力消耗的CPU中，大约有50%消耗在行为树上。目前，我们在战斗中还没有遇到瓶颈。

四、优化引擎从CPU、内存、IO和延迟启动

我们手游改造后如何提高引擎的健壮性，主要从几个方面考虑。首先是内存，你的引擎是稳定的，内存写入越界，内存泄漏一定要清除。工件、脚本虚拟机需要有统计，每个大小、数组、toble等都有总大小统计。

cpu，解决IO到CPU，基本上是一个循环优化的过程，优化CPU，下次发现卡是IO，然后优化IO，然后卡在CPU上，就是一个循环的过程. 对于我们在这方面所做的工作，我们需要在上线之前估计我们的热点在哪里。我们做出了很好的估计。首先，登录、行走、战斗。这是对可能热点的估计。5000人被逼迫，拼命做同样的事情。压力测试的效果乘以1.5到2倍。假设5000人有压力，基本上10000人问题不大。另一种是引擎和脚本分开做，找出引擎和脚本的热点，简化热点，脚本热点可以引擎化。脚本做的不多，可以考虑在虚拟机调用函数的时候做统计。这是非常准确的。当你定位到函数字段时，基本上你的热点也找到了。这是解决脚本的神器。

IO其实是个大问题。我们最好的解决方案之一就是使用多线程异步写入来解决卡的超级神器，基本上是同步读取一个IO造成的，所以我们正常的IO现在是异步的，LOG是异步写入的，数据文件是异步写入的。当需要读取数据时，函数暂停，子线程读取数据后回调函数。

这对我们来说是一个非常简单的例子。因为是异步的，所以要注意所有的条件检测。为什么要去找原来的函数，因为函数里面有一些条件检测。如果我们不直接返回原来的函数，可能会有一些条件检测。被跳过，此时可能会出现逻辑问题。还有检查IO。在优化过程中，我们会发现引擎本身的问题基本很少。大部分在写代码的时候不够标准，或者还有其他问题。我们现在主要发现的大部分磁盘io问题都是由于写法的问题。我们记录了文件写入的时间和保存名，然后在这个统计下，我们基本上可以看到，每个秒都可以看到保存的文件大小，找到没用的保存删除。有可能是因为写法不规范，或者写的比较随意，这个操作非常频繁，会导致IO问题。你游戏里的内容是同一个循环的，有多次保存，可以把同一个文件合并到一起，最后一次保存。还有一些 IO 操作是不必要的，因为我们写入磁盘的每个文件都会执行一些保证文件，这是可以避免的。做一次之后，就不需要再做一次了。IO主要是“保存和砍”。这个操作非常频繁，会导致IO问题。你游戏里的内容是同一个循环的，有多次保存，可以把同一个文件合并到一起，最后一次保存。还有一些 IO 操作是不必要的，因为我们写入磁盘的每个文件都会执行一些保证文件，这是可以避免的。做一次之后，就不需要再做一次了。IO主要是“保存和砍”。这个操作非常频繁，会导致IO问题。你游戏里的内容是同一个循环的，有多次保存，可以把同一个文件合并到一起，最后一次保存。还有一些 IO 操作是不必要的，因为我们写入磁盘的每个文件都会执行一些保证文件，这是可以避免的。做一次之后，就不需要再做一次了。IO主要是“保存和砍”。

延迟，所有游戏玩家的感觉，游戏的交互感觉，他的感觉主要取决于服务器的返回速度，所以基本上可以建立延迟统计系统，比如玩家同意过来，开始录制时间，然后给他的回复，记录一个时间，记录两个协议的执行时间。以回合制游戏为例，如果服务器延迟0.5S以下，玩家感觉非常流畅，没有卡顿的感觉。所以一般控制在0.5S以内，活动尽量控制在2S以内，感觉会更好。前面是介绍我们引擎的一些相关的东西，

五、过程中提供协助，消除低级问题

，对解决低级bug有很好的效果，强约束类型，弱约束类型，需要选择适合自己项目的方法。还有就是平衡工作量的影响，这在我们项目的前期是绝对不需要的，因为大量的代码还在堆里，没有时间去做。当项目处于中后期的时候，我们可以考虑启动这个东西。强约束型存在中断问题。我的作品必须经过别人阅读才能提交，所以这种限制比较强。弱限制类型，我提交后，让老板看看。看完以后有问题我会改的。我们采用弱约束类型，但这不是必须的。

代码覆盖率主要是为了保证QC的测试用例写得足够全面。当我写一个代码让QC测试的时候，我不知道我的代码的所有代码逻辑都已经跑通了。为每个内容创建一个项目。例如，我们还没有运行它。我修改的所有功能都在运行。这个还没有运行。这里缺少用例。我们需要为此编写一些用例。这个主要是用来辅助QC的。

静态代码检测，因为有些东西跑不起来，主要是看看有没有错别字，调用了不存在的函数，或者调用了不符合要求的参数。因为有些参数写错了，编译不报，但是你放到外部服务器后，就开始报错了。

自动回归，为了保证前人种树，后人享荫，这是一个积累的过程。在每个版本发布之前，都会进行脚本自动回归，确保现有的东西没有问题，新的内容不会影响现有的内容。

协议测试非常重要。所有协议必须由 QC 完成。他设计值，将它们发送到服务器，并测试服务器的运行状况。尤其是手游开发，往往服务端和客户端都由一个人完成，这样很容易相信自己客户端发送的数据。写新游戏的时候，肯定有好几个这样的地方，然后肯定会被玩家刷爆。最后我们检查了所有的协议函数天外神坛，程序员检查了所有的协议参数是否都经过了有效性测试，所以这个测试是最重要的。

免责声明：本文根据 CC BY-NC-SA 3.0 协议授权

十方杀阵

青铜器陶器啥阿发

十方杀阵

这个帖子很牛逼

十方杀阵

我是这里最靓的仔

十方杀阵

我要我要我要我还要

十方杀阵

强强强强强强强强强强强强强强