BlazeDS是作为servlet实现的，因此仅限于大约数百个同时使用的用户。
我想知道最近支持Servlet 3的web容器（Tomcat7、GlassFish/Grizzly、Jetty等）是否可以用于创建NIO端点，以将同时使用的用户数量增加到数千？
这是一个有效和实用的解决方案吗？有人在生产中这样做吗？
这是一个成熟的版本：http://flex.sys-con.com/node/720304如果这在当时非常重要，那么为什么现在（当Servlet 3广泛可用时）没有努力实现NIO端点呢？（注意，我是这里的新手，所以如果我错过了什么，请随时说明显而易见的事情）
NIO的好处：http://www.javalobby.org/java/forums/t92965.html
如果不是，推荐的解决方案是一个负载均衡器和多个应用程序服务器（每个服务器都有一个BlazeDS实例）吗？
GraniteDS&异步Servlet
据我所知，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服务器集群，以进一步提高可扩展性和健壮性（例如，请参阅本视频）。
异步Servlet性能
异步servlet与经典servlet的可伸缩性已经进行了多次基准测试，并给出了令人印象深刻的结果。例如，请参阅Jetty博客上的这篇文章：
对于非NIO或非Continuation服务器需要大约11000个线程才能同时处理10000个用户。Jetty只需250个就可以处理这么多连接线程。
经典同步模型：
- 10000个并发用户->11000个服务器线程
- 1.1比例
Comet异步模型：
- 10000个并发用户->250个服务器线程
- 0.025的比例
这种比率可以从其他异步实现（而不是Jetty）中大致预期，并且使用Flex/AMF3而不是纯文本HTTP请求应该不会改变太多结果。
为什么选择异步Servlet
当每个请求都被立即处理时，经典的（同步）servlet模型是可以接受的：
request -> immediate processing -> response
数据推送的问题是，HTTP协议中没有真正的"数据推送"：服务器无法向客户端发起发送数据的调用，必须回答请求。这就是为什么Comet的实现依赖于不同的模型：
request -> wait for available data -> response
通过同步servlet处理，每个请求都由一个专用的服务器线程处理。然而，在数据推送处理的上下文中，该线程大部分时间只是在等待可用数据，并且在消耗大量服务器资源的同时什么也不做。
异步处理的全部目的是让servlet容器使用这些（通常）空闲线程来处理其他传入请求，这就是为什么当应用程序需要实时消息传递功能时，您可以期望在可伸缩性方面得到显著改进。
您可以在Web上找到许多其他资源来解释这种机制，只需在Comet上搜索即可。