目前常用的服务器有tomcat、Apache和nginx等，服务器种类繁多，但其框架基本都是一样的，不同之处在于它的逻辑处理。本文旨在谈论其基本框架。如图所示：



        该图既能用来描述一台服务器，也可以用来描述一个服务器集群。描述对象不同，各个模块对应的实体也就有所不同。

        I/O处理单元主要是负责服务器管理客户连接的模块。一般会有以下工作：等待并接受新的客户连接、接收客户请求数据、以及将逻辑单元处理的数据返回给客户端。但是数据的接收与发送也不是一定就在I/O处理单元中进行，也有可能是在逻辑单元中进行，具体在哪执行取决于事件处理模式。另外对于一个服务器集群而言，I/O处理单元是一个专门的接入服务器，用来实现负载均衡，从所有逻辑服务器节点中选取最合适的一台来响应当前的请求。

        逻辑单元通常指的是进程或者线程。它主要是分析和处理客户端发来的请求数据，并将响应结果传递给I/O处理单元。对于服务器集群而言，一个逻辑单元就是一台逻辑服务器。服务器通常也会拥有多个逻辑单元，以实现对多个客户端请求的并发处理。

        网络存储单元一般指的是数据库、缓存或者文件，甚至是一台独立的服务器。但它不是必须的，某些登录服务就不需要这个单元，譬如ssh等。

        请求队列是各单元之间通信方式的抽象。I/O处理单元接收到客户请求时，需要以某种方式通知其中一个逻辑单元来处理该请求；而多个逻辑单元在同时访问一个存储单元时，也需要采取某种机制来协调竞态条件。一般通过池来实现。对服务器集群而言，请求队列则是各台服务器之间预先建立的、静态的、永久的tcp连接。这种tcp连接能提高服务器之间交换数据的效率，它避免了动态建立tcp连接带来的额外开销。

 

一、服务器编程框架



模块
			
单个服务器程序
			
服务器机群
		
I/O处理单元
			
处理客户连接，读写网络数据
			
作为接入服务器，实现负载均衡
		
逻辑单元
			
业务进程或线程
			
逻辑服务器
		
网络存储单元
			
本地数据库 、文件或缓存
			
数据库服务器
		
请求队列
			
各单元之间的通信方式
			
各服务器之间的永久TCP连接
		
        I/O处理单元是服务器管理客户连接的模块。主要完成以下工作：等待并接受新的客户连接，接受客户数据，将服务器响应数据返回给客户端。但是，数据的收发不一定在I/O处理单元中执行，也可能在逻辑单元中执行，具体在何处执行取决于事件处理模式。对于一个服务器机群来说，它实现负载均衡，从所有逻辑服务器中选取负荷最小的一台来为新客户服务。

        一个逻辑单元通常是一个线程或者进程。它分析并处理客户数据，然后将结果传递给I/O处理单元或者直接发送给客户端。对服务器机群而言，一个逻辑单元本身是一台逻辑服务器。服务器通常拥有多个逻辑单元，以实现对多个客户任务的并行处理。

网络存储单元可以使数据库、缓存和文件，甚至是一台独立的服务器。但它不是必须的，比如ssh、telnet等登录服务就不需要这个单元。

       请求队列是各单元之间的通信方式的抽象。I/O处理单元收到客户请求时，需要以某种方式通知一个逻辑单元来处理该请求。同样，多个逻辑单元同时访问同一个存储单元时，也需要采用某种机制来协调处理竞态条件。请求队列通常实现为池的一部分。

二、I/O模型

1.阻塞I/O和非阻塞I/O

        阻塞I/O执行的系统调用可能因为无法立即完成而被操作系统挂起，直到等待的事件发生为止。非阻塞I/O执行的系统调用总是立即返回，而不管事件是否已经发生，如果事件没有立即发生则返回-1，和出错情况一样，此时可根据errno来区分这两种情况。对accept/send和recv而言，事件未发生时errno通常被设置为EAGAIN或者EWOULDBLOCK;对于connect而言，errno则被设置成EINPROGRESS。非阻塞I/O一般和I/O通知机制一起使用，如I/O复用和SIGIO信号。

2.I/O复用

       I/O复用是最常使用的I/O通知机制，指定是应用程序通过I/O复用函数向内核注册一组事件，内核通过I/O复用函数把其中就绪的事件通知给应用程序。Linux上常用的I/O复用函数是select、poll和epoll_wait。I/O复用函数本身是阻塞的，它们能提高程序效率的原因在于它们具有同时监听多个I/O事件的能力。

3.四种I/O模型

       阻塞I/O、I/O复用、信号驱动I/O这三者都是同步I/O模型。

I/O模型
			
读写操作和阻塞阶段
		
阻塞I/O
			
程序阻塞与读写函数
		
I/O复用
			
程序阻塞与I/O复用系统调用，但可同时监听多个I/O事件。对I/O本身的读写操作是非阻塞的
		
SIGIO信号
			
·信号触发读写就绪事件，用户程序执行读写操作，程序没有阻塞阶段
		
异步I/O
			
内核执行读写操作并触发读写完成事件。程序没有阻塞阶段
		
三、两种高效的事件处理模式

      服务器程序通常要处理三类事件：I/O事件、信号和定时事件。两种高效的事件处理模式：Reactor和Proactor。一般地，同步I/O模型常用于实现Reactor模式，异步I/O模型则用于实现Proactor模式。

1.Reactor模式

        Reactor是一种这样的模式，它要求主线程（I/O处理单元）只负责监听文件描述符上是否有事件发生，有的话就立即将该事件通知工作线程（逻辑单元）。除此之外，主线程不作任何其他实质性工作。读写数据，接收新的连接，以及处理客户请求均在工作线程完成。

       使用同步I/O模型（以epoll_wait为例）实现的Reactor模式的工作流程是：

       (1)主线程往epoll内核事件表中注册socket读就绪事件；

       (2)主线程调用epoll_wait等待socket上有数据可读；

       (3)当socket上有数据可读时，epoll_wait通知主线程。主线程则将socket可读事件放入请求队列；

      (4)睡眠在请求队列上的某个工作线程被唤醒，它从socket读取数据，并处理客户请求，然后往epoll内核事件表中注册该socket上的写就绪事件；

        (5)主线程调用epoll_wait等待socket可写；

       (6)当socket可写时，epoll_wait通知主线程，主线程将socket可写事件放入请求队列；

       (7)睡眠在请求队列上的某个工作线程被唤醒，它往socket上写入服务器处理客户请求的结果。

2.Proactor模式

         Proactor模式将所有I/O操作都交给主线程和内核来处理，工作线程仅负责业务逻辑。

        使用异步I/O模型（以aio_read和aio_write为例）实现的Proactor模式工作流程是：

        (1)主线程调用aio_read函数想内核注册socket上读完成事件，并告诉内核用户读缓冲区的位置，以及读操作完成时如何通知应用程序;

        (2)主线程继续处理其他逻辑;

        (3)当socket上的数据被读入用户缓冲区后，内核将向应用程序发送一个信号，以通知应用程序数据已经可用;

        (4)应用程序预先定义好的处理函数选择一个工作线程来处理客户请求。工作线程处理完客户请求以后，调用aio_write函数想内核注册socket上的写完成事件，并告诉内核用户写缓冲区的位置，以及写操作完成时如何通知应用程序;

        (5)主线程继续处理其他逻辑;

        (6)当用户缓冲区的数据被写入socket之后，内核将向应用程序发送一个信号，以通知应用程序数据已经发送完毕;

        (7)应用程序预先定义好的信号处理函数选择一个工作线程来做善后处理，比如决定是否关闭socket.

3.两者的区别

        Reactor模式适用于耗时短的处理场景，同时接受多个服务请求，并且一次同步的处理它们的事件驱动程序。

        Proactor则适用于耗时长的处理场景，异步接受和同时处理多个服务器请求的事件驱动程序。

四、两种高效的并发模式

         并发编程的目的是让程序“同时”执行多个任务。而并发模式是指I/O处理单元和多个逻辑单元之间协调完成任务的方法。

1.半同步/半异步模式

        同步是指程序完全按照代码序列的顺序执行；异步是指程序的执行需要有系统事件来驱动，常见的系统事件包括中断、信号等。

        一种高效的半同步/半异步模式是指，主线程只管理监听socket，连接socket由工作线程来管理。主线程是异步的，工作线程也是异步的，这不是严格意义上的半同步/半异步.

 



2.领导者/追随者模式

        领导者/追随者模式是多个工作线程轮流获得事件源集合，轮流监听、分发并处理时间的一种模式。在任意时间点，程序都仅有一个领导者，它负责监听I/O事件，而其他线程则都是追随者，他们休眠在线程池中等待称为新的领导者。当前的领导者如果检测到I/O事件，首先要冲线程池中推选出新的领导者线程，然后处理I/O事件。此时，新的领导者等待新的I/O事件，而原来的领导者则处理I/O事件，二者实现了并发。

五、提高服务器性能的其他建议

        高性能服务器要注意的几个方面：池、数据复制、上下文切换和锁。

1.池

    池是一组资源的集合，这组资源在服务器启动之初就完全被创建好并初始化，这称为静态资源分配。当拂去其正式运行阶段，即开始处理客户请求的时候，如果需要相关资源，则可以直接从池中获取，无需动态分配。因为直接从池中获取资源比动态分配资源的速度要快的多，因为分配系统资源的系统调用都是很耗时的，涉及到用户态和内核态的来回切换。当服务器处理完一个客户连接以后，可以把相关资源放回池中，无需执行系统调用来释放资源。

        常见的池有内存池、进程池、线程池和连接池。

(1)内存池

        内存池通常用于socket的接收缓冲和发送缓冲。内存池的大小可以根据情况进行分配，一种是预先分配好固定的内存池大小，另一种是根据情况动态扩大接收缓冲区。

(2)进程池/线程池

        进程池和线程池都是用于并发的手段，当我们需要一个工作进程或工作线程来处理新到来的客户请求时，我们可以直接从进程的池或线程池中取得一个执行实体，而无须动态调用fork或pthread_create等函数来创建进程和线程。

(3)连接池

        连接池通常用于服务器或服务器机群的内部永久连接。如每个逻辑单元都可能需要频繁访问本地的某个数据库。简单做法是：逻辑单元每次需要访问数据库的时候，就像数据库程序发起连接，而访问完毕后释放连接。这种做法效率太低。一种解决方案是使用连接池。连接池是服务器预先和数据库程序建立的一组连接的集合。当某个逻辑单元需要访问数据库时，它可以直接从连接池中取得一个连接的实体并使用之。待完成后再返回给连接池。

2.数据复制

        尽量使用“零拷贝”函数，如sendfile()、tee()等，从而避免数据在用户空间和内核空间的来回拷贝，提高效率。

3.上下文切换和锁

        不管是多进程还是多线程，数量都不应该太多，否则可能出现进程间或线程间切换占用大量的CPU时间，从而降低效率。

       并发程序中考虑的另外一个问题是共享资源的加锁保护，加的锁应粒度尽可能的小。

 

补充：socket的基础API中，可能被阻塞的系统调用包括accept、send、recv和connect.

acl 3.0.14 版本发布了。acl
 是 one Advanced C/C++ library 的简称，主要包括网络通信库以及服务器框架库等功能，支持 Linux/Windows 平台；整个 acl 项目主要包含三个函数库： 

lib_acl：纯C开发的最基础库，主要包含网络通信及服务器编程框架以及其它丰富的功能)
lib_protocol：包含 HTTP/PING/SMTP 通信协议的C语言实现
lib_acl_cpp：基于 lib_acl 及 lib_protocol 两个C库，提供了更为强大的编程接口及丰富的功能类
项目主页：https://sourceforge.net/projects/acl/ 
技术文章主页：http://zsxxsz.iteye.com/ 

acl 包括以下丰富的常用函数库： 

常见网络应用库： SMTP 客户端库/PING 库/memcache 客户端库/handlersocket 客户端库/beanstalk 客户端库
HTTP 网络库：HTTP 客户端/服务端库，C++版 HttpServlet 类，HTTP COOKIE/HTTP SESSION 等
邮件解析库：mime解析库/RFC2047/RFC2048/mime base64/mime qp/mime uucode 等
网络通信库：阻塞/非阻塞网络 IO 库(其中 lib_acl_cpp 库通过嵌入 polarssl 而具备了 SSL 的能力)
服务器框架：包括进程池模式、线程池模式、非阻塞模式、UDP通信模式及触发器模式
事件引擎：支持 select、poll(for unix)、epoll（for linux)、kqueue（for bsd)、devpoll(for solaris)、iocp(for win32)、win32 窗口消息(for win32）事件引擎
通用连接池库：高效的连接池基础类库，支持丰富的功能
数据库客户端库：对原生的数据库客户端库进行了二次封装，使编程更为简易，功能更为丰富
xml/json 流式解析库：区别于网上其它已有的 xml/json 解析库，acl 中的 xml/json 解析库采用有限状态机方式解析数据，处理方式更为灵活
本次 acl 升级除了一些 bug 修复外，主要优化了 ACL 中的网络服务器框架及网络通信库的性能，此外，修复了一些在 solaris(x86) 上的一些不兼容性问题。主要改进包括： 

一、基础 C 库：lib_acl 

新特性：acl_json.c 增加了 acl_json_node_duplicate 用于复制一个 JSON 结点对象到一个新的 JSON 结点中；增加了 acl_json_create 用于根据一个 JSON 结点创建一个完全的 JSON 对象
新特性：acl_json_util.c 增加了 acl_json_node_build 用于根据一个 JSON 结点生成 JSON 字符串
性能优化：acl_vstream.c，__sys_read 函数中当流的 sys_read_ready 为 1 时，则不会调用系统 API select 判断超时过程，从而减少一次系统调用，因为 sys_read_ready 标志位会在事件模块(event_xxx) 中被设置
性能优化：acl_aio_server.c, acl_ioctl_server.c 服务器模块参加了控制参数：master_status_notify，当启动多个子进程时，该参数决定是否向acl_master 主进程汇报子进程的状态，当 master_prefork 预启动参数打开且该值 > 1 时，将 master_status_notify 设置为 0，则子进程不再向 acl_master 主进程汇报状态，有助于减少
 acl_master 主进程的负载
性能优化：acl_vstream.c, 在 acl_vstream_readn 中，为减少 read 次数，当输入缓冲区较小时，则自动启用双缓冲读方式
问题修复：acl_json_parse.c，json_val() 函数中没有针对转义内容做特殊处理
问题修复：acl_vstream.c，在 acl_vstream_ctl 函数中，当控制参数为 ACL_VSTREAM_CTL_PATH 时，对 stream->addr_peer 的赋值有问题（此 bug 由高版本的 gcc4.8.2 检测出）
编译：Makefile 支持 solaris 编译
其它：去掉了 event 目录下的 events_kernel2.c 及 events_kernel3.c
其它：acl_msg.c，在函数 acl_last_serror() 中分配的线程局部变量在主线程中无法被正常释放，会导致 valgrind 报错
二、网络应用协议库：lib_protocol 

问题修复：http_chat_sync.c，在函数 http_res_body_get_sync 中，当为 chunked 传输方式时，需要设置 ctx->chunk.chunk_oper = CHUNK_OPER_HEAD
编译：Makefile 支持 solaris 编译
其它：http_hdr_res.c/http_hdr_req.c，内部的线程局部变量无法在主线程中释放，会导致 valgrind 报警告
三、功能丰富的C++库：lib_acl_cpp 

新特性：新增加 event 模块，将 master_timer 定时器类改名为 event_timer 类放于 event 模块中
新特性：在基类 master_base 中添加了方法 proc_set_timer 用于添加进程级别的定时器，(同时移除了 master_threads 子类中的 proc_set_timer 方法)，这样 master_base 的所有子类 (master_threads, master_aio, master_proc, master_udp, master_trigger) 都可以添加进程级别的定时器
新特性：master 模块增加了定时器类 master_timer
新特性：json 类增加了以下功能函数：                    a) 构造函数 json(const json_node&)，可以根据一个 json 对象的某一个 json 结点创建一个新的 json 对象 

                    b) duplicate_node 根据一个 json 对象的某个 json 结点复制一个新的 json 结点 

                    c) to_string 新的将 json 对象转换为字符串的函数
新特性：json_node 类增加了以下功能函数：                    a) to_string 根据 json 结点生成 json 字符串的函数 

                    b) set_tag 用来替换标签名 

                    c) set_text 当 json 结点为叶结点时用来替换标签值
新特性：http_header 类丰富了 set_url 及请求构造函数的参数类型，允许 URL 参数中含有请求参数，且内部会自动解析 url 中的主机名及参数
新特性：http_header 类添加了请求参数添加方法：add_int 及 add_format
新特性：http_header add_param 允许参数值为空指针或空串
新特性：http_header::set_host 仅是将主机字符串添加至成员变量 host_ 中
新特性：http_header::set_url 中允许添加类似于 http://www.test.com 的 url(即末尾可以没有 '/')
新特性：http_client 类增加了 chunked 传输方式；
新特性：http_request 类增加流式写函数：write_head/write_body；
新特性：http_response 类增加了流式写数据方式
新特性：HttpServletRequest 类增加了几个获取 HTTP 请求头参数的方法
新特性：http_utils::get_addr 的 url 参数既可以是 HTTP 也可以是 HTTPS
新特性：master_threads 模板支持新的定时器
问题修复：connect_pool::put 在归还连接给连接池时，为了让过期连接尽快回收，需要调用 push_front，原来调用了 push_back
问题修复：http_header.cpp，http_header::date_format 在 WIN32 编译出错
问题修复：json.cpp, json::getElementsByTags() 内部未对空指针做判断
问题修复：http_header.cpp, http_header::date_format 在 UNIX 平台下 gmtime 是线程不安全的，所以需要使用 gmtime_r
问题修复：http_download.cpp 的构造函数中调用 ACL_SAFE_STRNCPY 时第三个参数给出错误的尺寸大小（此 bug 由高版本的 gcc4.8.2 检测出）
问题修复：Makefile 支持 solaris(x86) 编译
新增示例：samples/json2, 用于测试级联提取数据的例子
新增示例：samples/ 目录下新增加了 json 测试用例 json3/json4
示例：samples/master_udp_threads：该例子中的线程局部变量的静态用法 __thread 无法支持 solaris，改为动态方式使用线程局部变量方式
注释：修正 connect_manager::init 原来错误的参数格式描述
注释：消除了几个头文件中由 doxygen 检测出的错误注释
其它：stream 模块的异步流部分，将 aio_timer_callback 等类声明从 aio_handle 类中移除成为独立的类
其它：调整类 http_client 中的两个函数 get_respond_head  和 get_request_head 的返回值限制，去掉 const 限定词
技术博客：http://zsxxsz.iteye.com/ 
下载地址：http://sourceforge.net/projects/acl/ 
svn：svn checkout svn://svn.code.sf.net/p/acl/code/trunk acl-code 
Github地址：https://github.com/zhengshuxin/acl

服务器模型
C/S模型(客户端/服务器)
如图：



TCP/IP协议在设计和实现上并没有客户端和服务器的概念，在通信过程中所有机器都是对等的。但由于资源(视频、新闻、软件等)都被数据提供者所垄断

几乎所有的网络应用程序都很自然地采用了C/S 模型:所有客户端都通过访问服务器来获取所需的资源
特点

非对等服务，即客户端与服务器处于不对等地位
体现：服务器有软硬件资源及运算能力而客户端没有，服务器提供服务客户端请求服务

TCP服务器和TCP客户端工作流程



服务器可以同时监听多个请求：通过select系统调用实现
服务器在监听到请求后接收它并分配一个逻辑单元为新的连接服务【新建的子进程、子线程或其他】

应用

C/S模型适合资源相应集中的场所，实现简单

缺点

服务器是通信的中心，当访问量过大时，可能所有的客户端都得到很慢的响应【此时用P2P模型】
P2P模型(点对点)
相对C/S模型，更符合网络通信的实际情况，服务器不再是中心，让网络上所有主机回归到对等的地位

优：P2P模型使得每台机器在消耗服务的同时也给别人提供服务，这样资源能够充分、自由地共享。云计算机群可以看作P2P模型的一个典范

缺：当用户之间传输的请求过多时，网络的负载将加重



图a中主机之间很难互相发现。所以实际使用的P2P模型通常带有一个专门的发现服务器，这个发现服务器通常还提供查找服务(甚至提供内容服务),使每个客户都能尽快地找到自己需要的资源
从编程角度来讲，P2P模型可以看作C/S模型的扩展:每台主机既是客户端，又是服务器

服务器编程框架
服务器程序种类不同：其基本框架都一样，只是逻辑处理不同

服务器基本框架：



该基本框架可描述一台服务器或服务器机群
各部件功能、含义：




模块
单个服务器程序
服务器机群




I/O处理单元
处理客户连接，读写网络数据
作为接入服务器，实现负载均衡


逻辑单元
业务进程/线程
逻辑服务器


网络存储单元
本地数据库、文件/缓存
数据库服务器


请求队列
各单元间通信方式
各服务器之间的永久TCP连接



I/O处理单元

对服务器：服务器管理客户连接的模块。它通常要完成以下工作:等待并接受新的客户连接，接收客户数据，将服务器响应数据返回给客户端。

数据的收发不一定在I/O处理单元中执行，也可能在逻辑单元中执行(具体在何处执行取决于事件处理模式)
对一个服务器机群：I/O处理单元是一个专门的接入服务器。它实现负载均衡，从所有逻辑服务器中选取负荷最小的一台来为新客户服务

逻辑单元

对服务器：通常是一个进程或线程。它分析并处理客户数据，然后将结果传递给I/O处理单元或者直接发送给客户端(具体使用哪种方式取决于事件处理模式)
对服务器机群：一个逻辑单元本身就是一台逻辑服务器。服务器通常拥有多个逻辑单元，以实现对多个客户任务的并行处理

网络存储单元

它不是必须的，比如ssh、telnet 等登录服务就不需要这个单元

请求队列

对服务器：是各单元之间的通信方式的抽象。IO处理单元接收到客户请求时，需要以某种方式通知一个逻辑单元来处理该请求。同样，多个逻辑单元同时访问一个存储单元时，也需要采用某种机制来协调处理竞态条件(请求队列通常被实现为池的一部分)
对服务器机群：请求队列是各台服务器之间预先建立的、静态的、永久的TCP连接。这种TCP连接能提高服务器之间交换数据的效率，因为它避免了动态建立TCP连接导致的额外的系统开销