BlazeDS 是作为 servlet 实现的，因此仅限于大约数百个同时用户。
我想知道是否可以使用支持 Servlet 3 的最新 Web 容器（Tomcat 7、GlassFish/Grizzly、Jetty 等）来创建 NIO 端点以将同时用户的数量增加到数千？
这是一个有效且实用的解决方案吗？有人在生产中这样做吗？
类似这个的成熟版本：http://flex.sys-con.com/node/720304 如果这在当时非常重要，为什么现在（当 Servlet 3 被广泛使用时）没有努力尝试实现 NIO 端点？ （注意，我是这里的新手，所以如果我遗漏了什么，请随意说明）
蔚来的好处：http://www.javalobby.org/java/forums/t92965.html
如果不是，是否有一个负载均衡器和多个应用程序服务器，每个都有一个 BlazeDS 实例，推荐的解决方案（除了去 LCDS 等）？
【问题讨论】：
据我所知，GraniteDS 是唯一为实时消息传递实现异步 servlet 的解决方案，即。数据推送。此功能不仅适用于 Servlet 3 容器（Tomcat 7、JBoss 7、Jetty 8、GlassFish 3 等），而且适用于旧的或其他具有特定异步支持的容器（例如 Tomcat 6/CometProcessor、WebLogic 9+/AbstractAsyncServlet等）
其他解决方案没有此功能 (BlazeDS) 或使用 RTMP（LCDS、WebORB 和 Clear Toolkit 的最新版本）。关于 RTMP 实现我不能说太多，但 BlazeDS 显然缺少可扩展的实时消息传递实现，因为它只使用同步 servlet 模型。
如果您需要处理成千上万的并发用户，您甚至可以创建一个 GraniteDS 服务器集群，以进一步提高可扩展性和稳健性（例如，参见 this video）。
异步 servlet 与经典 servlet 的可扩展性已经过多次基准测试，并给出了令人印象深刻的结果。例如，请参阅 Jetty 博客上的 this post：
对于非 NIO 或非基于 Continuation 的服务器，这 将需要大约 11,000 个线程来同时处理 10,000 个 用户。 Jetty 仅使用 250 个连接来处理此数量的连接 线程。
经典同步模型：
Comet 异步模型：
这种比率可以从其他异步实现（不是 Jetty）中大致预期，并且使用 Flex/AMF3 代替纯文本 HTTP 请求不应该改变太多结果。
当立即处理每个请求时，经典（同步）servlet 模型是可以接受的：
request -> immediate processing -> response
数据推送的问题在于HTTP协议没有真正的“数据推送”：服务器无法发起对客户端的调用以发送数据，它必须响应请求。这就是 Comet 实现依赖于不同模型的原因：
request -> wait for available data -> response
使用同步 servlet 处理，每个请求都由一个专用服务器线程处理。但是，在数据推送处理的上下文中，该线程大部分时间只是在等待可用数据，而在消耗大量服务器资源时什么也不做。
异步处理的全部目的是让 servlet 容器使用这些（通常）空闲线程来处理其他传入请求，这就是为什么当您的应用程序需要实时消息传递功能时，您可以期望在可伸缩性方面得到显着改进.
您可以在 Web 上找到许多其他解释此机制的资源，只需在 Comet 上搜索即可。
【讨论】：