多个线程中的多个选择器

Question

在 n 个线程之间分配传入连接是否有益，每个线程都有自己独立的 NIO Selector，其中 n 是服务器中的内核数？假设我正在编写一个服务器，它应该处理多个客户端连接。我可以有类似的东西：

selector.select();
Iterator<SelectionKey> i = selector.selectedKeys().iterator();

while (i.hasNext()) {
   SelectionKey key = i.next();
   i.remove();

   if (!key.isValid())
      continue;

   if (key.isAcceptable()) {
      // get one of the n selectors (I'd have one per core)
      Selector chosenSelector = getRandomSelector();

      // delegate the new connection to the chosen selector
      SocketChannel newChannel = key.channel.accept();
      newChannel.configureBlocking(false);
      newChannel.register(chosenSelector, SelectionKey.OP_READ);
   }
}

你们觉得这有道理吗？我的意思是，运行 n 个线程，每个线程都有不同的选择器？还是我应该坚持使用一个选择器线程来处理所有连接的 OP_READ？还是别的什么？

Answer 1

不，这没有好处，因为需要处理的代码与 IO 操作所需的时间之间的关系可以忽略不计。特别是如果您考虑同步碎片数据所需的额外时间。然而，在单独的线程中处理接收到的数据是有益的。

所以基本上：有一个单线程选择器循环，将数据从一个缓冲区复制到任务缓冲区中，以便在单独的线程中进一步处理，然后在 Executor 中启动带有该任务缓冲区的 Runnable 以处理复制的数据.

Answer 2

这正是 Netty 所做的。它使用 N 个线程调用 Selector.select() 其中 N = (num available CPUs * 2) 由于超线程，它乘以 2。这是父事件循环，它被认为是接受套接字连接的“接受者事件循环”。 然后是线程工作者的子EventLoop

建议你看看NioEventLoopGroup-class

Answer 3

在 n 个线程之间分配传入连接是否有益，每个线程都有自己独立的 NIO 选择器，其中 n 是服务器中的内核数？

所有主要框架都以这种方式运行； Mina、Netty、Nginx 等都在多个选择器之间分配套接字。 Nginx 确实将文件描述符传递给具有自己的选择器的分叉进程。

您在这里描述的是基本的选择器-工作者模型。每个核心通常有 2 个工人。每个工人都有一个Selector。这个模型在 Windows 上是绝对必要的，因为每个 Selector 只能处理 1024 个套接字，而 JDK 所做的解决方法对性能来说是灾难性的。

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b27/sun/nio/ch/WindowsSelectorImpl.java

• 核心 0 - 线程 -> 选择器 -> OP_READ/OP_WRITE -> 执行业务逻辑
• 核心 1 - 线程 -> 选择器 -> OP_READ/OP_WRITE -> 执行业务逻辑
• 核心 2 - 线程 -> 选择器 -> OP_READ/OP_WRITE -> 执行业务逻辑
• 核心 3 - 线程 -> 选择器 -> OP_READ/OP_WRITE -> 执行业务逻辑

这是缩放反应器模式的基本方法。

重要的是单个SocketChannel 仅附加到单个Selector。所以不要打电话给SocketChannel.register() 给一堆Selectors 听OP_READ，因为你不会得到任何好处。

http://man7.org/linux/man-pages/man7/epoll.7.html

Q2 两个epoll实例可以等待同一个文件描述符吗？如果 那么，事件是否同时报告给两个 epoll 文件描述符？

A2 是的，事件会同时报告给双方。不过，小心 可能需要编程才能正确执行此操作。

Answer 4

我将只有一个选择器，并让它通过无锁环形缓冲区将消息分配给固定数量的线程。然后，您可以以完全无锁定、超快速的方式进行流程。流程是这样的：

关键选择器 => DEMUX => 工作线程 => MUX => 关键选择器

您只需要确保您的工作线程数量足够（并且您有足够的空闲内核供它们使用）来快速处理您的消息，否则您最终可能会得到一个完整的 DEMUX，并且选择器将不得不阻塞或丢弃消息。

我建议您阅读this article 以了解异步、单线程、非阻塞网络框架的工作原理。当然你也可以查看 Netty 或 Mina。有关使用 demux 和 mux 支付的延迟（以纳秒为单位）的概念，请参阅 this benchmark。