关于lua+nginx的一点小感悟（nginx php的工作原理）

Posted 2022-12-04 zhuxineli

为了解决项目高并发问题（已经确定瓶颈不在数据库），先介绍下总体架构吧。一台mysql、一台memcache、三台nginx，
在php代码已经做了适当优化之后，况且nginx服务器的分发能力毋庸置疑，说明现在只有两条出路，要么加机器，要么换语言，加硬件是不可能的，连买个内存都费老大劲，而换语言又是不可能的（难道让我们离职重新找别的开发语言的人或者让我们都转其他语言？），这时候在尽我利索能力的想压榨nginx性能的时候我发现了openresty，看了不少文档，真是个好东西啊—-还没有学的太深，后续一点点补齐吧
先说一下，为什么我要选型nginx+lua.首先，要明确目的，任何产物的出现都是需求导致的（人类不可能平白无故的发明原子弹吧，肯定是想要炸你啊），lua语言快（我故意说错的）或者说nginx+lua语言很快，至少要比nginx+php快，那为什么nginx+lua的组合要比nginx+php快呢？这里一个前提是lua和php都是脚本语言，那貌似更说不通了，都是脚本语言，凭什么你比我快？难道是lua的源码写的更高效？（到底是否高效我不知道，我的侧重点不在这里）。那么问题又来了，要想知道nginx+lua为什么快，那我们需要先知道nginx+php的工作原理或者是说他俩是如何搭配工作的！
nginx+php是如何搭配工作的？—-这是一个大问题
要明白这个问题就要先知道，web服务器是做什么的？我曾经翻阅了好多好多文档，找到了一句形容web服务器至少我目前看来是非常非常容易理解且直到要害的一句话：所有web服务器的设计之初都是为了用户提供静态资源（比如html页面，视频，css文件，js文件等等），也就是说web服务器（nginx、apache）本身不能处理动态语言（php）的请求，但需求已经摆在这儿了，既然你不能处理，那总得有人来处理啊，谁来处理呢？既然当然是相关语言的解析器了（php解析器、lua解析器等等），nginx在这里只是起到了分发的作用，接受请求，将动态请求分发给相应的动态语言解析器去处理，自己本身不做处理。那么问题就来了，nginx+php虽然是市面上非常常用的一对组合，但他们也是两个不同的软件，需要进程间的通信，但openresty(也就是nginx+lua)是将lua作为一个模块集成进了nginx自身（这里区别apache的mod_php模型），此时，nginx+Lua是一个软件了，不需要进程间的通信，这在根上就决定了这个组合的速度的天然优势要比ngxin+php快，但因为lua的文档比较少，函数库少等等因素，语法比较清奇（可能是我现在学的不深的原因吧），导致现在用nginx+lua作为解决方案的比nginx+php的少的多
下面梳理一下，我在学习lua的过程中遇到的问题
1.关于处理lua请求，当前我的业务逻辑绝大部分还是用php，只有少部分高并发逻辑准备用lua代替，那摆在眼前的问题就很明确了，正常的php文件用php解析，那lua文件如何用lua解析器解析呢？在nginx的配置文件中,我们是这样处理php文件的

也就是说正常的访问请求，如localhost/index.html会直接由nginx处理直接返回给客户端，localhost/index.php会交给php处理，那localhost/index.lua显而易见我们可以这样
比如说，我们通过form表单提交数据分别给php和lua处理，php的话大家都知道，在action中写index.php，然后在php文件中$_post接受就可以，那如何提交给lua呢？在action中写index.lua，然后在index.lua中
ngx.req.read_body()
args = ngx.req.get_post_args()
ngx.say(args["param"])
就可以啦，之前我一直不明白的是，能否直接在action中写index.lua,事实证明是可以的！！！
2 openresty中常用的函数总结
《1》获取用户请求方法类型 ngx.var.request_method 值绝大部分情况为get或post
《2》获取get参数 local args = ngx.req.get_uri_args()
《3》获取post参数值 local args = ngx.req.get_post_args() 前提是先要接受post传值，用ngx.req_read_body()
《4》获得参数的具体方法 value = args[“param”]