原始英文连结：http://community.eveonline.com/devblog.asp?a=blog&nbid=2332 简体文章连结：http://eve.tiancity.com/homepage/article/2012/05/15/35308.html 这是中国CCP翻译欧服Devblog的成果，底下已转成繁体 我有在twitter上建议Horace先翻一些跟TiDi有关的Devblog文章，这虽然不是我建议的那 几篇，但依旧很好看，这种充满技术名词的文件光看头就大了，幸好中国CCP会持续翻译 到全部翻完，即使仍旧看不太懂，但有中文可看真是太棒了！！ ============================================================================== 【开发日志】CarbonIO与BlueNet：下一代的网络技术 作者：CCP Curt 译者：CCP Lion 大多数熟悉EVE的人都知道，它是用Python语言编写的，如果要说得更具体点，那就是 Stackless Python。Stackless是在Python基础上编写的一套微线程框架，它能在不产生 大量Python自身额外开销的情况下同时容纳数百万条的线程。但话还是要说回来，它毕竟 还是Python，因此摆脱不了“解释器全局锁”（Global Interpreter Lock，下文将其简 称为GIL）。 GIL是一个序列锁，用来保证在任何时候都只能有一个线程利用Python解释器（包括其 所有数据）来运行自己。因此，尽管Stackless Python感觉上好像具备多线程处理能力， 但实际上它还是单线程的，只不过运用了任务分离、频道、定时器及共享内存等一系列招 数而已。 其实过去有些协作式的多任务操作系统也是这样干的，其好处是保证了所有线 程都能被执行，不会出现被操作系统提前结束这一情况（除非被操作系统怀疑非法宕机） 。 GIL的存在使得程序员在编写游戏逻辑时能自信推断出程序的全局状态，省去了一大 堆采用异步回调函数的麻烦。 但这样有一大缺点：由於EVE中有部分框架的代码是用Python编写的，因此它们都免不了 GIL造成的负面影响。 比如，一段用来读取Python数据的C++语言代码必须在获得GIL後才 能读取一个字符串。 图片短网址：http://tinyurl.com/77s5fcc http://image.tiancity.com/article/UserFiles/Image/EVE/2012/05/15/eve0515 _a01.jpg 使用Python的任务都要获得GIL才能合法地被处理，这样等同於Python任务都是 单线程执行。 （这图画得不太好看，人家只是个程序员，不是美术师哦） 一言以蔽之，Stackless Python 代码的运行速度不会高於你最快的那个CPU核心的速度。 在一台4核或8核CPU的服务器上，其中只有一核在超负荷运作，其他都没派上用场。当然 ，为了让这些CPU核心物尽其用，我们可以在它们身上加载更多的节点。对於EVE中许多无 状态或对共享状态依赖度极低的代码而言，这没什麽问题。但对於像太空模拟或空间站行 走这样高度依赖共享状态的代码而言，就成了一个大问题。 假设一个CPU核心就能处理所有的逻辑并且写出来的Python代码较为清晰，那我之前说的 都不是什麽问题。不过，想必我不用说大家也知道，尽管Gridlock等小组已经在优化工作 方面做到了其极致，但我们现在面临的情况依旧是单个CPU已经无法处理一场大型会战了 。最近上市的CPU速度是更快、缓存容量也更大、总线也更宽裕并且具备更好的执行流水 线，但在EVE需要其给力的地方，却没有任何进步。近期（也可能包括中长期）的趋势是 “横向增长”，即同时运行多个CPU核心。 总体而言，多核CPU的流行对EVE的长远发展是一大利好。 未来那些30乃至60核CPU的机器 能够很好地体现EVE集群部署方式的优势，这是因为CPU核心之间切换的效率将远远大於线 程之间切换的效率。但就目前而言，为了提升游戏运行速度，我们需要把网络及通用读写 这样的EVE模块从GIL中解放出来。 多核心、超标量的硬件对当今的网络游戏来说，都是个好消息。这些游戏很适合这种架构 ，并且能很容易地进行并行处理。可惜对於依赖Python的EVE来说，这就算不得好消息了 。那些对运行速度要求极高、不需要Python便利开发优势的EVE系统需要尽早摆脱GIL的束 缚。CarbonIO在这个方向上可以说是向前迈进了一大步。 CarbonIO 是在StacklessIO 基础上的一个自然提升。它实际上是个从头写起的全新引 擎，目标非常明确：让网络流量摆脱GIL的束缚，并且让任何C++代码也能这样做。後半个 目的是重头戏，我们花了大半年才把它完成。 这里不得不先稍微提一下StacklessIO。对Stackless Python的网络通信而言，它可以说 是个质的飞跃。通过让网络操作变得具有“无堆栈的意识”，StacklessIO可以将一个被 锁住的操作转移到一个未被GIL锁住的线程上，这样该操作就可以继续等候，而Stackless 则继续处理其他事务。然後，该操作重新获得GIL，告诉Stackless其操作已完成。这样， 接收端就可以同步进行，使得通讯速度可以达到操作系统级别，并且能基本上在第一时间 内回报给Python。 图片短网址：http://tinyurl.com/8xy2lj3 http://image.tiancity.com/article/UserFiles/Image/EVE/2012/05/15/eve0515 _a02.jpg StacklessIO在没有GIL的情况下完成Python请求 CarbonIO在此基础上更上一层楼。由於它是在完全脱离於GIL的情况下运行多线程通信 引擎，因此Python与该系统之间的交互便是完全独立了。没有Python的要求，它也能收发 数据。 请允许我再强调一下：CarbonIO能在Python不作任何要求的情况下收发数据。这是并发性 的，不需要GIL。 当一个连接通过CarbonIO被建立後，系统会调用WSARecv()开始接收数据。与Python进程 并行的线程池将这些数据解密、解压缩然後转义到数据包里。这些数据包会排队，等着 Python来处理。 当Python觉得它需要一个数据包时，它会往下调用“可能已将此包准备就绪”的CarbonIO 。这意味着数据在离开队列被返回整个过程中根本没有用到GIL。这是一个瞬时过程，至 少也有纳秒那麽快。这个并行读取能力是CarbonIO的第一大好处。 第二大好处便是发送了。数据以其原始形式排在工作线程队列里，然後便等着Python来调 用了。 其间的压缩、加密、打包及WSASend()调用都没有触及GIL而发生在另一个线程里 ，这样操作系统便可以安排它运行在另一颗CPU上了。C++代码也可以调用一个方法来这样 做，并不需要特别的架构变更。StacklessIO也可以那样做，但在脱离上述背景的情况下 ，这会变得很没意义。 让我们再来回顾一下之前提到的“已将此包准备就绪”。但如果我们要安置一个C++回调 钩子函数，使得非Python模块能在不触及Machonet的情况下获得那个数据，这可行吗？ 行啊，这时我们要用的就是BlueNet了。 CarbonIO不停地进行数据接收，并且能在无Python介入的情况下告诉C++模块数据已收 到。 Machonet是一个大型功能集合，它负责对会话进行分流、导向及管理，负责对数据包的 时间计划/发送以及其他一系列将EVE撮合成一个有机整体的功能。由於它是个Python模块 ，因此所有的数据迟早都必须触及那倒霉的GIL，无论数据在哪个节点。无论一个C++模块 的速度有多快，GIL仍然是个绕不过的瓶颈。这使得我们曾经都不太愿意做大量的C++优化 ，因为任何优化後取得的优势都会被Machonet 中的GIL吞噬。 但现在情况不一样了。 现在C++的系统能通过BlueNet收发数据包，无需再理会GIL。这原来是专门为了空间站行 走设计的。空间站行走功能需要发送大量的表示移动的数据。EVE中太空飞行的那部分功 能所需要收发的数据，我们以前可以用旁门左道的方法来解决，但对於如此近距离的人物 动作，就不行了。 之前我们做的预测显示，即使把空间站行走发送数据的频率控制在一 般程度，该功能也会把整个服务器集群拖垮。通过在没有GIL干扰的情况下对流入/流出 C++原生系统（比如物理系统）的数据进行分流，BlueNet成功地解决了该问题。由於在这 种情况下，数据还是保持着其原生态，因此整个系统运行的速度就比之前提高了。 这个具体是怎麽运作的呢？ BlueNet保存着一份所有必要Machonet结构的只读拷贝，另外 ，所有的数据包前都会附上很小的一段（（8到10个字节）数据头。这个数据头里含有路径 信息。当BlueNet接到一个数据包时，它会对其进行检测，然後合理地再分发：要么转发到 另一个节点上，要么交给被本地的已注册的C++应用程序。如果它转发，那这个过程中将用 不到GIL，根本不会调用Machonet/Python。这意味着我们的代理服务器完全能以并行方式 对BlueNet的数据包进行分流，而不必去经过Python导致额外开销的产生。那这效率究竟提 高了多少呢？ 我们还无法确定，但在降低机器负载及延迟方面，它还是非常非常明显的。 实际上我们还不能将数据公开，因为它们好得难以置信。 除此之外，CarbonIO也包含了大量底层优化，绝大多数都是小规模的速度提升，但把这些 统统叠加起来，整个系统的运行速度也就有了显着提高。以下几点值得一提： 工作分组 虽然我很难在本文中把这事儿说得太细，但CarbonIO非常出色地将工作分组来处理。简而 言之，就是某些操作有了一个固定的开销。网络引擎有许多这样的开销，但其他所有具有 重要意义的代码也有大量开销。通过一些别出心裁的技巧，我们是可以将许多这样的工作 合并在一起，这样就只产生一次开销。就像把逻辑数据包都组合在一起发送在一个 TCP/IP MTU里一样（EVE一直就是这样干的），CarbonIO将这一做法进一步深化。一个比 较简单的例子就是GIL获取集合。 第一个要尝试取得GIL的线程会先建立起一个队列，这样其他要获取GIL的线程只需将自己 的唤醒调用排在队列末尾然後返回线程池就行。那GIL最後被取得时，第一个线程会吸乾 整个队列，不必在每次IO唤醒时释放/重拾GIL。在一个繁忙的服务器上这种情况很多，因 此这种改进对我们来说是一大利好。 openSSL整合 CarbonIO用openSSL来实现SSL，并且能在不锁定GIL的情况下与该协议数据通信。该库 只是用作一个BIO对而已，所有的数据导航还是由CarbonIO通过完成端口进行的。这有助 於我们循序渐进地让EVE变得更安全，甚至将来可以把官方网站上的某些帐号管理功能挪 到EVE客户端上去，这样可以更方便大家。 压缩整合 CarbonIO能利用zlib或snappy对每一个数据包都进行压缩/解压缩，这一过程同样是无 需GIL的。 实战检验 通过对一个繁忙的代理服务器（人数峰值大约1600人，一个平常工作日）的24小时数据的 收集，我们发现CPU的总体使用率与单个用户的CPU使用率都出现了大幅下降。这都归功於 CarbonIO的总体架构，其作用就是降低事务的开销。当服务器变得繁忙之後，这些优化的 效果会被逐渐增多且必须处理的事务所抵消，但在最高负载时，CarbonIO还是让我们的游 戏增速了不少。 图片短网址：http://tinyurl.com/775fsg8 http://image.tiancity.com/article/UserFiles/Image/EVE/2012/05/15/eve0515 _a04.jpg 图片短网址：http://tinyurl.com/8x7q7eo http://image.tiancity.com/article/UserFiles/Image/EVE/2012/05/15/eve0515 _a05.jpg 以上为24小时内单个用户的CPU使用率 图片短网址：http://tinyurl.com/7cd22zw http://image.tiancity.com/article/UserFiles/Image/EVE/2012/05/15/eve0515 _a06.jpg 以上为同样的24小时内总体CPU使用率 至於SOL（星系）节点，由於它们的主要职责是游戏机制而非网络管理，因此它们从该优 化中获得的优势并不那麽明显，但我们还是看到它们的CPU使用率下降了8%-10%。 需要指出的是，在上述的检验中我们没有运用BlueNet，没有用CarbonIO的数据导航，也 没有用离GIL的数据压缩/解压缩。 总结 总的来说，比起以前，EVE能更好地利用现代服务器硬件带来的优势，能让它在同样的时 间内完成更多的工作，这样就间接提升了一个系统所能进行的操作上限。通过将我们的代 码尽量与GIL脱离，我们反而为那些真正需要用它的代码腾出了空间。另外，由於不再有 那麽多代码需要竞相获取GIL，系统的总体运行效率也会提升。有了BlueNet再加上很好的 代码优化，提速空间已被打开。虽然最後的结果仍有待实践检验，但至少，我们已经消除 了一大瓶颈。 原文 http://community.eveonline.com/devblog.asp?a=blog&nbid=2332 --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 220.130.245.45 ※ art1:转录至看板 C_Chat 05/15 15:02 ※ art1:转录至看板 GameDesign 05/15 15:23