我使用过的场景Selector是IO multiplexing：
我们有一个主要内容服务器和 100 个辅助内容服务器。辅助服务器发送更改的内容元信息，以便主服务器将更新所有最新的内容信息。最初的设计是为 100 个打开的套接字使用 100 个线程，这些套接字是一对一映射到辅助服务器的。但是由于我们想支持更多的辅助服务器，我改变了设计使用Selectors，以便一个线程执行 IO 多路复用（selector.select()）并将其发送SelectionKey到工作线程池（大小为 50 的固定线程池）。最快乐的部分是设计工作。
实施这两个问题后，我想到的是：
如果辅助内容服务器在一秒钟内轰炸了 100/1000 次请求，这种设计是否可行（目前我们每个辅助内容服务器每秒收到 5 到 7 个请求）？因为我觉得上面的设计只不过是把你的问题推到了下一层，但问题仍然存在。我对么？
上述设计只是解决了将辅助服务器的数量从 100 扩展到 500 的问题，但如果我想将每秒请求（即从 5req/sec 到假设 1000 req/sec）扩展，它不会解决问题。