高性能网络服务器编程：为什么linux下epoll

基本的IO编程过程（包括网络IO和文件IO）是，打开文件描述符（windows是handler，Java是stream或channel），多路捕获（Multiplexe，即select和poll和epoll）IO可读写的状态，而后可以读写的文件描述符进行IO读写，由于IO设备速度和CPU内存比速度会慢，为了更好的利用CPU和内存，会开多线程，每个线程读写一个文件描述符。

但C10K问题，让我们意识到在超大数量的网络连接下，机器设备和网络速度不再是瓶颈，瓶颈在于操作系统和IO应用程序的沟通协作的方式。

举个例子，一万个socket连接过来，传统的IO编程模型要开万个线程来应对，还要注意，socket会关闭打开，一万个线程要不断的关闭线程重建线程，资源都浪费在这上面了，我们算建立一个线程耗1M内存，1万个线程机器至少要10G内存，这在IA-32的机器架构下基本是不可能的（要开PAE），现在x64架构才有可能舒服点，要知道，这仅仅是粗略算的内存消耗。别的资源呢？

所以，高性能的网络编程（即IO编程），第一，需要松绑IO连接和应用程序线程的对应关系，这就是非阻塞（nonblocking）、异步（asynchronous）的要求的由来（构造一个线程池，epoll监控到有数的fd，把fd传入线程池，由这些worker thread来读写io）。第二，需要高性能的OS对IO设备可读写（数据来了）的通知方式：从level-triggered notification到edge-triggered notification，关于这个通知方式，我们稍后谈。

需要注意异步，不等于AIO（asynchronous IO），Linux的AIO和java的AIO都是实现异步的一种方式，都是渣，这个我们也接下来会谈到。

针对前面说的这两点，我们看看select和poll的问题

这两个函数都在每次调用的时候要求我们把需要监控（看看有没有数据）的文件描述符，通过数组传递进入内核，内核每次都要扫描这些文件描述符，去理解它们，建立一个文件描述符和IO对应的数组（实际内核工作会有好点的实现方式，但可以这么理解先），以便IO来的时候，通知这些文件描述符，进而通知到进程里等待的这些select、poll。当有一万个文件描述符要监控的时候呢（一万个网络连接）？这个工作效率是很低的，资源要求却很高。

我们看epoll

epoll很巧妙，分为三个函数，第一个函数创建一个session类似的东西，第二函数告诉内核维持这个session，并把属于session内的fd传给内核，第三个函数epoll_wait是真正的监控多个文件描述符函数，只需要告诉内核，我在等待哪个session，而session内的fd，内核早就分析过了，不再在每次epoll调用的时候分析，这就节省了内核大部分工作。这样每次调用epoll，内核不再重新扫描fd数组，因为我们维持了session。

说道这里，只有一个字，开源，赞，众人拾柴火焰高，赞。

epoll的效率还不仅仅体现在这里，在内核通知方式上，也改进了，我们先看select和poll的通知方式，也就是level-triggered notification，内核在被DMA中断，捕获到IO设备来数据后，本来只需要查找这个数据属于哪个文件描述符，进而通知线程里等待的函数即可，但是，select和poll要求内核在通知阶段还要继续再扫描一次刚才所建立的内核fd和io对应的那个数组，因为应用程序可能没有真正去读上次通知有数据后的那些fd，应用程序上次没读，内核在这次select和poll调用的时候就得继续通知，这个os和应用程序的沟通方式效率是低下的。只是方便编程而已（可以不去读那个网络io，方正下次会继续通知）。

于是epoll设计了另外一种通知方式：edge-triggered notification，在这个模式下，io设备来了数据，就只通知这些io设备对应的fd，上次通知过的fd不再通知，内核不再扫描一大堆fd了。

基于以上分析，我们可以看到epoll是专门针对大网络并发连接下的os和应用沟通协作上的一个设计，在linux下编网络服务器，必然要采用这个，nginx、PHP的国产异步框架swool、varnish，都是采用这个。

注意还要打开epoll的edge-triggered notification。而java的NIO和NIO2都只是用了epoll，没有打开edge-triggered notification，所以不如JBoss的Netty。

接下来我们谈谈AIO的问题，AIO希望的是，你select，poll，epoll都需要用一个函数去监控一大堆fd，那么我AIO不需要了，你把fd告诉内核，你应用程序无需等待，内核会通过信号等软中断告诉应用程序，数据来了，你直接读了，所以，用了AIO可以废弃select，poll，epoll。

但linux的AIO的实现方式是内核和应用共享一片内存区域，应用通过检测这个内存区域（避免调用nonblocking的read、write函数来测试是否来数据，因为即便调用nonblocking的read和write由于进程要切换用户态和内核态，仍旧效率不高）来得知fd是否有数据，可是检测内存区域毕竟不是实时的，你需要在线程里构造一个监控内存的循环，设置sleep，总的效率不如epoll这样的实时通知。所以，AIO是渣，适合低并发的IO操作。所以java7引入的NIO2引入的AIO对高并发的网络IO设计程序来说，也是渣，只有Netty的epoll+edge-triggered notification最牛，能在linux让应用和OS取得最高效率的沟通。

想设计亿万级高并发架构，你要先知道高并发是什么？

面对流量高峰，不同的企业是如何通过技术手段解决高并发难题的呢

0、引言

软件系统有三个追求：高性能、高并发、高可用，俗称三高。三者既有区别也有联系，门门道道很多，全面讨论需要三天三夜，本篇讨论高并发。

高并发（High Concurrency）。并发是操作系统领域的一个概念，指的是一段时间内多任务流交替执行的现象，后来这个概念被泛化，高并发用来指大流量、高请求的业务情景，比如春运抢票，电商双十一，秒杀大促等场景。

很多程序员每天忙着搬砖，平时接触不到高并发，哪天受不了跑去面试，还常常会被面试官犀利的高并发问题直接KO，其实吧，高并发系统也不高深，我保证任何一个智商在线的看过这篇文章后，都能战胜恐惧，重拾生活的信心。

本文先介绍高并发系统的度量指标，然后讲述高并发系统的设计思路，再梳理高并发的关键技术，最后结合作者的经验做一些延伸探讨。

1、高并发的度量指标

既然是高并发系统，那并发一定要高，不然就名不副实。并发的指标一般有QPS、TPS、IOPS，这几个指标都是可归为系统吞吐率，QPS越高系统能hold住的请求数越多，但光关注这几个指标不够，我们还需要关注RT，即响应时间，也就是从发出request到收到response的时延，这个指标跟吞吐往往是此消彼长的，我们追求的是一定时延下的高吞吐。

比如有100万次请求，99万次请求都在10毫秒内响应，其他次数10秒才响应，平均时延不高，但时延高的用户受不了，所以，就有了TP90/TP99指标，这个指标不是求平均，而是把时延从小到大排序，取排名90%/99%的时延，这个指标越大，对慢请求越敏感。

除此之外，有时候，我们也会关注可用性指标，这可归到稳定性。

一般而言，用户感知友好的高并发系统，时延应该控制在250毫秒以内。

什么样的系统才能称为高并发？这个不好回答，因为它取决于系统或者业务的类型。不过我可以告诉你一些众所周知的指标，这样能帮助你下次在跟人扯淡的时候稍微靠点儿谱，不至于贻笑大方。

通常，数据库单机每秒也就能抗住几千这个量级，而做逻辑处理的服务单台每秒抗几万、甚至几十万都有可能，而消息队列等中间件单机每秒处理个几万没问题，所以我们经常听到每秒处理数百万、数千万的消息中间件集群，而像阿某的API网关，每日百亿请求也有可能。

2、高并发的设计思路

高并发的设计思路有两个方向：

垂直方向扩展，也叫竖向扩展

水平方向扩展，也叫横向扩展

垂直方向：提升单机能力

提升单机处理能力又可分为硬件和软件两个方面：

硬件方向，很好理解，花钱升级机器，更多核更高主频更大存储空间更多带宽

软件方向，包括用各快的数据结构，改进架构，应用多线程、协程，以及上性能优化各种手段，但这玩意儿天花板低，就像提升个人产出一样，996、007、最多24 X 7。

水平方向：分布式集群

为了解决分布式系统的复杂性问题，一般会用到架构分层和服务拆分，通过分层做隔离，通过微服务解耦。

这个理论上没有上限，只要做好层次和服务划分，加机器扩容就能满足需求，但实际上并非如此，一方面分布式会增加系统复杂性，另一方面集群规模上去之后，也会引入一堆AIOps、服务发现、服务治理的新问题。

因为垂直向的限制，所以，我们通常更关注水平扩展，高并发系统的实施也主要围绕水平方向展开。

3、高并发的关键技术

玩具式的网络服务程序，用户可以直连服务器，甚至不需要数据库，直接写磁盘文件。但春运购票系统显然不能这么做，它肯定扛不住这个压力，那一般的高并发系统是怎么做呢？比如某宝这样的正经系统是怎么处理高并发的呢？

其实大的思路都差不多，层次划分 + 功能划分。可以把层次划分理解为水平方向的划分，而功能划分理解为垂直方向的划分。

首先，用户不能直连服务器，要做分布式就要解决“分”的问题，有多个服务实例就需要做负载均衡，有不同服务类型就需要服务发现。

集群化：负载均衡

负载均衡就是把负载（request）均衡分配到不同的服务实例，利用集群的能力去对抗高并发，负载均衡是服务集群化的实施要素，它分3种：

DNS负载均衡，客户端通过URL发起网络服务请求的时候，会去DNS服务器做域名解释，DNS会按一定的策略（比如就近策略）把URL转换成IP地址，同一个URL会被解释成不同的IP地址，这便是DNS负载均衡，它是一种粗粒度的负载均衡，它只用URL前半部分，因为DNS负载均衡一般采用就近原则，所以通常能降低时延，但DNS有cache，所以也会更新不及时的问题。

硬件负载均衡，通过布置特殊的负载均衡设备到机房做负载均衡，比如F5，这种设备贵，性能高，可以支撑每秒百万并发，还能做一些安全防护，比如防火墙。

软件负载均衡，根据工作在ISO 7层网络模型的层次，可分为四层负载均衡（比如章文嵩博士的LVS）和七层负载均衡（NGINX），软件负载均衡配置灵活，扩展性强，阿某云的SLB作为服务对外售卖，Nginx可以对URL的后半部做解释承担API网关的职责。

所以，完整的负载均衡链路是 client <-> DNS负载均衡 -> F5 -> LVS/SLB -> NGINX

不管选择哪种LB策略，或者组合LB策略，逻辑上，我们都可以视为负载均衡层，通过添加负载均衡层，我们将负载均匀分散到了后面的服务集群，具备基础的高并发能力，但这只是万里长征第一步。

数据库层面：分库分表+读写分离

前面通过负载均衡解决了无状态服务的水平扩展问题，但我们的系统不全是无状态的，后面通常还有有状态的数据库，所以解决了前面的问题，存储有可能成为系统的瓶颈，我们需要对有状态存储做分片路由。

数据库的单机QPS一般不高，也就几千，显然满足不了高并发的要求。

所以，我们需要做分库分表 + 读写分离。

就是把一个库分成多个库，部署在多个数据库服务上，主库承载写请求，从库承载读请求。从库可以挂载多个，因为很多场景写的请求远少于读的请求，这样就把对单个库的压力降下来了。

如果写的请求上升就继续分库分表，如果读的请求上升就挂更多的从库，但数据库天生不是很适合高并发，而且数据库对机器配置的要求一般很高，导致单位服务成本高，所以，这样加机器抗压力成本太高，还得另外想招。

读多写少：缓存

缓存的理论依据是局部性原理。

一般系统的写入请求远少于读请求，针对写少读多的场景，很适合引入缓存集群。

在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求，因为缓存集群很容易做到高性能，所以，这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。

缓存的命中率一般能做到很高，而且速度很快，处理能力也强（单机很容易做到几万并发），是理想的解决方案。

CDN本质上就是缓存，被用户大量访问的静态资源缓存在CDN中是目前的通用做法。

缓存也有很多需要谨慎处理的问题：

一致性问题：(a)更新db成功+更新cache失败 -> 不一致 (b)更新db失败+更新cache成功 -> 不一致 ©更新db成功+淘汰缓存失败 -> 不一致

缓存穿透：查询一定不存在的数据，会穿透缓存直接压到数据库，从而导致缓存失去作用，如果有人利用这个漏洞，大量查询一定不存在的数据，会对数据库造成压力，甚至打挂数据库。解决方案：布隆过滤器 或者 简单的方案，查询不存在的key，也把空结果写入缓存（设置较短的过期淘汰时间），从而降低命失

缓存雪崩：如果大量缓存在一个时刻同时失效，则请求会转到DB，则对DB形成压迫，导致雪崩。简单的解决方案是为缓存失效时间添加随机值，降低同一时间点失效淘汰缓存数，避免集体失效事件发生

但缓存是针对读，如果写的压力很大，怎么办？

高写入：消息中间件

同理，通过跟主库加机器，耗费的机器资源是很大的，这个就是数据库系统的特点所决定的。

相同的资源下，数据库系统太重太复杂，所以并发承载能力就在几千/s的量级，所以此时你需要引入别的一些技术。

比如说消息中间件技术，也就是MQ集群，它是非常好的做写请求异步化处理，实现削峰填谷的效果。

消息队列能做解耦，在只需要最终一致性的场景下，很适合用来配合做流控。

假如说，每秒是1万次写请求，其中比如5千次请求是必须请求过来立马写入数据库中的，但是另外5千次写请求是可以允许异步化等待个几十秒，甚至几分钟后才落入数据库内的。

那么此时完全可以引入消息中间件集群，把允许异步化的每秒5千次请求写入MQ，然后基于MQ做一个削峰填谷。比如就以平稳的1000/s的速度消费出来然后落入数据库中即可，此时就会大幅度降低数据库的写入压力。

业界有很多著名的消息中间件，比如ZeroMQ，rabbitMQ，kafka等。

消息队列本身也跟缓存系统一样，可以用很少的资源支撑很高的并发请求，用它来支撑部分允许异步化的高并发写入是很合适的，比使用数据库直接支撑那部分高并发请求要减少很多的机器使用量。

避免挤兑：流控

再强大的系统，也怕流量短事件内集中爆发，就像银行怕挤兑一样，所以，高并发另一个必不可少的模块就是流控。

流控的关键是流控算法，有4种常见的流控算法。

计数器算法（固定窗口）：计数器算法是使用计数器在周期内累加访问次数，当达到设定的限流值时，触发限流策略，下一个周期开始时，进行清零，重新计数，实现简单。计数器算法方式限流对于周期比较长的限流，存在很大的弊端，有严重的临界问题。

滑动窗口算法：将时间周期分为N个小周期，分别记录每个小周期内访问次数，并且根据时间滑动删除过期的小周期，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。此算法可以很好的解决固定窗口算法的临界问题。

漏桶算法：访问请求到达时直接放入漏桶，如当前容量已达到上限（限流值），则进行丢弃（触发限流策略）。漏桶以固定的速率进行释放访问请求（即请求通过），直到漏桶为空。分布式环境下实施难度高。

令牌桶算法：程序以r（r=时间周期/限流值）的速度向令牌桶中增加令牌，直到令牌桶满，请求到达时向令牌桶请求令牌，如获取到令牌则通过请求，否则触发限流策略。分布式环境下实施难度高。

4、高并发的实践经验

接入-逻辑-存储是经典的互联网后端分层，但随着业务规模的提高，逻辑层的复杂度也上升了，所以，针对逻辑层的架构设计也出现很多新的技术和思路，常见的做法包括系统拆分，微服务。

除此之外，也有很多业界的优秀实践，包括某信服务器通过协程（无侵入，已开源libco）改造，极大的提高了系统的并发度和稳定性，另外，缓存预热，预计算，批量读写（减少IO），池技术等也广泛应用在实践中，有效的提升了系统并发能力。

为了提升并发能力，逻辑后端对请求的处理，一般会用到生产者-消费者多线程模型，即I/O线程负责网络IO，协议编解码，网络字节流被解码后产生的协议对象，会被包装成task投入到task queue，然后worker线程会从该队列取出task执行，有些系统会用多进程而非多线程，通过共享存储，维护2个方向的shm queue，一个input q，一个output q，为了提高并发度，有时候会引入协程，协程是用户线程态的多执行流，它的切换成本更低，通常有更好的调度效率。

另外，构建漏斗型业务或者系统，从客户端请求到接入层，到逻辑层，到DB层，层层递减，过滤掉请求，Fail Fast（尽早发现尽早过滤），嘴大屁眼小，哈哈。

漏斗型系统不仅仅是一个技术模型，它也可以是一个产品思维，配合产品的用户分流，逻辑分离，可以构建全方位的立体模型。

5、小结

莫让浮云遮望眼，除去繁华识真颜。我们不能掌握了大方案，吹完了牛皮，而忽视了编程最本质的东西，掌握最基本最核心的编程能力，比如数据架构和算法，设计，惯用法，培养技术的审美，也是很重要的，既要致高远，又要尽精微。

电子商务网站高负载，简单可以分为前端和后台：

前端主要是（应该没有文件下载吧），因为是电子商务网站，少不了大量的，用户集中的情况下，网页加载就会变的极其缓慢。

解决思路：1、压缩，使产品图不失真的情况下尽可能的减少体积，节省宽带。2、增大服务器带宽。3、优化网页代码，尽量采用异步加载方式。4、CDN

后台则是数据处理和数据库负载，电子商务网站后台除了庞大的用户数据要处理意外，还有大量订单，和结算数据。

解决思路：增大数据库服务器配置。

高并发，是所有访问量大的网站都会遇到的问题，并发数是指同一时刻，服务器能接受多少次同时访问，比如服务器配置并发数为200，则这一刻只能允许200个用户同时访问，超过并发数，轻则用户打不开网站，严重的则是服务器宕机。

解决思路：1、CDN。2、增加服务器配置

注：CDN是现在网站普遍使用的加速方案，对减轻服务器负载，避免高并发，缓解恶意攻击都有很好的效果，其主要原理就是将服务器上的数据分发给多个服务器，用户访问的是CDN服务器，从而减轻和保护了网站服务器，也就是常说的云服务器。

1：配置executor属性

打开/conf/serverxml文件，在Connector之前配置一个线程池：

重要参数说明：name ：共享线程池的名字。这是Connector为了共享线程池要引用的名字，该名字必须唯一。默认值：None； namePrefix ：在JVM上，每个运行线程都可以有一个name 字符串。这一属性为线程池中每个线程的name字符串设置了一个前缀，Tomcat将把线程号追加到这一前缀的后面。默认值：tomcat-exec-； maxThreads ：该线程池可以容纳的最大线程数。默认值：200； maxIdleTime ：在Tomcat关闭一个空闲线程之前，允许空闲线程持续的时间(以毫秒为单位)。只有当前活跃的线程数大于minSpareThread的值，才会关闭空闲线程。默认值：60000(一分钟)。 minSpareThreads ：Tomcat应该始终打开的最小不活跃线程数。默认值：25。

2：配置Connector

重要参数说明：executor ：表示使用该参数值对应的线程池； minProcessors ：服务器启动时创建的处理请求的线程数； maxProcessors ：最大可以创建的处理请求的线程数； acceptCount ：指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。

一Tomcat内存优化

Tomcat内存优化主要是对 tomcat 启动参数优化，我们可以在 tomcat 的启动脚本 catalinash 中设置JAVA_OPTS 参数。

1JAVA_OPTS参数说明

现公司服务器内存一般都可以加到最大2G ，所以可以采取以下配置：

在cygwin=false前添加

配置完成后可重启Tomcat ，通过以下命令进行查看配置是否生效：

首先查看Tomcat 进程号：

result

我们可以看到Tomcat 进程号是27698 。

查看是否配置生效：

能在输出的信息中找到Heap Configuration中看到MaxHeapSize 等参数已经生效。

二Tomcat并发优化

1Tomcat连接相关参数

在Tomcat 配置文件 serverxml 中的 配置中

1参数说明

minProcessors ：最小空闲连接线程数，用于提高系统处理性能，默认值为 10 maxProcessors ：最大连接线程数，即：并发处理的最大请求数，默认值为 75 acceptCount ：允许的最大连接数，应大于等于 maxProcessors ，默认值为 100 enableLookups ：是否反查域名，取值为： true 或 false 。为了提高处理能力，应设置为 false connectionTimeout ：网络连接超时，单位：毫秒。设置为 0 表示永不超时，这样设置有隐患的。通常可设置为 30000 毫秒。其中和最大连接数相关的参数为maxProcessors 和 acceptCount 。如果要加大并发连接数，应同时加大这两个参数。web server允许的最大连接数还受制于操作系统的内核参数设置，通常 Windows 是 2000 个左右， Linux是 1000 个左右。

2Tomcat中的配置示例

2调整连接器connector的并发处理能力

1参数说明

maxThreads ：客户请求最大线程数 minSpareThreads ：Tomcat初始化时创建的 socket 线程数 maxSpareThreads ：Tomcat连接器的最大空闲 socket 线程数 enableLookups ：若设为true, 则支持域名解析，可把 ip 地址解析为主机名 redirectPort ：在需要基于安全通道的场合，把客户请求转发到基于SSL 的 redirectPort 端口 acceptAccount ：监听端口队列最大数，满了之后客户请求会被拒绝（不能小于maxSpareThreads ） connectionTimeout ：连接超时 minProcessors ：服务器创建时的最小处理线程数 maxProcessors ：服务器同时最大处理线程数 URIEncoding ：URL统一编码

2Tomcat中的配置示例

3Tomcat缓存优化

1参数说明

compression ：打开压缩功能 compressionMinSize ：启用压缩的输出内容大小，这里面默认为2KB compressableMimeType ：压缩类型 connectionTimeout ：定义建立客户连接超时的时间 如果为 -1, 表示不限制建立客户连接的时间

2Tomcat中的配置示例

4参考配置

1旧有的配置

参考网络对服务器做过如下配置，拿出来分享下：

后来发现在访问量达到3 百万多的时候出现性能瓶颈。

2更改后的配置

不同类型的网站对于服务器资源的占用情况也不一样

如果是普通的企业站或者文字为主的网站不需要做负载均衡,用一台四核至强处理器4G以上内存10M以上带宽的配置基本上就能满足

如果是较大规模或者是视频内容较多的网站,则会对服务器资源占用较高推荐用双至强八核处理器32G内存1T硬盘的配置来放数据库,然后再用几台普通四核配置的机器放网站前端来做负载均衡即可带宽需要根据你们的具体需求来决定