Java 多个NIO反应堆，还是只有一个？

我目前一直在阅读JavaNIO，过去我自己也做过一些实现。然而，我从来没有真正想过服务器的性能——这看起来很愚蠢，事实确实如此。我听人说单线程反应堆很好，但我真的想利用我拥有的内核

因为我要制作的实现是一个游戏，所以也有一些游戏逻辑线程，所以它不能占用很多线程——如果有的话，可能只有两个线程

下面是我想到的情节：

• 高优先级反应堆
• 接受连接
• 处理游戏的登录过程（客户端发送数据包，服务器处理，服务器发送响应数据包，而不是大量数据）
• 按需分发资源文件数据（构建游戏时，服务器会发送数据，客户端会将数据存储在缓存中，缓存中包含游戏的几乎所有资源。这大部分是在加载游戏时完成的，但在游戏进行时，很多情况仍会在后台发生）
• 标准反应器
• 读取和响应游戏中的数据包；它们通常很小，但也有很多，因为一个玩家所做的每件事都是以数据包的形式分发的，我希望能够很好地扩展它，以处理大约200名玩家）

目标：

• 适合约200-300名玩家
• 快速响应游戏包
• 快速分发上述文件数据
• 快速接受连接

另外，如果你熟悉它，游戏是RuneScape。我的目标是模拟RuneScape的官方服务器软件，以便我的可以与他们的一个客户端一起使用。这是一种流行的做法，你看

我的问题是：你认为这是一个好的实施方案吗？仅仅拥有一个反应堆是更好的主意吗？或者我应该使用更多？我猜接收和发送的数据大致相同，在高优先级反应堆上可能会多一点（这就是为什么它是高优先级的。）

而且，当我把它定义为高优先级时，我实际上并没有把它置于标准反应堆之上。它只是处理被认为比游戏包更重要的任务

非常感谢任何反馈：）如果需要任何澄清/解释，请让我知道

您认为这是一个好的实现吗

---

对于100-1000个连接，我将使用一个/两个线程，每个连接模型带有阻塞NIO或旧IO。这通常更易于实现，并且对于这种数量的连接几乎同样有效。如果您有免费的内核，那么越简单越好。显然，这个模型可以毫无问题地使用您的所有内核

正如我在Rune服务器上多次解释的，这是一种理想的方法。这对RuneScape协议（可能还有其他基于循环的游戏）非常有益

最终目标是避免和减少将网络帧编码/解码为数据包对象并将其排队等待以后处理的开销。如果您可以安全地直接从缓冲区读取数据，同时遵守RuneScape的基于周期的处理，而不需要任何同步，您已经从该任务中尽可能地消除了开销

---

第二个高优先级反应器的目的不是为了性能，而是为了减少接受客户端和登录过程的延迟。它也适用于缓存更新，这绝对需要尽可能少的延迟。

那么，我是否应该将所有不同的任务放入just-on-reactor并试一试？这是服务器的处理器规格：3.1 GHz四核（8个线程）Intel core i7，如果我能在1个线程中运行它，那就太好了，因为我想并行运行游戏逻辑：）我关心的是，我是否真的能够用一个线程高效地流式传输数据包。播放器更新数据包通常非常繁重。每个连接一个线程，而不是每个服务器一个线程。不需要反应堆。100个连接=100+个线程。在RSPS社区中，人们以前已经这样做过，并且已经证明它工作得不是很好——一旦你开始拥有几百个线程，性能可能会变得有点糟糕。另外，制作大量线程不是很糟糕吗？什么是太多的线程？太多的线程取决于应用程序，对于CPU绑定的进程，您只需要与逻辑线程相同的线程数（在某些情况下是内核数）。对于IO绑定的应用程序，它更可能是数百个，最多一千个。这些测试中有很多都是使用旧的JVM、操作系统和硬件技术，而100个测试都不好。据我所知，这一限制目前已接近1000，而在现代CPU、操作系统和硬件中，最高可达10000。如果你想要100000+NIO是唯一的答案。在我看来，这是个糟糕的建议。1000个线程是非常多的，特别是当您为性能而编程时。1万是近乎荒谬的。如果我期望有几十个以上的客户机，我不会使用每个客户机的线程。