参考资料
:极客时间 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虽然比较理想,但是目前使用起来还有一些问题。