本⽂以爱奇艺开源的⽹络协程库(https://github.com/iqiyi/libfiber )为例,讲解⽹络协程的设计原理、编程实践、性能优化等⽅⾯内容。
早年间,支持多个用户并发访问的服务应用,往往采用多进程方式,即针对每一个TCP网络连接创建一个服务进程。在2000年左右,比较流行使用CGI方式编写Web服务,当时人们用的比较多的Web服务器模式开发的Apache1.3.x系列,因为进程占用系统资源比较多,所以人们开始使用多线程方式编写web应用程序,线程占用的资源更少,这样使得单台服务器支撑的用户并发度提高了,但依然存在资源浪费问题。因为在多进程或者多线程编程方式下,均采用了阻塞通信方式,对于慢连接请求,会使得服务器的进程或者线程因【等待】客户端的请求数据而不能做别的事情,白白浪费了操作系统的调度时间和系统资源。这种一对一服务服务方式在广域网的环境下显示变得不够廉价,于是人们开始采用非阻塞网络编程方式来提升服务器网络并发度,比较著名的Web服务器Nginx就是非阻塞通信服务的典型代表。
⾮阻塞⽹络编程⼀直以⾼并发和⾼难度⽽著称,这种编程⽅式虽然有效的提升了服务器的利⽤率和处理能力,但却对⼴⼤程序员提出了较⼤挑战,因为⾮阻塞 IO 的编程⽅式往往会把业务逻辑分隔的⽀离破碎,需要在通信过程中记录⼤量的中间状态,⽽且还需要处理各种异常情况,最终带来的后果就是开发周期⻓、复杂度⾼,⽽且难于维护。
阻塞式⽹络编程实现容易但并发度不⾼,⾮阻塞⽹络编程并发度⾼但编写难,针对这两种⽹络编程⽅式的优缺点,⼈们提出了使⽤协程⽅式编写⽹络程序的思想。其实协程本身并不是⼀个新概念,早在2000年前Windows NT 上就出现了『纤程』的 API,号称可以创建成千上万个纤程来处理业务,在 BSD Unix 上可以⽤来实现协程切换的 API
Russ Cox 早在 2002 年就编写了⼀个简单的⽹络协程库 libtask(https://swtch.com/libtask/ ),代码量不多,却可以使我们⽐较清晰地看到『通过使⽹络 IO 协程化,使编写⾼并发⽹络程序变得如此简单』。
网络协程的本质就是将应用层的阻塞式IO过程在底层转换成非阻塞IO过程,并通过程序运行栈的上下文切换使IO准备就绪的协程交替运行,从而达到以简单方式编写高并发网络程序的目的。既然网络协程的底层也是非阻塞IO过程,所以在介绍⽹络协程基本原理前,我们先了解⼀下⾮阻塞⽹络通信的基本过程.
下面给出了非阻塞网络编程的常见设计模式:
在了解使⽤协程编写⽹络程序之前,需要先了解⼏个概念:
既然操作系统进行任务调度的最小单元是线程,所以操作系统无法感知协程的存在,自然也就无法对其进行调度;因此,存在于线程中的大量协程需要相互协作,合理的占用CPU时间片,在合适的运行点(比如网络阻塞点)主动让出CPU,给其他协程提供运行的机会,这也正是【协程这一概念的由来】。每个协程一般都会经历如下过程:
协程之间的切换⼀般可分为『星形切换』和『环形切换』,参照下图:
当有大量的协程需要运行时,在【环形切换】模式下,前一个协程运行完毕后直接【唤醒】并切换到下一个协程,而无需像【星形切换】那样先切换到调度原点,再从调度原点来【唤醒】下一个协程;因为『环形切换』比『星型切换』节省了⼀次上下⽂的切换过程,所以『环形切换』⽅式的切换效率更⾼。
在网络协程库中,内部由一个缺省的IO调度协程,其负责处理与网络IO相关的协程调度过程,故称为IO调度协程:
下⾯给出⼀个使⽤协程⽅式编写的⽹络服务器程序
该⽹络协程服务器程序处理流程为:
从该例⼦可以看出,⽹络协程的处理过程都是顺序⽅式,⽐较符合⼈的思维习惯;我们很容易将该例⼦改成线程⽅式,处理逻辑和协程⽅式相似,但协程⽅式更加轻量、占⽤资源更少,并发能⼒更强。
简单的表⾯必定隐藏着复杂的底层设计,因为⽹络协程过程在底层还是需要转为『⾮阻塞』处理过程,只是使⽤者并未感知⽽已。
在介绍了⽹络协程的基本原理后,本章节主要介绍 libfiber ⽹络协程的核⼼设计要点,为⽹络协程应⽤实践化提供了基本的设计思路。
libfiber采用了单线程调度方式,主要是为了避免设计上的复杂度和效率上的影响。
如果设计成多线程调度模式,则必须首先考虑如下几点:
当然,设计成单线程调度也需要解决如下问题:
libfiber的事件引擎支持当今主流的操作系统,从而为 libfiber 的跨平台特性提供了有⼒的⽀撑,下⾯为 libfiber 事件引擎所⽀持的平台:
⼤家在谈论⽹络协程程序的运⾏效率时,往往只重视协程的切换效率,却忽视了事件引擎对于性能影响的重要性,虽然现在基本上⽹络协程库所采⽤的事件引擎都是内核级的,但仍需要合理使⽤才能发挥其最佳性能
在使⽤ libfiber 的早期版本编译⽹络协程服务程序时,虽然在 Linux 平台上也是采⽤了 epoll 事件引擎,但在对⽹络协程服务程序进⾏性能压测(使⽤⽤系统命令 『# perf top -p pid』 观察运⾏状态)时,却发现 epoll_ctl API 占⽤了较⾼的 CPU,分析原因是 epoll_ctl 使⽤次数过多导致的:因为 epoll_ctl 内部在对套接字句柄进⾏添加、修改或删除事件操作时,需要先通过红⿊树的查找算法找到其对应的内部套接字对象(红⿊树的查找效率并不是O (1)的),如果 epoll_ctl 的调⽤次数过多必然会造成 CPU 的占⽤较⾼。
因为 TCP 数据在传输时是流式的,这就意味着数据接收者经常需要多次读操作才能获得完整的数据,反映到⽹络协程处理流程上,如下图所示:
仔细观察上⾯处理流程,可以发现在图中的标注4(唤醒协程)和标注5(挂起协程)之间的两个事件操作:标注2取消读事件 与 标注3注册读事件,再结合 标注1注册读事件,完全可以把注2和标注3处的两个事件取消,因为标注1⾄标注3的⽬标是 注册读事件。最后,通过缓存事件操作的中间状态,合并中间态的事件操作过程,使 libfiber 的 IO 处理性能提升 20% 左右。
下图给出了采⽤ libfiber 编写的回显服务器与采⽤其它⽹络协程库编写的回显服务器的性能对⽐(对⽐单核条件下的 IO 处理能⼒):
在libfiber中之所以可以针对中间的事件操作过程进行合并处理,主要是因为libfiber的调度过程是单线程模式的,如果想要在多线程调度器中合并中间态的实践操作要难很多:在多线程调度过程中,当套接字所绑定的协程因IO可读被唤醒时,假设不取消该套接字的读事件,则该协程被某个线程『拿⾛』后,恰巧该套接字又收到新数据,内核会再次触发事件引擎,协程调度器被唤醒,此时协程调度器也许就不知该如何处理了。
对于象 libfiber 这样的采⽤单线程调度⽅案的协程库⽽⾔,如果互斥加锁过程仅限于同⼀个调度线程内部,则实现⼀个协程互斥锁是⽐较容易的,下图为 libfiber 中单线程内部使⽤的协程互斥锁的处理流程图(参考源⽂件:fiber_lock.c):
同一线程内的协程在等待锁资源时,该协程将被挂起并被加入锁等待队列中,当加锁协程解锁后会唤醒锁等待队列中的头部协程,单线程内部的协程互斥锁正是利用了协程的挂起和唤醒机制。
虽然libfiber的协程调度器是单线程模式的,但可以启动多个线程使每个线程运行独立的协程调度器,如果一些资源需要在多个线程中的协程间共享,则就需要有⼀把可以跨线程使⽤的协程互斥锁。将 libfiber 应⽤在多线程的简单场景时,直接使⽤系统提供的线程锁就可以解决很多问题,但线程锁当遇到如下场景时就显得⽆能为⼒:
上述显示了系统线程互斥锁在libfiber多线程使用场景中遇到的死锁问题:
当线程A中的协程A2 要对线程锁2加锁⽽阻塞时,则会使线程A的协程调度器阻塞,从⽽导致线程A中的所有协程因宿主线程A被操作系统挂起而停止运行,同样,线程B 也会因协程B1 阻塞在线程锁1上⽽被阻塞,最终造成了死锁问题。
使用系统线程锁时产生上述死锁的根本原因是单线程调度机制以及操作系统的最小调度单元是线程,系统对协程是无感知的。因此,在 libfiber 中专⻔设计了可⽤于在线程的协程之间使⽤的事件互斥锁(源码参⻅ fiber_event.c),其设计原理如下:
该可用于在线程之间的协程进行互斥的事件互斥锁的处理流程为:
在上面事件锁的加/解锁处理过程中,使用原子锁和IO管道的好处是:
在使⽤线程编程时,都知道线程条件变量的价值:在线程之间传递消息时往往需要组合线程条件变量和线程锁。因此,在 libfiber 中也设计了协程条件变量(源码⻅ fiber_cond.c),通过组合使⽤ libfiber 中的协程事件锁(fiber_event.c)和协程条件变量,⽤户便可以编写出⽤于在线程之间、线程与协程之间、线程内的协程之间、线程间的协程之间进⾏消息传递的消息队列。下图为使⽤ libfiber 中协程条件变量时的交互过程:
这是⼀个典型的 ⽣产者-消费者 问题,通过组合使⽤协程条件变量和事件锁可以轻松实现。
使⽤⽹络协程库编写的⽹络服务很容易实现⾼并发功能,可以接⼊⼤量的客户端连接,但是后台系统(如:数据库)却未必能⽀持⾼并发,即使是⽀持⾼并的缓存系统(如 Redis),当网络连接数比较⾼时性能也会下降,所以协程服务模块不能将前端的并发压⼒传递到后端,给后台系统造成很⼤压⼒,我们需要提供⼀种⾼并发连接卸载机制,以保证后台系统可以平稳地运⾏,在 libfiber 中提供了协程信号量(源码⻅:fiber_semc.c)。
下⾯是使⽤ libfiber 中的协程信号量对于后台系统的并发连接进行卸载保护的示意图:
当有大量协程需要访问后台系统时,通过协程信号量将大量的协程【挡在外面】,只允许部分协程与后端系统建立连接。
注:⽬前 libfiber 的协程信号量仅⽤在同⼀线程内部,还不能跨线程使⽤,要想在多线程环境中使⽤,需在每个线程内部创建独⽴的协程信号量。
网络协程既然面向网络应用场景,自然离不开域名的协程化支持,现在很多网络协程库的设计者往往忽略了这一点,有些网络协程库在使用系统API进行域名解析时为了防止阻塞协程调度器,将域名解析过程(即调⽤gethostbyname/getaddrinfo 等系统 API)扔给独立的线程去支持,当域名解析并发量较大时必然会造成很多线程资源被占用。
在libfiber中集成了第三方的dns源码,实现了域名解析过程的协程化,占用更低的系统资源,基本满⾜了⼤部分服务端应⽤系统对于域名解析的需求。
在网络协程广泛使用前,很多网络库很早就存在了,并且不部分这些网络库都是阻塞式的,要改造这些网络库使之协程化的成本是非常具有的,我们不可能采用协程方式将这些网络库重新实现一般,目前一个广泛采用的方案时hook与io以及网络相关的系统中API,在 Unix 平台上 Hook 系统 API 相对简单,在初始化时,先加载并保留系统 API 的原始地址,然后编写⼀个与系统 API 函数名相同且参数也相同的函数,将这段代码与应⽤代码⼀起编译,则编译器会优先使⽤这些 Hooked API,下⾯的代码给出了在 Unix 平台上 Hook 系统 API 的简单示例:
在 libfiber 中Hook 了⼤部分与 IO 及⽹络相关的系统 API,下⾯列出 libfiber 所 Hook 的系统 API:
IO 相关 API
⽹络相关 API
通过 Hook API ⽅式,libfiber 已经可以使 Mysql 客户端库、⼀些 HTTP 通信库及 Redis 客户端库的⽹络通信协程化,这样在使⽤⽹络协程编写服务端应⽤程序时,⼤⼤降低了编程复杂度及改造成本。
为了使爱奇艺用户可以快速流畅地观看视频内容,就需要 CDN 系统尽量将数据缓存在 CDN 边缘节点,使用户就近访问,但因为边缘节点的存储容量有限、数据淘汰等原因,总会有一些数据在边缘节点不存在,当用户访问这些数据时,便需要回源软件去源站请求数据并下载到本地,在爱奇艺自建 CDN 系统中此回源软件的名字为『奇迅』,相对于一些开源的回源缓存软件(如:Squid,Apache Traffic,Nginx 等),『奇迅』需要解决以下问题:
下面为爱奇艺自研缓存与回源软件『奇迅』的软件架构及特点描述:
在爱奇艺的自建 CDN 系统中,作为数据回源及本地缓存的核心软件,奇迅承担了重要角色,该模块采用多线程多协程的软件架构设计,如下所示奇迅回源架构设计的特点总结如下:
特性说明:
奇迅的前后端通信模块均采用网络协程方式,分为前端连接接入层和后端下载任务层,为了有效地使用多核,前后端模块均启动多个线程(每个线程运行一个独立的协程调度器);
对于前端连接接入模块,由于采用协程方式,所以:
对于后端下载模块,由于采用协程方式,所以
采用协程方式编写的回源与缓存软件『奇迅』上线后,爱奇艺自建CDN视频卡顿比小于 2%,CDN 视频回源带宽小于 1%。
随着爱奇艺用户规模的迅速壮大,对于像 DNS 服务这样非常重要的基础设施的要求也越来越高,开源软件(如:Bind)已经远远不能满足要求,下面是项目初期对于自研 DNS 系统的基本要求:
下面是爱奇艺自研 DNS 的软件架构及特点介绍:
爱奇艺自研的高性能 DNS 的单机处理能力(非 DPDK 版本)可以达到 200 万次/秒以上;将业务域名变更后的信息同步至全网自建 DNS 节点可以在一分钟内完成。