Linux高性能服务器设计

C10K和C10M

计算机领域的不少技术都是需求推进的，上世纪90年代，因为互联网的飞速发展，网络服务器没法支撑快速增加的用户规模。1999年，Dan Kegel提出了著名的C10问题：一台服务器上同时处理10000个客户网络链接。10000个网络链接并不会发送请求到服务器，有些链接并不活跃，同一时刻，只有极少的部分链接发送请求。不一样的服务类型，每一个链接发送请求的频率也不相同，游戏服务器的链接会频繁的发送请求，而Web服务器的链接发送请求的频率就低不少。不管如何，根据经验法则，对于特定的服务类型，链接越多，同一时刻发送请求的链接也越多。

时至今日，C10K问题固然早已解决，不只如此，一台机器能支撑的链接愈来愈多，后来提出了C10M问题，在一台机器上支撑1000万的链接，2015年，MigratoryData在单机承载12M的链接，解决了C10M问题。

本文先回顾C10问题的解决方案，再探讨如何构建支撑C10M的应用程序，聊聊其中涉及的各类技术。

C10K问题的解决

时间退回到1999年，当时要实现一个网络服务器，大概有这样几种模式

简单进程/线程模型

这是一种很是简单的模式，服务器启动后监听端口，阻塞在accept上，当新网络链接创建后，accept返回新链接，服务器启动一个新的进程/线程专门负责这个链接。从性能和伸缩性来讲，这种模式是很是糟糕的，缘由在于

进程/线程建立和销毁的时间，操做系统建立一个进程/线程显然须要时间，在一个繁忙的服务器上，若是每秒都有大量的链接创建和断开，采用每一个进程/线程处理一个客户链接的模式，每一个新链接都要建立建立一个进程/线程，当链接断开时，销毁对应的线程/进程。建立和销毁进程/线程的操做消耗了大量的CPU资源。使用进程池和线程池能够缓解这个问题。

内存占用。主要包含两方面，一个是内核数据结构所占用的内存空间，另一个是Stack所占用的内存。有些应用的调用栈很深，好比Java应用，常常能看到几十上百层的调用栈。

上下文切换的开销。上下文切换时，操做系统的调度器中断当前线程，选择另一个可运行的线程在CPU上继续运行。调度器须要保存当前线程的现场信息，而后选择一个可运行的线程，再将新线程的状态恢复到寄存器中。保存和恢复现场所须要的时间和CPU型号有关，选择一个可运行的线程则彻底是软件操做，Linux 2.6才开始使用常量时间的调度算法。 以上是上下文切换的直接开销。除此以外还有一些间接开销，上下文切换致使相关的缓存失效，好比L1/L2 Cache，TLB等，这些也会影响程序的性能，可是间接开销很难衡量。

有意思的是，这种模式虽然性能极差，但却依然是咱们今天最多见到的模式，不少Web程序都是这样的方式在运行。

select/poll

另一种方式是使用select/poll，在一个线程内处理多个客户链接。select和poll可以监控多个socket文件描述符，当某个文件描述符就绪，select/soll从阻塞状态返回，通知应用程序能够处理用户链接了。使用这种方式，咱们只须要一个线程就能够处理大量的链接，避免了多进程/线程的开销。之因此把select和poll放在一块儿说，缘由在于二者很是类似，性能上基本没有区别，惟一的区别在于poll突破了select 1024个文件描述符的限制，然而当文件描述符数量增长时，poll性能急剧降低，所以所谓突破1024个文件描述符实际上毫无心义。select/poll并不完美，依然存在不少问题：

1. 每次调用select/poll，都要把文件描述符的集合从用户地址空间复制到内核地址空间
2. select/poll返回后，调用方必须遍历全部的文件描述符，逐一判断文件描述符是否可读/可写。

这两个限制让select/poll彻底失去了伸缩性。链接数越多，文件描述符就越多，文件描述符越多，每次调用select/poll所带来的用户空间到内核空间的复制开销越大。最严重的是当报文达到，select/poll返回以后，必须遍历全部的文件描述符。假设如今有1万个链接，其中只一个链接发送了请求，可是select/poll就要把1万个链接所有检查一遍。

epoll

FreeBSD 4.1引入了kqueue，此时是2000年7月，而在Linux上，还要等待2年后的2002年才开始引入kqueue的相似实现: epoll。epoll最初于 2.5.44进入Linux kernel mainline，此时已是2002年，距离C10K问题提出已通过了3年。

epoll是如何提供一个高性能可伸缩的IO多路复用机制呢？首先，epoll引入了epoll instance这个概念，epoll instance在内核中关联了一组要监听的文件描述符配置：interest list，这样的好处在于，每次要增长一个要监听的文件描述符，不须要把全部的文件描述符都配置一次，而后从用户地址空间复制到内核地址空间，只须要把单个文件描述符复制到内核地址空间，复制开销从O(n)降到了O(1)。

注册完文件描述符后，调用epoll_wait开始等待文件描述符事件。epoll_wait能够只返回已经ready的文件描述符，所以，在epoll_wait返回以后，程序只须要处理真正须要处理的文件描述符，而不用把全部的文件描述符所有遍历一遍。假设在所有N个文件描述符中，只有一个文件描述符Ready，select/poll要执行N次循环，epoll只须要一次。

epoll出现以后，Linux上才真正有了一个可伸缩的IO多路复用机制。基于epoll，可以支撑的网络链接数取决于硬件资源的配置，而再也不受限于内核的实现机制。CPU越强，内存越大，能支撑的链接数越多。

编程模型

Reactor和proactor

不一样的操做系统上提供了不一样的IO多路复用实现，Linux上有epoll，FreeBSD有kqueue，Windows有IOCP。对于须要跨平台的程序，必然须要一个抽象层，提供一个统一的IO多路复用接口，屏蔽各个系统接口的差别性。

Reactor是实现这个目标的一次尝试，最先出如今Douglas C. Schmidt的论文"The Reactor An Object-Oriented Wrapper for Event-Driven Port Monitoring and Service Demultiplexing"中。从论文的名字能够看出，Reactor是poll这种编程模式的一个面向对象包装。考虑到论文的时间，当时正是面向对象概念正火热的时候，什么东西都要蹭蹭面向对象的热度。论文中，DC Schmidt描述了为何要作这样的一个Wrapper，给出了下面几个缘由：

1. 操做系统提供的接口太复杂，容易出错。select和poll都是通用接口，由于通用，增长了学习和正确使用的复杂度。
2. 接口抽象层次过低，涉及太多底层的细节。
3. 不能跨平台移植。
4. 难以扩展。

实际上除了第三条跨平台，其余几个理由实在难以站得住脚。select/poll这类接口复杂吗，使用起来容易出错吗，写出来的程序难以扩展吗？不过不这么说怎么体现Reactor的价值呢。正如论文名称所说的，Reactor本质是对操做系统IO多路复用机制的一个面向对象包装，为了证实Reactor的价值，DC Schmidt还用C++面向对象的特性实现了一个编程框架：ACE，实际上使用ACE比直接使用poll或者epoll复杂多了。

后来DC Schmidt写了一本书《面向模式的软件架构》，再次提到了Reactor，并从新命名为Reactor Pattern，如今网络上能找到的Reactor资料，基本上都是基于Reactor Pattern，而不是早期的面向Object-Orientend Wrapper。

《面向模式的软件》架构中还提到了另一种叫作Proactor的模式，和Reactor很是相似，Reactor针对同步IO，Proactor则针对异步IO。

Callback，Future和纤程

Reactor看上去并不复杂，可是想编写一个完整的应用程序时候就会发现其实没那么简单。为了不Reactor主逻辑阻塞，全部可能会致使阻塞的操做必须注册到epoll上，带来的问题就是处理逻辑的支离破碎，大量使用callback，产生的代码复杂难懂。若是应用程序中还有非网络IO的阻塞操做，问题更严重，好比在程序中读写文件。Linux中文件系统操做都是阻塞的，虽然也有Linux AIO，可是一直不够成熟，难堪大用。不少软件采用线程池来解决这个问题，不能经过epoll解决的阻塞操做，扔到一个线程池执行。这又产生了多线程内存开销和上下文切换的问题。

Future机制是对Callback的简单优化，本质上仍是Callback，可是提供了一致的接口，代码相对来讲简单一些，不过在实际使用中仍是比较复杂的。Seastar是一个很是完全的future风格的框架，从它的代码能够看到这种编程风格真的很是复杂，阻塞式编程中一个函数几行代码就能搞定的事情，在Seastar里须要上百行代码，几十个labmda (在Seastar里叫作continuation)。

纤程是一种用户态调度的线程，好比Go语言中的goroutine，有些人可能会把这种机制成为coroutine，不过我认为coroutine和纤程仍是有很大区别的，coroutine是泛化的子进程，具备多个进入和退出点，用来一些一些相互协做的程序，典型的例子就是Python中的generator。纤程则是一种运行和调度机制。

纤程真正作到了高性能和易用，在Go语言中，使用goroutine实现的高性能服务器是一件轻松愉快的事情，彻底不用考虑线程数、epoll、回调之类的复杂操做，和编写阻塞式程序彻底同样。

网络优化

Kernel bypass

网络子系统是Linux内核中一个很是庞大的组件，提供了各类通用的网络能力。通用一般意味在在某些场景下并非最佳选择。实际上业界的共识是Linux内核网络不支持超大并发的网络能力。根据我过去的经验，Linux最大只能处理1MPPS，而如今的10Gbps网卡一般能够处理10MPPS。随着更高性能的25Gbps，40Gbps网卡出现，Linux内核网络能力愈加捉襟见肘。

为何Linux不能充分发挥网卡的处理能力？缘由在于：

• 大多数网卡收发使用中断方式，每次中断处理时间大约100us，另外要考虑cache miss带来的开销。部分网卡使用NAPI，轮询+中断结合的方式处理报文，当报文放进队列以后，依然要触发软中断。
• 数据从内核地址空间复制到用户地址空间。
• 收发包都有系统调用。
• 网卡到应用进程的链路太长，包含了不少没必要要的操做。

Linux高性能网络一个方向就是绕过内核的网络栈(kernel bypass)，业界有很多尝试。

• PF_RING 高效的数据包捕获技术，比libpcap性能更好。须要本身安装内核模块，启用ZC Driver，设置transparent_mode=2的状况下，报文直接投递到客户端程序，绕过内核网络栈。
• Snabbswitch 一个Lua写的网络框架。彻底接管网卡，使用UIO(Userspace IO)技术在用户态实现了网卡驱动。
• Intel DPDK，直接在用户态处理报文。很是成熟，性能强大，限制是只能用在Intel的网卡上。根据DPDK的数据，3GHz的CPU Core上，平均每一个报文的处理时间只要60ns（一次内存的访问时间）。
• Netmap 一个高性能收发原始数据包的框架，包含了内核模块以及用户态库函数，须要网卡驱动程序配合，所以目前只支持特定的几种网卡类型，用户也能够本身修改网卡驱动。
• XDP，使用Linux eBPF机制，将报文处理逻辑下放到网卡驱动程序中。通常用于报文过滤、转发的场景。

kernel bypass技术最大的问题在于不支持POSIX接口，用户没办法不修改代码直接移植到一种kernel bypass技术上。对于大多数程序来讲，还要要运行在标准的内核网络栈上，经过调整内核参数提高网络性能。

网卡多队列

报文到达网卡以后，在一个CPU上触发中断，CPU执行网卡驱动程序从网卡硬件缓冲区读取报文内容，解析后放到CPU接收队列上。这里全部的操做都在一个特定的CPU上完成，高性能场景下，单个CPU处理不了全部的报文。对于支持多队列的网卡，报文能够分散到多个队列上，每一个队列对应一个CPU处理，解决了单个CPU处理瓶颈。

为了充分发挥多队列网卡的价值，咱们还得作一些额外的设置：把每一个队列的中断号绑定到特定CPU上。这样作的目的，一方面确保网卡中断的负载能分配到不一样的CPU上，另一方面能够将负责网卡中断的CPU和负责应用程序的CPU区分开，避免相互干扰。

在Linux中，/sys/class/net/${interface}/device/msi_irqs下保存了每一个队列的中断号，有了中断号以后，咱们就能够设置中断和CPU的对应关系了。网上有不少文章能够参考。

网卡Offloading

回忆下TCP数据的发送过程：应用程序将数据写到套接字缓冲区，内核将缓冲区数据切分红不大于MSS的片断，附加上TCP Header和IP Header，计算Checksum，而后将数据推到网卡发送队列。这个过程当中须要CPU全程参与， 随着网卡的速度愈来愈快，CPU逐渐成为瓶颈，CPU处理数据的速度已经赶不上网卡发送数据的速度。经验法则，发送或者接收1bit/s TCP数据，须要1Hz的CPU，1Gbps须要1GHz的CPU，10Gbps须要10GHz的CPU，已经远超单核CPU的能力，即便能彻底使用多核，假设单个CPU Core是2.5GHz，依然须要4个CPU Core。

为了优化性能，现代网卡都在硬件层面集成了TCP分段、添加IP Header、计算Checksum等功能，这些操做再也不须要CPU参与。这个功能叫作tcp segment offloading，简称tso。使用ethtool -k 能够检查网卡是否开启了tso

除了tso，还有其余几种offloading，好比支持udp分片的ufo，不依赖驱动的gso，优化接收链路的lro

充分利用多核

随着摩尔定律失效，CPU已经从追求高主频转向追求更多的核数，如今的服务器大都是96核甚至更高。构建一个支撑C10M的应用程序，必须充分利用全部的CPU，最重要的是程序要具有水平伸缩的能力：随着CPU数量的增多程序可以支撑更多的链接。

不少人都有一个误解，认为程序里使用了多线程就能利用多核，考虑下CPython程序，你能够建立多个线程，可是因为GIL的存在，程序最多只能使用单个CPU。实际上多线程和并行自己就是不一样的概念，多线程表示程序内部多个任务并发执行，每一个线程内的任务能够彻底不同，线程数和CPU核数没有直接关系，单核机器上能够跑几百个线程。并行则是为了充分利用计算资源，将一个大的任务拆解成小规模的任务，分配到每一个CPU上运行。并行能够 经过多线程实现，系统上有几个CPU就启动几个线程，每一个线程完成一部分任务。

并行编程的难点在于如何正确处理共享资源。并发访问共享资源，最简单的方式就加锁，然而使用锁又带来性能问题，获取锁和释放锁自己有性能开销，锁保护的临界区代码不能只能顺序执行，就像CPython的GIL，没能充分利用CPU。

Thread Local和Per-CPU变量

这两种方式的思路是同样的，都是建立变量的多个副本，使用变量时只访问本地副本，所以不须要任何同步。现代编程语言基本上都支持Thread Local，使用起来也很简单，C/C++里也可使用__thread标记声明ThreadLocal变量。

Per-CPU则依赖操做系统，当咱们提到Per-CPU的时候，一般是指Linux的Per-CPU机制。Linux内核代码中大量使用Per-CPU变量，但应用代码中并不常见，若是应用程序中工做线程数等于CPU数量，且每一个线程Pin到一个CPU上，此时才可使用。

原子变量

若是共享资源是int之类的简单类型，访问模式也比较简单，此时可使用原子变量。相比使用锁，原子变量性能更好。在竞争不激烈的状况下，原子变量的操做性能基本上和加锁的性能一致，可是在并发比较激烈的时候，等待锁的线程要进入等待队列等待从新调度，这里的挂起和从新调度过程须要上下文切换，浪费了更多的时间。

大部分编程语言都提供了基本变量对应的原子类型，通常提供set, get, compareAndSet等操做。

lock-free

lock-free这个概念来自

An algorithm is called non‐blocking if failure or suspension of any thread cannot cause failure or suspension of another thread; an algorithm is called lock‐free if, at each step, some thread can make progress.

non-blocking算法任何线程失败或者挂起，不会致使其余线程失败或者挂起，lock-free则进一步保证线程间无依赖。这个表述比较抽象，具体来讲，non-blocking要求不存在互斥，存在互斥的状况下，线程必须先获取锁再进入临界区，若是当前持有锁的线程被挂起，等待锁的线程必然须要一直等待下去。对于活锁或者饥饿的场景，线程失败或者挂起的时候，其余线程彻底不只能正常运行，说不定还解决了活锁和饥饿的问题，所以活锁和饥饿符合non-blocking，可是不符合lock-free。

实现一个lock-free数据结构并不容易，好在已经有了几种常见数据结构的的lock-free实现：buffer, list, stack, queue, map, deque，咱们直接拿来使用就好了。

优化对锁的使用

有时候没有条件使用lock-free，仍是得用锁，对于这种状况，仍是有一些优化手段的。首先使用尽可能减小临界区的大小，使用细粒度的锁，锁粒度越细，并行执行的效果越好。其次选择适合的锁，好比考虑选择读写锁。

CPU affinity

使用CPU affinity机制合理规划线程和CPU的绑定关系。前面提到使用CPU affinity机制，将多队列网卡的中断处理分散到多个CPU上。不只是中断处理，线程也能够绑定，绑定以后，线程只会运行在绑定的CPU上。为何要将线程绑定到CPU上呢？绑定CPU有这样几个好处:

• 为线程保留CPU，确保线程有足够的资源运行
• 提升CPU cache的命中率，某些对cache敏感的线程必须绑定到CPU上才行。
• 更精细的资源控制。能够预先须要静态划分各个工做线程的资源，例如为每一个请求处理线程分配一个CPU，其余后台线程共享一个CPU，工做线程和中断处理程序工做在不一样的CPU上。
• NUMA架构中，每一个CPU有本身的内存控制器和内存插槽，CPU访问本地内存别访问远程内存快3倍左右。使用affinity将线程绑定在CPU上，相关的数据也分配到CPU对应的本地内存上。

Linux上设置CPU affinity很简单，可使用命令行工具taskset，也能够在程序内直接调用API sched_getaffinity和sched_setaffinity.

其余优化技术

使用Hugepage

Linux中，程序内使用的内存地址是虚拟地址，并非内存的物理地址。为了简化虚拟地址到物理地址的映射，虚拟地址到物理地址的映射最小单位是“Page”，默认状况下，每一个页大小为4KB。CPU指令中出现的虚拟地址，为了读取内存中的数据，指令执行前要把虚拟地址转换成内存物理地址。Linux为每一个进程维护了一张虚拟地址到物理地址的映射表，CPU先查表找到虚拟地址对应的物理地址，再执行指令。因为映射表维护在内存中，CPU查表就要访问内存。相对CPU的速度来讲，内存实际上是至关慢的，通常来讲，CPU L1 Cache的访问速度在1ns左右，而一次内存访问须要60-100ns，比CPU执行一条指令要慢得多。若是每一个指令都要访问内存，好比严重拖慢CPU速度，为了解决这个问题，CPU引入了TLB(translation lookaside buffer)，一个高性能缓存，缓存映射表中一部分条目。转换地址时，先从TLB查找，没找到再读内存。

显然，最理想的状况是映射表可以彻底缓存到TLB中，地址转换彻底不须要访问内存。为了减小映射表大小，咱们可使用“HugePages”：大于4KB的内存页。默认HugePages是2MB，最大能够到1GB。

避免动态分配内存

内存分配是个复杂且耗时的操做，涉及空闲内存管理、分配策略的权衡（分配效率，碎片），尤为是在并发环境中，还要保证内存分配的线程安全。若是内存分配成为了应用瓶颈，能够尝试一些优化策略。好比内存复用i：不要重复分配内存，而是复用已经分配过的内存，在C++/Java里则考虑复用已有对象，这个技巧在Java里尤为重要，不只能下降对象建立的开销，还避免了大量建立对象致使的GC开销。另一个技巧是预先分配内存，实际上至关于在应用内实现了一套简单的内存管理，好比Memcached的Slab。

Zero Copy

对于一个Web服务器来讲，响应一个静态文件请求须要先将文件从磁盘读取到内存中，再发送到客户端。若是自信分析这个过程，会发现数据首先从磁盘读取到内核的页缓冲区，再从页缓冲区复制到Web服务器缓冲区，接着从Web服务器缓冲区发送到TCP发送缓冲区，最后经网卡发送出去。这个过程当中，数据先从内核复制到进程内，再从进程内回到内核，这两次复制彻底是多余的。Zero Copy就是相似状况的优化方案，数据直接在内核中完成处理，不须要额外的复制。

Linux中提供了几种ZeroCopy相关的技术，包括sendfile,splice,copy_file_range,Web服务器中常用sendfile优化性能。

最后

千万牢记：不要过早优化。

优化以前，先考虑两个问题：

1. 如今的性能是否已经知足需求了
2. 若是真的要优化，是否是已经定位了瓶颈

在回答清楚这两个问题以前，不要盲目动手。

---

本文做者：太公

阅读原文

本文为云栖社区原创内容，未经容许不得转载。