一淘技术专家清无：Nginx_lua的测试及选择

对于Web高性能服务器上的选择，这个是很多人头痛的问题。其实Apache、lighttpd、Nginx都用他们优点，在什么情况下我们如何去选择适合自己的Web高性能服务器，如何去搭建一个适合自己的架构环境，这个是一个很麻烦的事情。接下来，在ADC 2012（Alibaba Developer Conference 2012）大会上，51CTO记者有幸采访到了一淘数据平台与产品部技术专家——清无（花名），为我们解读Nginx_lua的一些优势及劣势，以及在高性能服务器上的选择。

首先让我们来了解一下Nginx_lua的设计指导思想：

1、基于Nginx 快速开发高性能、大并发的网络服务。

2、提供“同步非阻塞” 的I/O 访问接口简化I/O 多路复用体系中的业务逻辑开发：

■“同步”的主体是用户代码与其发起的I/O 请求处理流程之间的时序关系，意即I/O 请求处理完成前用户代码将一直挂起。

■“非阻塞”的主体是服务进程，意即I/O 请求的处理不会导致服务进程阻塞等待，而是可以继续处理其他请求的用户逻辑。

Nginx的特点是占有内存少，并发能力强，事实上nginx的并发能力确实在同类型的网页伺服器中表现较好。目前中国大陆使用nginx网站用户有：新浪、网易、 腾讯，另外知名的微网志Plurk也使用Nginx。

Nginx服务器及Lua版本的选择

1）Nginx高性能开源WEB服务器的选择

清无是在08年开始接触Nginx服务器的，当时高性能的开源WEB服务器还有lighttpd，那么一淘网技术专家清无为什么会选择Nginx呢？Nginx哪方面比较有它的优势？清无介绍说，lighttpd和Nginx的比较中，有一个很明显的缺点就是lighttpd的模块机制设计的很不好，lighttpd的模块机制过多的把模块本身的请求处理逻辑和底层的网络事件的处理组合在一起，所以不像Nginx的模块结构这么清晰，当然Nginx的模块设计很大程度上也借鉴了Apache的这种模块设计，所以这块有一个先天的优势。当时其实他最早接触lighttpd，然后Nginx出来以后，就对比它们模块结构上的差异后，觉得Nginx似乎更有优势一些。实测对于我们这种网络I/O密集型的应用来说，只要不是你实现的这个逻辑有多大缺陷，其实在放lighttpd或者Nginx差别不是特别大。

在比较选择的过程中，首先从架构出发，如果有问题的话无论你实现如何它都是有问题的，所以我的比较首先在架构搭建上，每连接或者每请求单线程单进程这种服务模型，直接就被刷掉，肯定不可能做到很高的服务能力。余下来清一色的都是基于RO多路的这种结构体系，那么在这个体系上我们才去检验，实际上拿一个IPP的请求来压测看它实现的质量如何，通常来说这部分一旦架构体系决定以后，实测这个性能差异不是特别的大，除非说是某个特性一个实现另一个没实现这种情况，我们测出来的差异通常是在10%-20%上下波动而已。

2）Lua版本的选择

在小编与清无的交流中了解到目前一淘网所使用lua的版本是5.1.2，当小编提出是否版本越高性能越强时，清无则认为不太对。对于lua来说每一个版本的变化意味着它将加入新的语法元素或者变更了内部的一些实现的方式。严格意义上并不说明它的性能就好，比如对5.2和5.1来说，不管对于环境表或者其它的一些机制的修改上面，严格的来说他都是一种新的语言了。所以目前来说迁移到5.2最大的障碍其实还是5.2里面对于底层接口的这种概念的变化。因为5.1里面对于一些方面下了很多工夫，然后使用它的全局表加环境表这种机制。但是5.2里面彻底取消了全局表的概念，也取消了CU级别上一系列对环境表操作的接口，对我们来说肯定是不能平滑的迁移到5.2，如果有这个需求的话，我们可以做，但目前还没有看到这个需求。另外一个阻碍我们升级版本号的问题是Lua
JIT，lua JIT的性能比标准的lua要高很多，所以深层里面我们通常用JIT，但是luaJIT目前对lua5.2的支持并不是那么紧，它目前还是以5.1为主，所以这块我没可能较长的时间跟着lua JIT的脚步来。

在一淘网的应用中，清无介绍说，Nginx_lua主要应用在两块地方，一块是传统的一淘数据库量子统计店铺经，数据接口部分完全是用Nginx_lua来做。另一块是一淘的广告部门有一部分数据接口也使用着Nginx_lua。

Nginx_lua的性能测试比较

其实也有很多人一直还在使用Nginx_php这种组合搭配，对于Nginx_lua组合的优势在哪里呢？清无介绍说，Nginx+php之间是要有进程之间通信的，这样以来基础的性能开销就很大。lua是嵌在Nginx进程内部的，它不需要有两套进程在那里独立工作。所以这块从结构上来说就有决定性的优势在里面。再加上线程之间通讯的时候需要大量的反序列化和序列化的工作，然后两套进程带来额外情况是更多的进程更多的切换开销，所以单机上面Nginx_php要比Nginx_lua要低很多。但是相对来说仍然要回到我们做什么事情上面，因为Nginx_lua目前最大的劣势就是周边的模块相当的不健全，我们需要大量的时间来积累这些模块。php积累了十几年的时间了，如果说你对性能的要求并不是那么高，我的并发数就是几十，那么你用php就是最合适的。但是如果像一淘数据的数据接口，机器数就那么一点，因为我的大量成本在MySQL集群上面，它是这块的主力，那么对外的数据接口我希望尽可能降成本，并发数又非常大，php肯定是不行，那么我们就要选择Nginx_lua。但这块的话对模块的劣势看起来不是那么大，因为它的逻辑相对来说较为固定，我们可以忍受这样的成本，我们去为这个逻辑来定制一些模块。



 


 
从上面的两张性能测试图中我们总结Nginx_lua的适用场景：

网络I/O 阻塞时间远高于CPU 计算占用时间、同时上游资源非瓶颈（可伸缩）的网络应用，如高性能网络中间层、HTTP REST 接口服务等；
期望简化系统架构，让服务向Nginx 同质化的Web 站点；
Nginx_lua的优势和劣势

对于Nginx_lua的劣势在刚刚和Nginx_php的对比的时候清无也介绍了一个是周边模块不完善，不健全的问题。如果你用到的这个东西比较复杂的时候可能生产力上不去，目前Nginx_lua最适合的人员是数据接口层，以及所有的网络中间层，你需要最求并发，高性能的网络中间层。因为它本身的逻辑相对来说比较简单，或者完全用lua本身就可以变现出来，这个用起来收效比例是最大的。那么如果你目前要做一个复杂的WEB访问站，有大量模板要套，有大量的复杂逻辑嵌在里面，然后要访问mail要访问其他服务的话，目前来说我觉得还是php或者其他比较成熟的语言。就我们目前应用来说也是这样，中间层会大量的使用lua，但是前端展现层的话要么全部移到浏览器上面用JS+模板的形式来实现，要么就是用PHP这样来做。

另外的劣势就是调试的辅助工具不太多，因为高级点的php程序员会往往会使用XDebug或者其它的调试工具，可以单步调试，在线调试。跟php相比目前还欠缺这样的一个机制。到时候我们会仿照XDebug 去实现DPT V2协议，我们实现兼容DPT V2这样的一种机制内连到Nginx_lua里面，那样Nginx_lua也可以单步调试。到时候我们也会分享给大家。

最后我们来归纳一下清无介绍的几点优势和劣势：

优势：

同步非阻塞I/O 形式直观易懂，并发服务能力强
CPU、内存运行开销低
同Nginx 结合度高，可方便粘合现有Nginx 模块功能
劣势：

属于新技术方案，Lua 相比于PHP、Ruby 等广泛使用的开发
语言，周边附属设施尚不够健全，需要时间积累
Nginx_lua的需求以及性能的追求

在需求方面，清无认为在一淘网的数据接口的这部分是完全可以满足的，至于其他的需求我们还要具体发现，寻找最佳决解方案。因为在计算机行业没有一招吃遍天这种事。

那么作为一名技术人员，在性能的追求是适合而止还是无止境的追求呢？清无表示，这个要看我们是在做生意还是在个人事情，如果是在公司，比如在具体的事情上面，然后是一个团队协作的情况下，那么盲目的追求性能的极限是一个不合适的行为，因为你的追求是要付出相应的成本和开销的，而往往在一个企业的环境里面这个是不可容忍的。最合适的架构往往是针对你去解决问题的那个架构，而不是去追求效率最高的架构。所以我们具体在企业里面做项目的时候，显然适可而止是最好的。盖过了你这个用户的最大需求你就没必要去付出更多的精力来做，因为其他的问题有很多，你没必要停留在性能这个问题上，性能只是其中的一个问题，在一个问题上没必要投入太大的精力。但是，从开发人员个人的角度来说，追求性能的极限是一个很好的想法和行为，因为开发者自己对性能极限的追求体现出对完美的追求，对于完美的追求意味着它可以从上层到底层的专研，而专研是提升个人素质最有效的动力。所以是分开来看这个问题。

协程（Coroutine）

         协程类似一种多线程，与多线程的区别有：
        1. 协程并非os线程，所以创建、切换开销比线程相对要小。
        2. 协程与线程一样有自己的栈、局部变量等，但是协程的栈是在用户进程空间模拟的，所以创建、切换开销很小。
        3.
多线程程序是多个线程并发执行，也就是说在一瞬间有多个控制流在执行。而协程强调的是一种多个协程间协作的关系，只有当一个协程主动放弃执行权，另一个协程才能获得执行权，所以在某一瞬间，多个协程间只有一个在运行。
        4.
由于多个协程时只有一个在运行，所以对于临界区的访问不需要加锁，而多线程的情况则必须加锁。
        5. 多线程程序由于有多个控制流，所以程序的行为不可控，而多个协程的执行是由开发者定义的所以是可控的。
        Nginx的每个Worker进程都是在epoll或kqueue这样的事件模型之上，封装成协程，每个请求都有一个协程进行处理。这正好与Lua内建协程的模型是一致的，所以即使ngx_lua需要执行Lua，相对C有一定的开销，但依然能保证高并发能力。

三. ngx_lua

1. 原理

        ngx_lua将Lua嵌入Nginx，可以让Nginx执行Lua脚本，并且高并发、非阻塞的处理各种请求。Lua内建协程，这样就可以很好的将异步回调转换成顺序调用的形式。ngx_lua在Lua中进行的IO操作都会委托给Nginx的事件模型，从而实现非阻塞调用。开发者可以采用串行的方式编写程序，ngx_lua会自动的在进行阻塞的IO操作时中断，保存上下文；然后将IO操作委托给Nginx事件处理机制，在IO操作完成后，ngx_lua会恢复上下文，程序继续执行，这些操作都是对用户程序透明的。

        每个NginxWorker进程持有一个Lua解释器或者LuaJIT实例，被这个Worker处理的所有请求共享这个实例。每个请求的Context会被Lua轻量级的协程分割，从而保证各个请求是独立的。

        ngx_lua采用“one-coroutine-per-request”的处理模型，对于每个用户请求，ngx_lua会唤醒一个协程用于执行用户代码处理请求，当请求处理完成这个协程会被销毁。每个协程都有一个独立的全局环境（变量空间），继承于全局共享的、只读的“comman data”。所以，被用户代码注入全局空间的任何变量都不会影响其他请求的处理，并且这些变量在请求处理完成后会被释放，这样就保证所有的用户代码都运行在一个“sandbox”（沙箱），这个沙箱与请求具有相同的生命周期。

        得益于Lua协程的支持，ngx_lua在处理10000个并发请求时只需要很少的内存。根据测试，ngx_lua处理每个请求只需要2KB的内存，如果使用LuaJIT则会更少。所以ngx_lua非常适合用于实现可扩展的、高并发的服务。

2. 典型应用

        官网上列出：

·  Mashup'ing and processing outputs of various nginx upstream outputs(proxy, drizzle, postgres, redis, memcached, and etc) in Lua,

·  doing arbitrarily complex access control and security checks in Luabefore requests actually reach the upstream backends,

·  manipulating response headers in an arbitrary way (by Lua)

·  fetching backend information from external storage backends (likeredis, memcached, mysql, postgresql) and use that information to choose whichupstream backend to access on-the-fly,

·  coding up arbitrarily complex web applications in a content handlerusing synchronous but still non-blocking access to the database backends andother storage,

·  doing very complex URL dispatch in Lua at rewrite phase,

·  using Lua to implement advanced caching mechanism for nginxsubrequests and arbitrary locations.