51CTO专访清无：Nginx_lua的应用及性能对比
51CTO专访清无：Nginx_lua的应用及性能对比
2012-07-13 10:57 小林 51CTO.com 字号：T | T
对于Web高性能服务器上的选择，这个是很多人头痛的问题。对于Apache、lighttpd、Nginx都用他们优点，在什么情况下我们如何去选择适合自己的Web高性能服务器，如何去搭建一个适合自己的架构环境，这个是一个很麻烦的事情。接下来，在ADC 2012（Alibaba Developer Conference 2012）大会上，51CTO记者有幸采访到了一淘数据平台与产品部技术专家——清无（花名），为我们解读Nginx_lua的一些优势及劣势，以及在高性能服务器上的选择。
AD：干货来了,不要等！WOT2015 北京站演讲PPT开放下载！
对于Web高性能服务器上的选择，这个是很多人头痛的问题。对于Apache、lighttpd、Nginx都用他们优点，在什么情况下我们如何去选择适合自己的Web高性能服务器，如何去搭建一个适合自己的架构环境，这个是一个很麻烦的事情。接下来，在ADC 2012（Alibaba Developer Conference 2012）大会上，51CTO记者有幸采访到了一淘数据平台与产品部技术专家——清无（花名），为我们解读Nginx_lua的一些优势及劣势，以及在高性能服务器上的选择。
王晓哲：花名清无，一淘网技术专家。任职于一淘数据部，负责量子恒道整体技术架构搭建。对海量数据处理、高性能高可用的Web服务相关技术有浓厚兴趣。
清无你好，lua我们都知道是一种嵌入式的脚本语言，而它最著名的是应用在暴雪的魔兽世界和网易的大话西游中。那么在淘宝上的应用lua主要是应用在那块？
清无：目前在一淘网这边Nginx_lua主要应用在两块地方，一块是传统的一淘数据库量子统计店铺经，数据接口部分完全是用Nginx_lua来做。另一块是一淘的广告部门有一部分数据接口也使用着Nginx_lua。
具我的了解，你开始接触nginx应该是2008年的。在08年时，很多高性能的WEB服务器也非常多，比如apache、lighttpd等等。这些都是高性能的开源服务器，你选择nginx是因为什么？它那方面比较吸引你？
清无：08的时候高性能WEB服务器除了Nginx以外其实只有lighttpd是开源的，lighttpd和Nginx比较的话有一个很明显的缺点是lighttpd的模块机制设计的很不好，lighttpd的模块机制过多的把模块本身的请求处理逻辑和底层的网络事件的处理组合在一起，所以不像Nginx的模块结构这么清晰，当然Nginx的模块设计很大程度上也借鉴了Apache的这种模块设计，所以这块有一个先天的优势。当时其实我最早接触lighttpd，然后Nginx出来以后，就对比它们模块结构上的差异后，觉得Nginx似乎更有优势一些。实测对于我们这种网络I/O密集型的应用来说，只要不是你实现的这个逻辑有多大缺陷，其实在放lighttpd或者Nginx差别不是特别大。
Nginx的优势你刚刚也讲了，你有没有哪nginx和其他的开源web服务器做过一些性能比较？可以跟我们网友进行一些分析。
清无：比较的话是这样，首先架构如果有问题的话无论你实现如何它都是有问题的，所以我的比较首先在架构搭建上，每连接或者每请求单线程单进程这种服务模型，直接就被刷掉，肯定不可能做到很高的服务能力。余下来清一色的都是基于RO多路**的这种结构体系，那么在这个体系上我们才去检验这个*****，实际上拿一个IPP的请求来压测看它实现的质量如何，通常来说这部分一旦架构体系决定以后，实测这个性能差异不是特别的大，除非说是某个特性一个实现另一个没实现这种情况，我们测出来的差异通常是在10%-20%上下波动而已。
lua目前最高的版本是5.2，你们现在使用的是哪个版本？
清无：我们现在使用的是5.1.2，后面那个是补丁号。
如果我认为它的版本越高，性能越强你认为对吗？
清无：呵呵，不太对。对于lua来说每一个版本的变化意味着它将加入新的语法元素或者变更了内部的一些实现的方式。严格意义上并不说明它的性能就好，比如对5.2和5.1来说，不管对于环境表或者其他的一些机制的修改上面，严格的来说他都是一种新的语言了。所以目前来说迁移到5.2最大的障碍其实还是5.2里面对于底层接口的这种概念的变化。因为5.1里面对于//形成隔离//方面下了很多工夫，然后使用它的全局表加环境表这种机制，但是5.2里面彻底取消了全局表的概念，也取消了CU级别上一系列对环境表操作的接口，对我们来说肯定是不能平滑的迁移到5.2，如果有这个需求的话，我们可以做，但目前还没有看到这个需求。另外一个阻碍我们升级版本号的问题是LuaJIT，luaJIT的性能比标准的lua要高很多，所以//深层//里面我们通常用JIT，但是luaJIT目前对lua5.2的支持并不是那么紧，它目前还是以5.1为主，所以这块我没可能较长的时间跟着luaJIT的脚步来。
据我了解lua的特点是体积小、快速、简单，作为独立编程并不是它的主要使用方式，因为它不像java那样有一个完善的库，必须嵌入到其他的大型语言中才能发挥出它的并发能力和灵活性。你们目前的主语言是什么？
清无：实际上我们是分场景，根据具体的业务场景来选择最合适的语言。对一淘数据库来说像Java，PHP，C++和lua都用。
在我的印象中很多人还是选择nginx+php这种组合搭配，你的选择是nginx+lua，那么nginx+lua比和php的组合优势在哪里？
清无：首先，Nginx+php之间是要有进程之间通信的，这样以来基础的性能开销就很大。lua是嵌在Nginx进程内部的，它不需要有两套进程在那里独立工作。所以这块从结构上来说就有决定性的优势在里面。再加上线程之间通讯的时候需要大量的反序列化和序列化的工作，然后两套进程带来额外情况是更多的进程更多的切换开销，所以单机上面Nginx_php要比Nginx_lua要低很多。但是相对来说仍然要回到我们做什么事情上面，因为Nginx_lua目前最大的劣势就是周边的模块相当的不健全，我们需要大量的时间来积累这些模块。php积累了十几年的时间了，如果说你对性能的要求并不是那么高，我的并发数就是几十，那么你用php就是最合适的。但是如果像一淘数据的数据接口，机器数就那么一点，因为我的大量成本在MySQL集群上面，它是这块的主力，那么对外的数据接口我希望尽可能降成本，并发数又非常大，php肯定是不行，那么我们就要选择Nginx_lua。但这块的话对模块的劣势看起来不是那么大，因为它的逻辑相对来说较为固定，我们可以忍受这样的成本，我们去为这个逻辑来定制一些模块。
你认为目前nginx+lua能满足你现在的需求吗？有没有尝试或寻找其他最佳的搭档？
清无：对于我们数据接口的这部分需求是完全可以满足的，至于其他的需求我们还要具体发现，寻找最佳决解方案。因为在计算机行业没有一招吃遍天这种事。
作为一名技术架构师，在性能这块你认为到何处为止？还是无止境的追求？
清无：这个要看我们是在做生意还是在个人事情，如果是在公司，比如在具体的事情上面，然后是一个团队协作的情况下，那么盲目的追求性能的极限是一个不合适的行为，因为你的追求是要付出相应的成本和开销的，而往往在一个企业的环境里面这个是不可容忍的。最合适的架构往往是针对你去解决问题的那个架构，而不是去追求效率最高的架构。所以我们具体在企业里面做项目的时候，显然适可而止是最好的。盖过了你这个用户的最大需求你就没必要去付出更多的精力来做，因为其他的问题有很多，你没必要停留在性能这个问题上，性能只是其中的一个问题，在一个问题上没必要投入太大的精力。但是，从开发人员个人的角度来说，追求性能的极限是一个很好的想法和行为，因为开发者自己对性能极限的追求体现出对完美的追求，对于完美的追求意味着它可以从上层到底层的专研，而专研是提升个人素质最有效的动力。所以是分开来看这个问题。
你刚刚在大会上也讲了一些nginx lua的优势和劣势，能不能在这里也给我们网友分享一些？
清无：刚才也说了一个是周边模块不完善，不健全。如果你用到的这个东西比较复杂的时候可能生产力上不去，目前Nginx_lua最适合的人员是数据接口层，以及所有的网络中间层，你需要最求并发，高性能的网络中间层。因为它本身的逻辑相对来说比较简单，或者完全用lua本身就可以变现出来，这个用起来收效比例是最大的。那么如果你目前要做一个复杂的WEB访问站，有大量模板要套，有大量的复杂逻辑嵌在里面，然后要访问mail要访问其他服务的话，目前来说我觉得还是php或者其他比较成熟的语言。就我们目前应用来说也是这样，中间层会大量的使用lua，但是前端展现层的话要么全部移到浏览器上面用JS+模板的形式来实现，要么就是用PHP这样来做。另外的劣势就是调试的辅助工具不太多，因为高级点的php程序员会往往会使用XDebug或者其它的调试工具，可以单步调试，在线调试。跟php相比目前还欠缺这样的一个机制。到时候我们会仿照XDebug 去实现DPT V2协议，我们实现兼容DPT V2这样的一种机制内连到Nginx_lua里面，那样Nginx_lua也可以单步调试。到时候我们也会分享给大家。