Redis 在选择 poll 和 epoll 时主要基于性能需求、连接规模、操作系统支持等因素。以下是具体场景的对比与选择建议：

---

1. 何时使用 poll 函数？

• 适用场景：

  • 跨平台兼容性需求：poll 在几乎所有操作系统（如 Windows、BSD、Linux）中均支持，而 epoll 仅限 Linux。
  • 少量并发连接：当连接数较少（如几百个）时，poll 的线性扫描（O(n)）开销可接受，且实现简单。
  • 非性能关键场景：如内部工具或低负载服务，无需追求极致性能。

• 设计原因：

  • poll 通过动态数组（pollfd）存储文件描述符（FD），无数量限制（select 默认仅支持 1024 个 FD），但每次调用需全量遍历 FD 集合，性能随连接数线性下降。

---

2. 何时使用 epoll 函数？

• 适用场景：

  • 高并发连接：如 Redis、Nginx 等需要处理数万级连接的场景，epoll 的事件驱动模型（O(1)）性能显著优于 poll。
  • Linux 环境：epoll 是 Linux 特有机制，若部署在 Linux 且无需跨平台，优先选择。
  • 低延迟要求：如实时消息推送、金融交易等，需快速响应 IO 事件。

• 设计原因：

  • 红黑树+就绪队列：epoll 使用红黑树管理 FD，仅返回就绪的 FD，避免无差别轮询；数据通过 mmap 共享内存减少内核态-用户态拷贝。
  • 边缘触发（ET）模式：可减少事件通知次数，提升吞吐量（需确保一次处理完数据）。

---

3. Redis 的选择与实践

• 默认使用 epoll：
  Redis 在 Linux 下默认采用 epoll，因其单线程模型依赖高效 IO 多路复用处理海量连接，作者 Antirez 称其为“奇迹”。

  • 性能对比：实验显示，epoll 在 1000 并发下延迟（5ms）和 CPU 占用（20%）远低于 poll（12ms, 35%）。
  • 降级策略：若 epoll 不可用（如非 Linux 系统），Redis 会降级为 select 或 kqueue（BSD 系统）。

• poll 的替代场景：
  仅在老旧系统或特殊环境中（如嵌入式设备）可能被迫使用 poll，但 Redis 官方推荐优先使用 epoll。

---

总结：选择依据

维度	poll	epoll
连接规模	少量（<1000）	海量（数万+）
性能需求	低延迟非关键场景	高吞吐、低延迟
操作系统	跨平台（Windows/BSD/Linux）	仅 Linux
实现复杂度	简单	需处理边缘触发（ET）
Redis 默认	降级备用	首选（Linux 下）

建议：

• 99% 的 Linux 生产环境选择 epoll；
• 仅在兼容性或资源受限时考虑 poll。