事件循环：Python / JS / Redis 都在用，是一回事吗？

事件循环 = 非阻塞 I/O + I/O 多路复用 + Reactor 设计模式 + 用户态协作式调度。四块拼起来才完整，缺任何一块都不成立：

# 一切事件循环的伪代码骨架
while not stopped:
    1. timeout = 计算下一个定时器还有多久到期   # 不能因为等 I/O 而误了定时任务
    2. events = multiplexer.wait(timeout)        # epoll_wait / kevent：阻塞在此，直到有 fd 就绪或超时
    3. for ev in events:                          # 把就绪事件转成「待办」
            ready_queue.push(handlers[ev.fd])
    4. for h in due_timers: ready_queue.push(h)  # 到期的定时器也进待办
    5. while ready_queue: ready_queue.pop().run() # 串行执行，遇阻塞点就交还控制权

Python 的事件循环是 asyncio 标准库提供的（_asyncio 有 C 加速实现）。它不是语言内置的——你不主动拿就没有：asyncio.run(coro) 内部会创建/获取一个事件循环，然后 run_forever()。

它的核心只有三样数据结构：

• _ready（collections.deque）：就绪回调队列，本轮要执行的回调都在这里。
• _scheduled（heapq 最小堆）：定时任务，按到期时间排序，用于计算 selector 的 timeout。
• _selector（selectors 模块）：I/O 多路复用封装，Linux 用 epoll、macOS 用 kqueue。

# asyncio/base_events.py —— _run_once() 骨架（高度简化，保留真实结构）
def _run_once(self):
    # 1. 到期的定时器从堆里弹出，塞进就绪队列
    end_time = self.time() + self._clock_resolution
    while self._scheduled and self._scheduled[0]._when < end_time:
        handle = heapq.heappop(self._scheduled)
        self._ready.append(handle)

    # 2. 算 selector 的阻塞超时：不能因为等 I/O 而耽误定时器
    timeout = 0 if self._ready else None
    if timeout is None and self._scheduled:
        timeout = min(max(0, self._scheduled[0]._when - self.time()),
                      MAXIMUM_SELECT_TIMEOUT)

    # 3. 阻塞在 I/O 多路复用上（唯一的"等"）
    event_list = self._selector.select(timeout)

    # 4. I/O 就绪 → 对应回调进就绪队列
    self._process_events(event_list)

    # 5. 执行本轮就绪回调（先快照长度，防止队列被无限追加）
    ntodo = len(self._ready)
    for _ in range(ntodo):
        self._ready.popleft()._run()

JS 的事件循环不在 ECMAScript 语言规范里，而是由宿主环境定义：浏览器按 HTML 规范实现一套，Node.js 用 C 库 libuv 实现另一套。两者共有的核心语义是宏任务 + 微任务。

// 经典执行顺序题：为什么是 1 2 3 5？
console.log('1 sync');
setTimeout(() => console.log('5 macrotask'), 0);   // 宏任务，最后
Promise.resolve().then(() => console.log('3 microtask'));  // 微任务，先
console.log('2 sync');
// 输出：1 sync → 2 sync → 3 microtask → 5 macrotask
// 原因：同步代码跑完 → 清空微任务 → 才取下一个宏任务

// Node 特有：nextTick 优先级高于 Promise 微任务
process.nextTick(() => console.log('A nextTick'));    // 最先
Promise.resolve().then(() => console.log('B promise'));  // 次之
setImmediate(() => console.log('C immediate'));        // check 阶段
setTimeout(() => console.log('D timeout'), 0);         // timers 阶段
// 输出：A → B → D / C（后两者顺序在主模块中不保证）

Redis 没有用 libevent / libuv，而是自己写了一个极简事件库 ae.c（约 500 行），用策略模式在编译期选择后端：ae_evport.c（Solaris）→ ae_epoll.c（Linux）→ ae_kqueue.c（macOS/BSD）→ ae_select.c（兜底）。上层只调统一的 aeApiPoll()。

它只有两类事件：

• 文件事件（aeFileEvent）：socket 可读 / 可写。如 acceptTcpHandler（新连接）、readQueryFromClient（读命令）、sendReplyToClient（写响应）。
• 时间事件（aeTimeEvent）：定时任务，用单链表存（数量少，遍历比维护堆更省）。最重要的是 serverCron，默认每秒运行 hz 次（默认 10，高连接时自适应提到 500），负责过期键清理、统计更新、增量 rehash、持久化触发、复制心跳等。

// ae.c —— 主循环与事件处理（简化，保留真实结构）
void aeMain(aeEventLoop *eventLoop) {
    eventLoop->stop = 0;
    while (!eventLoop->stop) {
        aeProcessEvents(eventLoop,
            AE_ALL_EVENTS | AE_CALL_BEFORE_SLEEP | AE_CALL_AFTER_SLEEP);
    }
}

int aeProcessEvents(aeEventLoop *eventLoop, int flags) {
    // 1. 计算最近一个时间事件还有多久 → 作为 poll 的超时
    shortest = 最近时间事件剩余毫秒数;

    // 2. beforeSleep：回复缓冲区刷盘、AOF flush、lazyfree、整理待写客户端
    if (eventLoop->beforesleep && flags & AE_CALL_BEFORE_SLEEP)
        eventLoop->beforesleep(eventLoop);

    // 3. 阻塞等 I/O：epoll_wait / kevent / select
    numevents = aeApiPoll(eventLoop, tvp);

    // 4. afterSleep（Redis 6.0+：唤醒 I/O 线程并行读写 socket）
    if (eventLoop->aftersleep && flags & AE_CALL_AFTER_SLEEP)
        eventLoop->aftersleep(eventLoop);

    // 5. 分发就绪的文件事件
    for (j = 0; j < numevents; j++) {
        fe = &eventLoop->events[eventLoop->fired[j].fd];
        mask = eventLoop->fired[j].mask;
        if (fe->mask & mask & AE_READABLE)  fe->rfileProc(eventLoop, fd, fe->clientData, mask);
        if (fe->mask & mask & AE_WRITABLE)  fe->wfileProc(eventLoop, fd, fe->clientData, mask);
    }

    // 6. 处理到期的时间事件（serverCron 等）
    if (flags & AE_TIME_EVENTS) processed += processTimeEvents(eventLoop);
    return processed;
}

各模型的典型坑