深度解析:为什么高并发网关最终选择了C+epoll,而不是Goroutine或协程?
引子:一个让很多开发者困惑的问题在技术社区里,经常能看到这样的争论:“Go的goroutine不香吗?为什么还要用C语言写epoll?”、“协程不是更简单吗?为什么要手写状态机?”这些问题背后,其实隐藏着一个更深层的追问:当我们在选择并发模型时,我们到底在选什么?本文试图从技术底层出发,拆解epoll、Goroutine、协程这三种并发方案的本质差异,以及"语言运行时"这个常被忽略的变量,如何成为架构决策中的关键砝码。一、epoll的本质:操作系统内核的"事件通知机制"1.1 epoll解决了什么问题?epoll是Linux内核提供的I/O多路复用机制。它的核心价值在于:让一个线程能够同时监控成千上万个文件描述符(fd)的I/O事件,且只在有事件发生时才被唤醒。从数据结构角度看,epoll在内核中维护了两个核心结构:红黑树(rbtree):存储所有被监控的fd,增删改查的时间复杂度为O(log n)就绪链表(rdlist):存储已就绪的fd,epoll_wait直接返回此链表,时间复杂度O(1)对比select/poll的O(n)遍历机制,epoll在大规模连接场景下的性能优势是指数级的。