Redis I/O：
从就绪到完成

四个因素一起工作

博客把 Redis 的速度归因于内存访问、高效数据结构、命令顺序执行，以及非阻塞 I/O + 多路复用。单线程只描述大部分命令的执行路径，不等于整个 Redis 进程只有一条线程。

顺序执行减少命令路径中的锁竞争、调度和上下文切换，也让单条命令不被另一条命令插入。但同一性质也形成队头阻塞：一个大 Key 或慢命令占住主线程，后续客户端都要等。

来源：src/content/blog/redis-interview/index.md，第 13-32 行

不要把“不等待”与“异步”混为一谈

接收网络数据可以拆成两个阶段：第一阶段等待数据进入内核 socket 缓冲区；第二阶段把数据交到用户缓冲区。同步非阻塞 I/O 只让第一阶段在未就绪时立即返回 EAGAIN，应用仍需反复查询，并亲自调用 recv() 完成第二阶段。

来源：src/content/blog/redis-interview/多路IO复用.md，第 14-59、83-102 行

复用的是等待者，不是数据通道

I/O 多路复用让一个线程只阻塞一次，同时等待一组 fd 中任意成员就绪。它避免应用不断逐个轮询所有 socket，也不要求“一连接一线程”。

epoll_wait()
  → 内核报告 fd3 ready
  → 用户线程 recv(fd3)
  → 数据进入用户缓冲区
  → recv() 返回

这里的分界点非常重要：epoll_wait() 交付的是“就绪事件”，不是已经读好的数据。应用收到事件后还必须调用 recv()，因此第二阶段仍由当前线程同步完成。

来源：src/content/blog/redis-interview/多路IO复用.md，第 61-81 行

三个机制的差别，抓住“每次都交什么”

select 的数量限制，先区分三个概念

glibc 默认的 fd_set 有 1024 位，能表示 fd 0-1023；这限制的是可放入集合的 fd 编号范围。nfds 应传三个集合中的最大 fd 编号加 1，它只是内核的扫描上界。一次调用实际监听的 socket 数量，则是集合中被置位的 socket fd 数量。

因此，“select 最多监听 1024 个 socket”只是一种不够严谨的简称。更准确的说法是：默认接口无法表示编号大于 1023 的 fd；进程可以拥有更多连接，只是不能把这些高编号 fd 交给这个 fd_set。

select 如何知道 fd 已就绪

Linux 内核先扫描集合中置位的 fd，查询每个 fd 对应对象当前是否满足可读、可写或异常条件。如果没有任何 fd 就绪且调用允许阻塞，内核会把当前任务挂到相关等待队列并让它睡眠；I/O 状态变化会唤醒任务，随后 select 再次扫描。

返回时，三个 fd_set 已被原地改写，只保留就绪的 fd。应用再用 FD_ISSET() 判断具体是哪几个。这里既不是用户态逐个调用 recv() 忙轮询，也不是内核执行用户态回调。

epoll_create1() 创建实例，epoll_ctl() 增删改关注的 fd，epoll_wait() 等待并返回一批就绪事件。它不是自动执行用户态回调，也不保证一次只返回一个 fd。

来源：src/content/blog/redis-interview/poll、select、epoll.md，select、poll 与 epoll 小节

LT 看状态，ET 看变化

LT（水平触发）在“仍然可读”这个条件持续成立时会继续通知；ET（边缘触发）只在状态变化时通知。ET 下若一次没读完，缓冲区依然处于可读状态，但没有新的边缘，应用可能等不到下一次通知。

收到 ET 可读事件
while true:
  n = read(nonblocking_fd)
  if n > 0: 处理数据，继续读
  if n == -1 and errno == EAGAIN: 本轮排空，停止
  if n == 0: 对端关闭

所以 ET 的配套纪律是：socket 设为非阻塞；每次事件到来后持续读取；直到 EAGAIN 明确表示当前已无数据。非阻塞保证循环不会在排空之后挂死。

来源：src/content/blog/redis-interview/poll、select、epoll.md，第 58-62 行；流程为基于该规则的教学性展开

最可靠的问题：Handler 拿到事件后还要不要 read？

Reactor 的路径是“注册 → 等待就绪 → 分发 → Handler 读写 → 业务处理”。Proactor 的路径是“提交异步 I/O → 系统完成 → 完成事件入队 → 分发 → Handler 处理现成结果”。

io_uring 使用提交队列与完成队列，模型上接近 Proactor；但博客也强调，普通 Tokio 网络 I/O 主要仍是就绪模型，不能把“Rust async 语法”自动等同于内核完成式 I/O。

来源：src/content/blog/redis-interview/Reactor 和 Proactor.md，第 14-52 行