nginx简介
Nginx ("engine x") 是一个高性能的网站用户有:淘宝、百度、新浪、网易、腾讯等。
nginx应用场景
1、结构图：
nginx的主要特点
高并发连接: 官方称单节点支持5万并发连接数，实际生产环境能够承受2-3万并发。内存消耗少: 在3万并发连接下，开启10个nginx进程仅消耗150M内存 (15M*10=150M)配置简单成本低廉: 开源免费支持rewrite重写规则: 能够根据域名、url的不同，将模型简介)
阻塞(blocking)非阻塞(nonblocking )同步(synchronous )阻塞I/O(blocking I/O)I/O多路复用非阻塞I/O(nonblocking I/O)信号驱动异步(asynchronous )异步I/O基本概念
I/O涉及的对象：应用程序进程(简称进程)操作系统内核(简称内核)I/O经历的过程(以读操作为例)：等待数据准备(简称准备过程)将数据从内核拷贝到进程(简称拷贝过程)阻塞：进程在准备过程中阻塞地等待非阻塞：进程在准备过程中不会阻塞同步：进程在拷贝过程中需要阻塞等待异步：进程在拷贝过程中不需要阻塞等待
同步阻塞I/O阻塞I/O
最常见也是默认情况下我们会使用的，进程发起read操作后，进程阻塞等待数据准备就绪，进程阻塞等待内核将数据拷贝到进程中。
I/O多路复用
所谓的select、epoll，又叫事件驱动I/O。在java中叫nio，进程发起一个或多个socket的read请求后：用select/epoll方法阻塞等待数据就绪，一旦有至少一个就绪，进程阻塞等待内核拷贝数据到进程中。处理单个连接并不比阻塞I/O快。好处在于可以提高并发性，一个线程可同时处理多个连接。
同步非阻塞I/O非阻塞I/O
进程发起read操作后
进程无需阻塞等待数据准备就绪，若未就绪立即返回err进程过一段时间后再次发起read操作，询问是否准备就绪若已经准备就绪，则进程阻塞等待内核将数据拷贝到进程中信号驱动I/O
进程发起read操作时，注册信号handler
进程无需阻塞等待数据准备就绪数据就绪后内核通过信号通知进程，并调用进程注册的信号handler进程阻塞等待数据拷贝异步非阻塞I/O
进程发起read操作，将socket和接收数据的buffer传递给内核后：
无需阻塞等待数据准备就绪数据就绪后也无需阻塞等待内核拷贝数据内核拷贝数据完成后发送信号通知进程数据已经可用nginx 如何保证强大的并发能力
nginx使用epoll(linux2.6内核)和kqueue(freebsd)网络模型，而apache使用传统的select模型epoll 与 select都是 I/O 多路复用epoll是当前在Linux下开发大规模并发网络程序的热门选择。
select模型与epoll模型的对比
select模型的缺点
最大并发数限制，因为一个进程所打开的FD（文件描述符）是有限制的，由FD_SETSIZE设置，默认值是1024/2048，因此Select模型的最大并发数就被相应限制了。自己改改这个FD_SETSIZE？想法虽好，可是先看看下面吧…效率问题，select每次调用都会线性扫描全部的FD集合，这样效率就会呈现线性下降，把FD_SETSIZE改大的后果就是，大家都慢慢来，什么？都超时了。内核/用户空间 内存拷贝问题，如何让内核把FD消息通知给用户空间呢？在这个问题上select采取了内存拷贝方法。注：从上面看，select和epoll都需要在返回后，通过遍历文件描述符来获取就绪的socket。事实上，同时连接的大量客户端在同一时刻只有很少处于就绪状态，因此随着监视的文件数量增长，其效率也会呈现线性下降。
epoll 模型的优点：
相对于select和poll来说，epoll更加灵活，没有描述符限制(它所支持的FD上限是最大可以打开文件的数目，这个数字一般远大于2048,举个例子,在1GB内存的机器上大约是10万左右，具体数目可以cat/proc/sys/fs/file-max察看)。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。IO的效率不会随着监视fd的数量的增长而下降。epoll不同于select和poll轮询的方式，而是通过每个fd定义的回调函数来实现的。只有就绪的fd才会执行回调函数。内存拷贝，Epoll在这点上使用了“共享内存”，这个内存拷贝也省略了。注：Epoll不仅会告诉应用程序有I/O事件到来，还会告诉应用程序相关的信息，根据这些信息应用程序就能直接定位到事件，而不必遍历整个FD集合nginx配置实例
反向代理缓存静态化文件
Tomcat的整体结构介绍
Tomcat的整体架构图下:
相关组件的大致介绍如下:
Server组件:Server组件是最顶级的组件,它代表Tomcat的运行实例,在一个JVM中只会包含一个Server。在Server的整个生命周期中,Server组件中的Listener组件实现事件的监听并完成相应的任务,此外Server中包含的GlobalNamingResources组件是为了方便在Tomcat中集成JNDI。除了这两个组件,Server的核心组件就是Service组件Service组件:Service是服务的抽象,它代表请求从接收到处理的所有组件的集合,一个Server组件可以包含多个Service组件,每一个Service组件都包含了若干的用于接受客户端消息的Connector组件和处理请求的Engine组件以及一些Executor组件。其中不同的Connector组件使用不同的通信协议,如组件的关系图如下:
,此外,Connector组件中还包含有Mapper组件和CoyoteAdapter组件。 Mapper组件:客户端请求的路由导航组件,通过它能够对一个完整的请求地址进行路由,从而根据请求地址找到对应的Servlet。 CoyoteAdapter组件:一个将Connector和Container适配起来的适配器。容器组件Tomcat内部有4个级别的容器,分别是Engine、Host、Context和Wrapper。
Engine组件:
Engine代表全局的Servlet引擎,每一个Service组件只能包含一个Engine容器组件,但是一个Engine组件可以包含多个Host组件,除了Host组件之外,还包含以下的组件。
Host组件:
Tomcat中Host组件代表的是虚拟主机,其中存放着若干的抽象的Web应用。Host组件除了包含Context组件之外还包含以下的组件
Context组件:
Context组件是Web应用的抽象,其包含了各种静态资源、若干Servlet(Wrapper容器)以及各种其他动态资源。其除了包含主要的Wrapper组件之外还包括以下的组件:
Wrapper组件:
一个Wrapper组件对应着一个Servlet,其主要包含以下的组件
小结总之,Tomcat从功能上可以抽象的看做是由连接器组件(Connector)和容器组件(Container)组成。Connector组件负责在服务器端处理客户端的连接,包括接受客户端的连接、接受客户端的消息,对消息报文进行解析。Container组件负责对客户端的请求进行逻辑处理然后把结果返回给客户端
作者：FuyunWang链接：来源：掘金著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。