Node.js的事件驱动有什么不同？我们不能在ASP.Net的HttpAsyncHandler中做到这一点吗？
我在web编程方面经验不是很丰富，而且我还没有真正用Node.js编写过任何代码，只是对event-driven approach很好奇。看起来确实不错。
本文解释了当我们使用基于线程的方法来处理请求时可能会发生的一些不好的事情，应该选择事件驱动的方法。在基于线程的模式中，收银员/线程会一直与我们在一起，直到我们的食物/资源准备就绪。而在事件驱动模式下，收银员会将我们从请求队列中的某个位置发送出去，这样我们在等待食物时就不会阻塞其他请求。要扩展基于线程的阻塞，您需要增加线程的数量。对我来说，这似乎是没有正确使用线程/线程池的一个糟糕的借口。
难道不能使用IHttpAsyncHandler正确地处理这个问题吗？ASP.Net接收请求，使用ThreadPool并运行处理程序(BeginProcessRequest)，然后在它内部使用回调加载文件/数据库。然后，该线程应该可以自由处理其他请求。文件读取完成后，ThreadPool将再次执行操作，并执行剩余的响应。对我来说没有太大的不同，那么为什么它不具有可伸缩性呢？
据我所知，基于线程的方法的缺点之一是，使用线程需要更多内存。但只有这样，您才能享受多核的好处。我怀疑Node.js根本没有使用任何线程/内核。
因此，仅仅基于事件驱动和基于线程(不要带来“因为它是Javascript和每个浏览器...”争论)，谁能告诉我使用Node.js而不是现有技术的实际好处是什么？
这是一个很长的问题。谢谢:)
回答 2
Stack Overflow用户
发布于 2011-08-03 07:07:01
关于node.js、ASP.Net和异步编程，有很多误解。你可以做non blocking IO in ASP.NET。当您使用.Net 2.0及更高版本中的begin/end模式进行web服务调用或其他I/O绑定操作时，大多数人不知道底层的.Net framework uses Windows iocompletion ports。IO完成端口是Windows操作系统支持非阻塞IO的方式，以便在IO操作完成时释放应用程序线程。有趣的是，node.js通过Cygwin在Windows中使用了一种不太优化的非阻塞IO实现。一个新的Windows版本正在规划中，在微软的指导下，它将使用IO完成端口。在这一点上，这是没有区别的。
也可以在ADO.NET中进行非阻塞数据库调用，但要注意NHibernate和实体框架等对象关系管理工具。它们仍然是非常同步的。
同步IO (阻塞)使得控制流更加清晰，因此它变得流行起来。计算机环境之所以是多线程的，只是表面上与此有关。它通常与多个CPU的分时和利用率有关。
在长时间的操作中，只有一个线程可能会导致饥饿，这可能与IO和复杂的计算有关。所以，即使经验法则是一个线程公关。当使用非阻塞IO时，人们仍然应该考虑足够的线程池大小，这样简单的请求就不会因为更复杂的操作而变得饥饿。多线程还允许在多个CPU之间轻松地拆分复杂的操作。像node.js这样的单线程环境只能通过更多的进程和消息传递来利用多核处理器来协调操作。
就我个人而言，还没有看到任何令人信服的论据来引入像node.js这样的额外技术。然而，可能有很好的理由，但在我看来，它们与通过非阻塞IO服务大量连接没有什么关系，因为这也可以使用ASP.NET来完成。
顺便说一句，tamejs可以帮助你的nodejs代码更具可读性，类似于即将推出的新的.Net Async CTP。
Stack Overflow用户
发布于 2013-07-01 22:11:45
根据当前时代的技术进步和阅读下面的链接，我可以说，这是专业知识和根据特定场景选择完美组合的问题。NodeJS正在变得越来越成熟，在ASP.NET方面，我们有ASP.NET MVC、WebAPI和SignalR等，以使事情变得更好。
http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/和
http://www.hanselman.com/blog/InstallingAndRunningNodejsApplicationsWithinIISOnWindowsAreYouMad.aspx
谢谢。
https://stackoverflow.com/questions/5599024
复制相似问题