运营研发团队程序媛 张晶晶
背景
1.最近研究redis关于主从复制的功能实现，发现客户端实时响应slaveof的命令后，把主从复制添加到epoll的时间事件中再进行操作。因此有疑问，redis是如何进行文件和时间事件的调度
2.go的一大特点就是从语言方面支持协程，提供系统的并发性，那么go语言中是否还需要epoll这种事件驱动模型
基于以上两个疑问，我进行了事件驱动模型的研究和分析
分析
先明确一点：事件驱动模型的本质是单线程的，因为想要同时处理多个请求，我们需要换成事件模型的方式重构代码
1.最简单的模型是单线程
bind()
listen()
while(1) {
accept() //接收新连接
handle() //处理消息
}
当多个客户端请求时只能一个个处理，只要等到当前连接结束，才能处理下一个连接。这种方式处理效率低下，怎么提高处理效率呢，有两种方法：多线程处理，或者一个线程处理多个连接
2.多线程
bind()
listen()
while(1) {
accept()
pthread_create()
}
这样就可以同时处理多个请求。但是这种方式有几个不好的地方，
cpu和内存消耗，上下文切换
线程安全问题
问题定位难等
对于第一个问题，在程序中进行速率的限制，防止客户端无限链接->线程池
3.事件驱动模型
除了线程池，还可以采用非阻塞式IO，通过fcntl设置套接字。这种方式只能通过不断的轮询来检查是否有请求数据到来。
操作系统应该是知道哪个套接字是准备好了数据的，因此没必要逐个扫描。
select
想想一个线程，有一堆的任务要处理，应该监视哪些东西呢，两种类型的套接字活动：
1.accept
2.读写事件
尽管这两种活动在本质上有所区别，我们还是要把它们放在一个循环里，因为只能有一个主循环。循环会包含 select 的调用。这个 select 的调用会监视上述的两种活动。
while(1) {
int nready = select(fdset_max + 1, &readfds, &writefds, NULL, NULL); // 获取事件的个数
//遍历fd
for (fd = 0; fd <= fdset_max && nready > 0; fd++) {
// Check if this fd became readable.
if (FD_ISSET(fd, &readfds)) { //是否为读事件
nready--;
if (fd == listener_sockfd) { //是否为请请求到来
fd_status_t status =
on_peer_connected(newsockfd, &peer_addr, peer_addr_len);
if (status.want_read) { //是否有读事件
FD_SET(newsockfd, &readfds_master);
} else {
FD_CLR(newsockfd, &readfds_master);
}
if (status.want_write) { //是否有写事件
FD_SET(newsockfd, &writefds_master);
} else {
FD_CLR(newsockfd, &writefds_master);
}
}
} else {
fd_status_t status = on_peer_ready_recv(fd);//接收数据
if (status.want_read) {
FD_SET(fd, &readfds_master);
} else {
FD_CLR(fd, &readfds_master);
}
if (status.want_write) {
FD_SET(fd, &writefds_master);
} else {
FD_CLR(fd, &writefds_master);
}
}
}
if (FD_ISSET(fd, &writefds)){ //是否有写事件
//
write()// 发送消息
...
}
}
流程图的处理从图一变成了图二
select 方法会返回需要处理的事件的个数，然后遍历所有的fd去处理。
但是这种方法依然是有缺陷，第一既然知道了事件的个数，可不可以知道事件是发生在哪个fd上。不然每次都需要遍历所有的fd，限制性能。
此外，FD_SETSIZE是一个编译期常数，在如今的操作系统中，它的值通常是 1024。它被硬编码在 glibc 的头文件里，并且不容易修改。它把 select 能够监视的文件描述符的数量限制在 1024 以内。曾有些人想要写出能够处理上万个并发访问的客户端请求的服务器，所以这个问题很有现实意义。
epoll
epoll 高效的关键之处在于它与内核更好的协作。epoll_wait 用当前准备好的事件填满一个缓冲区。只有准备好的事件添加到了缓冲区，因此没有必要遍历客户端中当前所有 监视的文件描述符。这简化了查找就绪的描述符的过程，把空间复杂度从 select 中的 O(N) 变为了 O(1)。
while(1){
int nready = epoll_wait(epollfd, events, MAXFDS, -1);
for ( int i = 0; i < nready; i++) {
...
}
}
要在 select 里面重新遍历，有明显的差异：如果在监视着 1000 个描述符，只有两个就绪， epoll_waits 返回的是 nready=2，然后修改 events 缓冲区最前面的两个元素，因此我们只需要“遍历”两个描述符。用 select 我们就需要遍历 1000 个描述符，找出哪个是就绪的。因此，在繁忙的服务器上，有许多活跃的套接字时 epoll 比 select 更加容易扩展。
redis为什么要实现自己的事件库？
Redis 并没有使用 libuv，或者任何类似的事件库，而是它去实现自己的事件库 —— ae，用 ae 来封装 epoll、kqueue 和 select。事实上，Antirez(Redis 的创建者)恰好在 2011 年的一篇文章http://oldblog.antirez.com/po... 中回答了这个问题。他的回答的要点是：ae 只有大约 770 行他理解的非常透彻的代码；而 libuv 代码量非常巨大，也没有提供 Redis 所需的额外功能。
epoll 实现
一颗红黑树，一张准备就绪fd链表，少量的内核cache，就帮我们解决了大并发下的fd(socket)处理问题。
1.执行epoll_create时，创建了红黑树和就绪list链表。
2.执行epoll_ctl时，如果增加fd(socket)，则检查在红黑树中是否存在，存在立即返回，不存在则添加到红黑树上，然后向内核注册回调函数，用于当中断事件来临时向准备就绪list链表中插入数据。
3.执行epoll_wait时立刻返回准备就绪链表里的数据即可
又来一个问题，为什么epoll选择红黑树问不是其它avl树,mysql 选择b+树
为什么不用 AVL 树作为底层实现, 那是因为 AVL 树是高度平衡的树, 而每一次对树的修改, 都要 rebalance, 这里的开销会比红黑树大. 红黑树插入只要两次旋转, 删除至多三次旋转. 但不可否认的是, AVL 树搜索的效率是非常稳定的. 选取红黑树, 是一种折中的方案
B+树是为磁盘或其他直接存取的辅助存储设备而设计的一种数据结构。mysql为什么选取B+树，本质上是因为mysql数据是存放在外部存储的
go是否需要epoll
因为协程的高效，在go中处理多客户端请求，只需要如下这样写即可
for{
accept()
go handle()
}
是否需要epoll的编程模型呢，在一篇帖子中写到
go中怎么找不到像epoll或者iocp这种编程模型
答案很简单：goroutine底层用的非阻塞+epoll，所以你可以用同步的方式写出异
步的程序。
验证需要查看goroutine的底层实现。(大概率是正确的，这就是go语言的优势所在)
有疑问加站长微信联系(非本文作者)
285
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
