参考资料 ：极客时间 Redis（亚风）
前置知识
系统隔离
为了避免⽤户应⽤导致冲突甚⾄内核崩溃服务器托管网，⽤户应⽤与内核是分离的：
进程的寻址空间会划分为两部分：内核空间、⽤户空间
• ⽤户空间只能执⾏受限的命令（Ring3），⽽且不能直接调⽤系统资源，必
须通过内核提供的接⼝来访问
• 内核空间可以执⾏特权命令（Ring0)，调⽤⼀切系统资源
缓冲区
Linux系统为了提⾼IO效率，会在⽤户空间和内核空间都加⼊缓冲区：
• 写数据时，要把⽤户缓冲数据拷⻉到内核缓冲区，然后写⼊设备
• 读数据时，要从设备读取数据到内核缓冲区，然后拷⻉到⽤户缓冲区
这里的数据交互采用不同的模型就会有不同的性能，因而也诞生了一些网络IO模型。
IO模型
阻塞IO
非阻塞IO
⽆论是阻塞IO还服务器托管网是⾮阻塞IO，⽤户应⽤在⼀阶段都需要调⽤recvfrom来获取数据，差别在于⽆数据时的理⽅案：
• 如果调⽤recvfrom时，恰好没有数据，阻塞IO会使进程阻塞，⾮阻塞IO使CPU空转，都不能充分发挥CPU的作⽤。
• 如果调⽤recvfrom时，恰好有数据，则⽤户进程可以直接进⼊第⼆阶段，读取并处理数据。
IO多路复用
文件表述符的概念
⽂件描述符（File Descriptor）：简称FD，是⼀个从0开始递增的⽆符号整数，⽤来关联Linux中的⼀个⽂件。在Linux中，⼀切皆⽂件，例如常规⽂件、视频、硬件设备等，当然也包括⽹络套接字 (Socket)。
IO多路复⽤：是利⽤单个线程来同时监听多个FD，并在某个FD可读、可写时得到通知，从⽽避免⽆效的等待，充分利⽤CPU资源。
区间听FD有三种实现方式
1 select
Sekect的结构
typedef struct {
// ⻓度为 1024/32 = 32
// 共1024个bit位，每个bit位代表⼀个fd，0代表未就绪，1代表就绪
int fds_bits[__FD_SETSIZE / __NFDBITS]；
} fd_set；
// select函数，⽤于监听多个fd的集合
int select(
int nfds，//要监视的fd_set的最⼤fd + 1
fd_set *readfds, //要监听读事件的fd集合
fd_set *writefds, // 要监听写事件的fd集合
fd_set *exceptfds，// 要监听异常事件的fd集合
//超时时间，null-永不超时；0-不阻塞等待；⼤于0-固定等待时间
struct timeval *timeout);
select模式存在的问题：
• 需要将整个fd_set从⽤户空间拷⻉到内核空间，select结束还要再次拷⻉回⽤户空间
• select⽆法得知具体是哪个fd就绪，需要遍历整个fd_set
• fd_set监听的fd数量不能超过1024（因为32个int,每个int 4 * 8 32 位）总共1024位。
2 poll
#define POLLIN //可读事件
#define POLLOUT //可写事件
#define POLLERR //错误事件
// pollfd结构
struct pollfd {
int fd; //要监听的fd
short int events；/*要监听的事件类型：读、写、异常*/
short int revents;/* 实际发⽣的事件类型*/
}；
// poll函数
int poll(
struct pollfd *fds，// pollfd数组，可以⾃定义⼤⼩
nfds_t nfds, //数组元素个数
int timeout) // 超时时间
1 ） 创建pollfd数组，向其中添加关注的fd信息
2 ）调⽤poll函数，将pollfd数组拷⻉到内核空间，转链表存储（内核要求转换为链表）
3 ）内核遍历fd，判断是否就绪
4 ）数据就绪或超时后，拷⻉pollfd数组到⽤户空间，返回就绪fd数量n
5 ）判断n是否⼤于0，⼤于0则遍历pollfd数组，找到就绪的fd
与select对⽐：
整体过程和Select大同小异。结构优化了一些，但是还是需要遍历fd_set.
select模式中的fd_set⼤⼩固定为1024，⽽pollfd⽆上限，监听FD越多，每次遍历消耗时间也越久，性能反⽽会下降。
3 epoll
struct eventpoll {
struct rb_root rbr；//红⿊树，记录要监听的FD
struct list_head rdlist;// 链表，记录就绪的FD
}；
//1.会在内核创建eventpoll结构体，返回对应的句柄epfd
int epoll_create(int size)；
//2.将⼀个FD添加到epoll的红⿊树中，并设置ep_poll_callback
// callback触发时，就把对应的FD加⼊到rdlist这个就绪列表中
int epoll_ctl(
int epfd, // epoll实例的句柄
int op, //要执⾏的操作，包括：ADD、 MOD、 DEL
int fd，//要监听的FD
struct epoll_event *event // 要监听的事件类型：读、写、异常等
)；
//3.循环检查rdlist列表是否为空，不为空则返回就绪的FD的数量
int epoll_wait(
int epfd,
struct epoll_event *events, //event数组，⽤于接收就绪的FD 属于用户空间
int maxevents, // events数组的最⼤⻓度
int timeout //超时时间，-1不超时；0不阻塞；⼤于0为阻塞时间)；
)
具体流程：
三种模式的对比：
select模式存在的三个问题：
• 能监听的FD最⼤不超过1024
• 每次select都需要把所有要监听的FD都拷⻉到内核
• 每次都要遍历所有FD来判断就绪状态
poll模式的问题：
• poll利⽤链表解决了select中监听FD上限的问题，但依然要遍历所有FD，如
果监听较多，性能会下降
epoll模式中如何解决这些问题的？
• 基于epoll实例中的红⿊树保存要监听的FD，增删改查效率⾮常⾼
• 每个FD只需要执⾏⼀次epollctl添加到红⿊树，⽆需重复拷⻉FD到内核空间
• 内核会将就绪的FD直接拷⻉到⽤户空间的指定位置，⽤户进程⽆需遍历所有FD就能知道就绪的FD是谁当FD有数据可读时，我们调⽤epollwait就可以得到通知。但是事件通知的模式
有两种：
LevelTriggered：简称LT。当FD有数据可读时，会重复通知多次，直⾄数据处理完成。是Epoll的默认模式。
EdgeTriggered：简称ET。当FD有数据可读时，只会被通知⼀次，不管数据是否处理完成。
ET模式避免了LT模式可能出现的惊群现象(就比如有多个进程监听了FD，这个FD一旦通知就会唤醒所有的进程，但是实际只需要一个进程来处理。)
ET模式最好结合⾮阻塞IO读取FD数据，相⽐LT会复杂。
信号驱动IO
信号驱动IO是与内核建⽴SIGIO的信号关联并设置回调，当內核有FD就绪时，会发出SIGIO信号通知⽤户，期间⽤户应⽤可以执⾏其它业务，⽆需阻塞等待。
存在的问题：当有⼤量lO操作时，信号较多，SIGlO处理函数不能及时处理可能导致信号队列溢出，⽽且内核空间与⽤户空间的频繁信号交互性能也较低。
AIO（异步IO）
AIO的整个过程都是⾮阻塞的，⽤户进程调⽤完异步API后就可以去做其它事情，内核等待数据就绪并拷⻉到⽤户空间后才会递交信号，通知⽤户进程。
IO操作是同步还是异步，关键看数据在内核空间与⽤户空间的拷⻉过程（数据读写的IO操作）
总结在Redis里面采用了IO多路复用，具体是epoll这种模式来实现。后面的信号IO 和 AIO虽然比较理想，但是目前使用起来还有一些问题。
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
MyBatis中文网：https://mybatis.net.cn/ 1 什么是 MyBatis？ MyBatis 是一款优秀的持久层框架，它支持自定义 SQL、存储过程以及高级映射。MyBatis 免除了几乎所有的 JDBC 代码以及设置参数和获取结果集的工…
