网站策划专员WordPress电影评分模板

1 用户空间和内核空间

以Centos 7 linux操作系统为例。

计算机系统被内核操控， 内核被应用操控。

为了避免用户应用导致冲突甚至内核崩溃，用户应用与内核是分离的

• 进程的寻址空间会划分为两部分:内核空间、用户空间。

• 用户空间只能执行受限的命令(Rin3，最低级命令)，而且不能直接调用系统资源，必须通过内核提供的接口来访问，内核可以选择暴露哪些资源可以被用户访问。

• 内核空间可以执行特权命令 (Ring0，可以直接访问系统资源)，调用一切系统资源

以32位CPU为例，其内存空间为2的32次方，即4GB，将其分为内核空间和用户空间如下图所示

Linux系统为了提高IO效率，会在用户空间和内核空间加入缓冲区

在写数据时：要把用户的缓冲数据拷贝到内核缓冲区，然后写入到磁盘。

注意图中红箭头

写数据图

在读数据时：要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区。

注意图中黑色箭头，

• 用户向内核发起读数据的指令，如果数据还没到达则需要等待数据；

• 数据从网络中传输到磁盘，然后读取到内核态的缓冲区；

• 用户太将数据从内核缓冲区copy到自己的缓冲区。

读数据图

影响性能的点：
1、在读取数据时会发生阻塞
2、用户态和内核态缓冲区的拷贝会影响效率。

2 网络模型

2.1 阻塞IO(Blocking IO)

用户获取数据的过程，图的左半部分是应用的等待过程，右半部分是等待过程中内核做哪些

1. 内核等待磁盘准备数据

2. 内核将数据拷贝到用户太的缓存中。

可以看到，阻塞IO模型中，用户进程在两个阶段都是阻塞状态。

2.2 非阻塞IO （NonBlocking IO）

用户获取数据的过程，左半部分用户一直在循环尝试获取锁数据，右图部分内核在等待数据，然后将数据拷贝到用户空间中。

1. 在第一阶段，内核直接返回失败信息。

2. 在第二阶段，数据拷贝时用户需要阻塞。

可以看到，非阻塞10模型中，用户进程在第一个阶段是非阻塞，第二个阶段是阻塞状态。虽然是非阻塞，但性能并没有得到提高。而且忙等机制会导致CPU空转，CPU使用率暴增。

2.3 IO多路复用

无论是阻塞IO还是非阻塞IO，用户应用在一阶段都需要调用recvfrom函数，差别在于无数据时的处理

• 如果调用recvfrom时，恰好没有数据，阻塞10会使进程阻塞，非阻塞10使CPU空转，都不能充分发挥CPU的作用。

• 如果调用recvfrom时，恰好有数据，则用户进程可以直接进入第二阶段，读取并处理数据。

在阻塞IO的情况下，服务端处理客户端Socket请求时，在单线程的情况下，只能处理一个socket，如果正常处理的socket数据还没有准备就绪，线程就会被阻塞，其他客户端的socket都必须等待，性能很差。

提高效率的方法
1、开启多线程，同时处理多个socket。
2、不排队，当谁数据准备好了，cpu就去处理谁。

那么内核如何知道哪些socket数据已经准备就绪了呢？可以通过文件描述符知道!!!

文件描述符(File Descriptor)

文件描述符: 简称FD，是一个从0开始递增的无符号整数，用来关联Linux中的一个文件。在Linux一切皆文件，例如常规文件、视频、硬件设备等，当然也包括网络套接字 (Socket)。

IO多路复用 :是利用单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从而避免无效的等待，充分利用CPU资源。

用户进程调用select函数，监听多个sockets，然后内核态告知用户态哪些sockets的数据已经准备就绪，然后用户态调用recvfrom函数获取数据。

监听FD的方式、通知的方式又有多种实现

• select

• poll

• epoll

差异:

• select和poll只会通知用户进程有FD就绪，但不确定具体是哪个FD，需要用户进程逐个遍历FD来确认

• epoll则会在通知用户进程FD就绪的同时，把已就绪的FD写入用户空间。

综合对比epoll更占优势。

2.4 Select

select是Linux中最早的I/0多路复用实现方案

例如select 监督读事件的fd集合。

1.1 创建fd_set集合

1.2 监听fd = 1,2,5

1.3 切换到内核态，并将fd_set拷贝，然后执行select函数

2.1内核遍历集合

2.2查看准备就绪的fd，没有则休眠

2.3 等待数据就绪被唤醒或者超时。

2.4 将fd_set拷贝到用户态的中。

select模式存在的问题:

• 需要将整个fd_set从用户空间拷贝到内核空间，select结束还要再次拷贝回用户空间；

• select无法得知具体是哪个fd就绪，需要遍历整个fd_set；

• fd_set监听的fd数量不能超过1024。

2.5 Poll

poll模式对select模式做了简单改进，但性能提升不明显，部分关键代码如下

IO流程

• 创建pollfd数组，向其中添加关注的fd信息，数组大小自定义

• 调用poll函数，将pollfd数组拷贝到内核空间，转链表存储，无上限

• 内核遍历fd，判断是否就绪

• 数据就绪或超时后，拷贝pollfd数组到用户空间，返回就绪fd数量n

• 用户进程判断n是否大于0

• 大于0则遍历pollfd数组，找到就绪的fd

与select对比

• select模式中的fd set大小固定为1024，而pollfd在内核中采用链表，理论上无上限

• 监听FD越多，每次遍历消耗时间也越久，性能反而会下降

2.5 epoll

epoll模式是对select和poll的改进，它提供了三个函数

epoll_create：在内核中创建eventpoll结构体，返回对应的句柄epfd

epoll_ctl：将fd加入到红黑树上，如果数据准备就绪触发callback将其加入到就绪的list链表中

epoll_wait：检查rdlist列表是否为空，不为空则返回就绪的FD数量。

epoll流程图：

select模式存在的三个问题

• 能监听的FD最大不超过1024

• 每次select都需要把所有要监听的FD都拷贝到内核空间每次都要遍历所有FD来判断就绪状态

poll模式的问题:

• poll利用链表解决了select中监听FD上限的问题，但依然要遍历所有FD，如果监听较多，性能会下降

epoll模式中如何解决这些问题的?

• 基于epoll实例中的红黑树保存要监听的FD，理论上无上限，而且增删改查效率都非常高，性能不会随监听的FD数量增多而下降。

• 每个FD只需要执行一次epoll_ctl添加到红黑树，以后每次epol wait无需传递任何参数，无需重复拷贝FD到内核空间

• 内核会将就绪的FD直接拷贝到用户空间的指定位置，用户进程无需遍历所省FD就能知道就绪的FD是谁

2.6 信号驱动IO

信号驱动IO是与内核建立SIGIO的信号关联并设置回调，当内核有FD就绪就会通知用户，期间用户可以执行其他业务。

当有大量I0操作时，信号较多，SIGIO处理函数不能及时处理可能导致信号队列溢出而且内核空间与用户空间的频繁信号交互性能也较低。

2.7 异步IO

闲的闲死，累的累死。

同步和异步的区分：看第二阶段是阻塞还是非阻塞的。

3 Redis网络模型

Redis到底是单线程还是多线程？

• 如果仅考虑Redis的核心业务部分（命令处理），答案是单线程

• 如果考虑整个Redis，那么答案是多线程。

在Redis 6.0 ：核心网络模型引入了多线程。

为什么Redis作者选择单线程？

• 抛开持久化不谈，Redis是纯内存操作，执行速度非常快，它的性能瓶颈是网络延迟而不是执行速度，因此多线程并不会带来巨大的性能提升。

• 多线程会导致过多的上下文切换，带来不必要的开销

• 引入多线程会面临线程安全问题，必然要引入线程锁这样的安全手段，实现复杂度增高，而且性能也会大打折扣

3.1 单线程下的网络模型

Redis通过10多路复用来提高网络性能，并且支持各种不同的多路复用实现，并且将这些实现进行封装，提供了统一的高性能事件库API库AE:

源码：server.c