BlazeDS作为servlet实现，因此仅限于大约数百个并发用户。
我想知道支持Servlet 3的更新的Web容器（Tomcat 7，GlassFish / Grizzly，Jetty等）是否可用于创建NIO端点以将同时用户数增加到数千个？
这是一个有效而实用的解决方案吗？有人在制作中这样做吗？
类似于此的成熟版本：http://flex.sys-con.com/node/720304 如果这在当时非常重要，为什么现在（当Servlet 3广泛可用时）没有努力尝试实现NIO端点？ （注意，我在这里是个新手，所以如果我错过了什么，请随意说清楚）
NIO的好处：http://www.javalobby.org/java/forums/t92965.html
如果没有，是一个负载均衡器和多个应用服务器，每个都有一个BlazeDS实例，推荐的解决方案（除了LCDS之外等）？
答案 0 :(得分：3)
据我所知，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协议的真正“数据推送”：服务器无法发起对客户端发送数据的调用，它必须回答请求< / em>的。这就是Comet实现依赖于不同模型的原因：
request -> wait for available data -> response
使用同步servlet处理，每个请求由一个专用服务器线程处理。但是，在数据推送处理的上下文中，此线程大多数时间只是等待可用数据，并且在消耗大量服务器资源时不执行任何操作。
异步处理的所有目的是让servlet容器使用这些（通常）空闲线程来处理其他传入请求，这就是为什么当应用程序需要实时消息传递功能时，可以期望在可伸缩性方面有显着改进的原因
你可以在网上找到解释这种机制的许多其他资源，只需google Comet。