Java 缩放问题：NIO中的选择器

我使用的和IO多路复用的场景是：

我们有一个主内容服务器和100个辅助内容服务器。辅助服务器发送更改的内容元信息，以便主服务器更新所有最新的内容信息。最初的设计是为100个打开的套接字使用100个线程，这些套接字一对一映射到辅助服务器。但由于我们希望支持更多的辅助服务器，我将设计更改为使用选择器，以便一个线程执行IO多路复用选择器。选择并将SelectionKey发送到大小为50的工作线程池固定线程池。最令人高兴的是设计成功了

实施后，我想到的两个问题是：

如果二级内容服务器在一秒钟内轰击了100/1000个请求，那么目前这种设计是否可行？每个二级内容服务器每秒可以收到5到7个请求？因为我觉得上面的设计只是把你的问题推到下一层，但问题仍然存在。我说得对吗

上述设计只是解决了将辅助服务器的数量从100扩展到500的问题，但如果我想将每秒的请求（即从5req/sec扩展到1000 req/sec）扩展，则无法解决该问题

---

我认为你做错事了。在连接数万个之前，每个连接使用一个线程阻塞I/O是非常有用的，并且更容易正确编程。最终导致您死亡的是线程堆栈的内存，而不是线程或连接的数量。@EJP在某些情况下，即使我们现在使用它管理1000多个辅助服务器。如果没有选择器，我们将不得不使用1000个持久连接。