DSP

EVE 居然是用 python 写的!!太不可思议了

2019-07-13 19:24发布

  大多数熟悉EVE的人都知道,它是用Python语言编写的,如果要说得更具体点,那就是Stackless Python。Stackless是在Python基础上编写的一套微线程框架,它能在不产生大量Python自身额外开销的情况下同时容纳数百万条的线程。但话还是要说回来,它毕竟还是Python,因此摆脱不了“解释器全局锁”(Global Interpreter Lock,下文将其简称为GIL)。
  GIL是一个序列锁,用来保证在任何时候都只能有一个线程利用Python解释器(包括其所有数据)来运行自己。因此,尽管Stackless Python感觉上好像具备多线程处理能力,但实际上它还是单线程的,只不过运用了任务分离、频道、定时器及共享内存等一系列招数而已。其实过去有些协作式的多任务操作系统也是这样干的,其好处是保证了所有线程都能被执行,不会出现被操作系统提前结束这一情况(除非被操作系统怀疑非法宕机)。GIL的存在使得程序员在编写游戏逻辑时能自信推断出程序的全局状态,省去了一大堆采用异步回调函数的麻烦。
  但这样有一大缺点:由于EVE中有部分框架的代码是用Python编写的,因此它们都免不了GIL造成的负面影响。比如,一段用来读取Python数据的C++语言代码必须在获得GIL后才能读取一个字符串。  
使用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。  
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非常出 {MOD}地将工作分组来处理。简而言之,就是某些操作有了一个固定的开销。网络引擎有许多这样的开销,但其他所有具有重要意义的代码也有大量开销。通过一些别出心裁的技巧,我们是可以将许多这样的工作合并在一起,这样就只产生一次开销。就像把逻辑数据包都组合在一起发送在一个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还是让我们的游戏增速了不少。      
以上为24小时内单个用户的CPU使用率  
以上为同样的24小时内总体CPU使用率
  至于SOL(星系)节点,由于它们的主要职责是游戏机制而非网络管理,因此它们从该优化中获得的优势并不那么明显,但我们还是看到它们的CPU使用率下降了8%-10%。
  需要指出的是,在上述的检验中我们没有运用BlueNet,没有用CarbonIO的数据导航,也没有用脱离GIL的数据压缩/解压缩。
总结
  总的来说,比起以前,EVE能更好地利用现代服务器硬件带来的优势,能让它在同样的时间内完成更多的工作,这样就间接提升了一个系统所能进行的操作上限。通过将我们的代码尽量与GIL脱离,我们反而为那些真正需要用它的代码腾出了空间。另外,由于不再有那么多代码需要竞相获取GIL,系统的总体运行效率也会提升。有了BlueNet再加上很好的代码优化,提速空间已被打开。虽然最后的结果仍有待实践检验,但至少,我们已经消除了一大瓶颈。