APUE.07d::服务端常用IO模型

分类于
字数统计: 515

Nginx:

  • 基于 epoll 监听多个连接(50000 个并发连接数的响应), 当某个连接有数据准备好的时候再通知, 这样一个进程能处理多个连接
  • 大于 5 k 并发的时候, Nginx 才明显比 apache 有更好的表现

Redis

  • Redis 使用单线程的 I/O 复用模型, 自己封装了一个简单的 AeEvent 事件处理框架, 主要实现了 epoll、kqueue 和 select.
  • 优势: 对于单纯只有 I/O 操作来说, 单线程可以将速度优势发挥到最大. 且无需考虑同步问题
  • 缺陷：Redis 排序、聚合、大 Key 操作、Flush 等, 对于这些耗时较高操作, 单线程模型实际会严重影响整体吞吐量, CPU 计算过程中, 整个 I/O 调度都是被阻塞住的

Apache: 默认是每个请求启动一个线程处理, 并不适合高并发

  • 缺陷:
    • 有多少并发就需要多少进程, 最大进程数
    • 在进程创建很多的情况下, 系统切换进程的代价很高, 进程运行的时间很少
    • 实际上本机处理数据的时间很短, 大多数时间都是在”等待数据准备好”的阶段, 效率低
  • 新版的 Apache 的改进, 支持多种 MPM(Multi-Processing Model)
    • prefork: 古老
    • worker: 多进程(注意并不是每个请求一个线程), 每个进程多个线程
    • event: epoll

Tomcat:

  • BIO 模式每个请求启动一个线程处理
  • 但 Tomcat 从 JDK 1.6 支持开始支持 NIO，这种方式同 Netty 的“主从 Reactor” 类似，这种模式下，只有一个 Acceptor 线程用于 accept 新请求，Poller 线程相当于 Netty 的 sub Reactor 线程（默认 process x 2 个）只负责已建立的连接 IO 事件，业务放入 exector 线程池处理业务（包括对 socket 流的 decode，业务代码指的是 servlet.service） @link APUE.07c.网络编程-Reactor&Proactor模型

@ref: