Redis · Event Loop Lab

五条连接已经醒来，主线程还是一次只做一件事

把业务连接送进就绪队列，然后逐步观察 Redis 如何读取请求、执行命令、写回响应。让一个命令故意变慢，你会看到后面的请求不是“并行赶工”，而是在队列里继续等。

I/O 多路复用负责同时观察许多连接，只把“有数据可读或可写”的连接交给事件循环；它省掉了“每个等待连接配一条线程”的成本，却没有把命令执行变成并行。

连接观察区

01 / WAIT

操作系统同时观察这些连接。连接没数据时，Redis 不需要让五条线程各自堵在读取操作上。

    已就绪队列

    02 / READY

    连接有数据可读后才进入这里。排在队首的请求获得下一次执行机会。

      单执行线程

      03 / EXECUTE

      事件循环一次只推进一个请求。手动运行时，每次点击推进一个阶段。

      等待就绪请求

      1. READ读取请求
      2. EXEC执行命令
      3. WRITE写回响应

      观察：主线程空闲。把连接加入就绪队列后开始运行。

      响应完成

      04 / DONE

      响应写回客户端后，请求离开本轮事件循环。

        CONNECTIONS ≠ THREADS

        等待连接不再占着线程

        连接是否可读由操作系统统一通知。Redis 可以管理大量连接，而不必为每条暂时无事可做的连接保留执行线程。

        READY ≠ RUNNING

        就绪只代表可以被处理

        连接进入就绪队列，并不等于命令已经开始。只有拿到唯一执行位，请求才会进入读取、执行和写回阶段。

        SLOW COMMAND = QUEUEING

        慢命令会放大排队时间

        一条命令长时间占据主线程，后面的请求即使命令本身很快，也只能等待。这正是生产环境要警惕大 Key 和重计算命令的原因。

        当前排队 0
        已经完成 0 / 5
        最长等待 0 ms

        事件循环记录

        1. 等待连接就绪。