2020/01/16 10:47
有跟tomcat开线程的方式对比吗?
2020/01/16 11:03
https://my.oschina.net/zhangxufeng/blog/3151282 这篇文章介绍nginx惊群问题,虽然现在已经在内核层面解决了,但是通过这个就可以看出来Tomcat(包括netty)与nginx使用epoll模型的异同了。单纯从请求接收方面来讲,Tomcat采用的是一个单线程accept客户端请求,然后将请求的read和write事件分发到其他的线程上,这也正是Reactor模型的处理模式,但是read和write事件的处理与用户业务流程的处理都是使用的同一个线程,如果业务处理较慢,就会到这这个本来只需要专门处理read和write事件的线程被业务代码阻塞了。对于nginx而言,首先其是使用多个worker进程(每个进程实际上也只维护了一个线程)来监听客户端请求的accept事件,这在并发度上要比Tomcat的单线程处理accept事件要强。而且nginx在转发请求到上游服务器的时候,也是使用的异步事件的方式,也就是说上游服务器在处理请求的时候nginx的worker进程还是可以继续处理其他的事件的,这种方式的效率比Tomcat要强很多。
2020/01/16 08:58
你多看看就了解了,不过我感觉最难的还是配置文件解析那部分,至今未看懂
2020/01/16 10:13
配置文件解析,其实也比较好理解,多看看源码,nginx的配置文件的解析分为三种方式:file、token和block。所谓的file指的是当前需要解析的是一个文件,初始状态解析的时候就是file。然后在解析的过程中,nginx每次都只会解析一个token,所谓的token指的是以一个分号结尾的完整一句配置,根据这个这个token的第一个配置名称,nginx会查找所有的ngx_command_t结构体,判断这个结构体的name属性值是不是与解析出来的这个token的名称相同(当然,还有其他的诸如类型的判断),如果相同,就说明这个结构体是用于解析这个token的。这个时候就会调用这个结构体的set属性所指定的方法解析当前token。所谓的block解析,就是解析的配置块,比如http{}配置块。同理,http这个名称也可以理解为一个名称,nginx会找到与这个名称对应的ngx_command_t结构体。然后调用这个结构体的set方法解析这个配置块,而在解析的过程中,对于http配置块的子配置项,则会在这个set方法里进行递归的调用。
2020/01/16 10:21
可能你感觉比较难理解的是nginx解析各个配置之后各个结构体的组织方式,尤其是http模块的结构体的嵌套方式,这部分确实比较难理解,这一块的博文我已经写了,会在后续进行讲解。
2020/01/15 11:33
可能我刚加入开源吧,不熟悉
2020/01/16 10:29
如果不是c或c++开发人员,对于nginx源码的理解会相对吃力一些,不过这个不用太担心,如果能够坚持下来,nginx源码理解起来还是非常有趣的。建议先学习一下nginx的基本使用方式,然后看一下《深入理解nginx》这本书,在看的过程中也要一边看源码,并且调试源码,不然单纯只是看书可能会有种云里雾里的感觉。
2020/01/15 11:32
该评论暂时无法显示,详情咨询 QQ 群:点此入群
回复 @
{{emojiItem.symbol}}
返回顶部
顶部