Node.js的事件驱动有何不同？我们不能在ASP.Net的HttpAsyncHandler中做到这一点吗？

我对Web编程的经验不是很丰富，并且实际上还没有在Node.js中编写任何代码，只是对事件驱动的方法感到好奇。看起来确实不错。

本文介绍了当我们使用基于线程的方法来处理请求时可能发生的一些坏事情，而应该选择事件驱动的方法。在基于线程的情况下，收银员/线程会一直困扰我们，直到我们准备好食物/资源为止。在事件驱动下，收银员将我们发送到请求队列之外的某个地方，因此我们在等待食物时不会阻止其他请求。要基于阻塞线程进行扩展，您需要增加线程数量。对我来说，这似乎是不好用的借口，原因是未正确使用线程/线程池。

使用IHttpAsyncHandler无法正确处理吗？ASP.Net接收一个请求，使用ThreadPool并运行处理程序（BeginProcessRequest），然后在其中加载带有回调的文件/数据库。然后，该线程应该可以自由处理其他请求。一旦文件读取完成，ThreadPool将再次被调用并执行剩余的响应。对我来说没什么不同，那为什么不那么可扩展？

我确实知道基于线程的缺点之一是，使用线程需要更多的内存。但是只有有了这些，您才能享受多核的好处。我怀疑Node.js根本没有使用任何线程/内核。

因此，仅基于事件驱动和基于线程（不要带“因为它是Javascript和每个浏览器...”参数），有人可以指出我使用Node.js而不是使用它的实际好处是什么。现有技术？

这是一个很长的问题。谢谢 ：）

首先，Node.js不是多线程的。这个很重要。您必须是一个非常有才华的程序员，才能设计在线程环境中完美运行的程序。线程很难。

您必须成为一个维护未正确设计的线程项目的上帝。在大型项目中，有太多问题是很难避免的。

其次，整个平台被设计为异步运行。您是否看到任何单个IO交互都是异步的ASP.NET项目？简而言之，ASP.NET并非设计为事件驱动的。

然后，由于每个开放连接只有一个线程以及整个扩展问题，因此存在内存占用。如果我错了，请纠正我，但我不知道您如何避免为ASP.NET中的每个连接创建一个新线程。

另一个问题是，不使用或等待IO时，Node.js请求处于空闲状态。另一方面，C＃线程处于休眠状态。现在，可以休眠的这些线程的数量受到限制。在Node.js中，您可以在一台开发机上轻松轻松地同时并行处理1万个客户端。您尝试在一台开发计算机上并行处理10k线程。

JavaScript本身作为一种语言使异步编码更加容易。如果您仍在使用C＃2.0，那么异步语法确实很痛苦。如果你定义很多开发商只会感到困惑Action<>和Function<>所有的地方，并使用回调。以事件方式编写的ASP.NET项目是普通ASP.NET开发人员无法维护的。

至于线程和核心。Node.js是单线程的，可以通过创建多节点进程进行扩展。如果您有一个16核，那么您将运行16个node.js服务器实例，并在其前面有一个Node.js负载均衡器。（如果需要，也许是一个nginx负载均衡器）。

从一开始，所有内容都以非常低的级别被写入平台。这并不是稍后再添加的某些功能。

其他优点

Node.js的功能远不止上述。以上仅是为什么Node.js处理事件循环的方法比使用ASP.NET中的异步功能更好的原因。

• 性能。它很快。真快。
• Node.js的一大优势是其底层API。您有很多控制权。
• 您将整个HTTP服务器直接集成到代码中，然后外包给IIS。
• 您拥有整个Nginx与Apache的比较。
• 整个C10K挑战由节点很好地处理，而不是由IIS处理
• AJAX和JSON通信自然而轻松。
• 实时通信是Node.js的一大优点。它是为此而做的。
• 与基于文档的nosql数据库一起很好地玩。
• 也可以运行TCP服务器。可以进行文件写入访问，可以在服务器上运行任何unix控制台命令。
• 您使用例如CouchDB和map / reduce在javascript中查询数据库。您使用JavaScript编写客户端。在Web堆栈上进行开发时，没有上下文切换。
• 丰富的社区驱动的开源模块集。node.js中的所有内容都是开源的。
• 占地面积小，几乎没有依赖性。您可以自己构建node.js源。

Node.js的缺点

这个很难（硬。还很年轻 作为一名熟练的JavaScript开发人员，由于Node.js的底层特性和我所拥有的控制级别，我面临着用Node.js编写网站的困难。感觉就像C。很多灵活性和力量可用于我或使我吊死。

该API未冻结。它正在迅速变化。我可以想象，由于到那时Node.js的数量将发生变化，不得不在5年内完全重写一个大型网站。这是可行的，您只需要知道在node.js网站上进行维护并不便宜。

进一步阅读

http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/

http://blip.tv/file/2899135

http://nodeguide.com/

关于node.js与ASP.Net和异步编程存在很多误解。您可以在ASP.NET中进行非阻塞IO。大多数人不知道在使用.Net 2.0及更高版本中的开始/结束模式进行Web服务调用或其他I / O绑定操作时，.Net框架在下面使用Windows iocompletion端口。IO完成端口是Windows操作系统支持非阻塞IO的方式，因此可以释放应用线程以完成IO操作。有趣的是，node.js在Windows中通过Cygwin使用了非最佳的非阻塞IO实现。路线图上有一个新的Windows版本，在Microsoft的指导下，它将使用IO完成端口。那时，根本没有区别。

也可以在ADO.NET中进行非阻塞数据库调用，但是要注意ORM工具，例如NHibernate和Entity Framework。它们仍然非常同步。

同步IO（阻塞）使控制流更加清晰，因此它变得很流行。计算机环境是多线程的原因仅与表面有关。通常，它与多个CPU的时间共享和利用有关。

仅拥有一个线程可能会在冗长的操作期间导致饥饿，这可能与IO和复杂的计算有关。因此，即使经验法则是一个线程。在使用非阻塞IO时，应该仍然考虑足够大的线程池大小，以使简单请求不会因较复杂的操作而饿死。多线程还使复杂的操作可以轻松地在多个CPU之间分配。像node.js这样的单线程环境只能通过更多进程和消息传递来利用多核处理器来协调动作。

我个人还没有看到引人注目的论点来介绍诸如node.js的其他技术。但是，可能有充分的理由，但是我认为它们与通过非阻塞IO服务大量连接无关，因为这也可以通过ASP.NET完成。

BTW tamejs可以使您的nodejs代码更具可读性，类似于即将推出的新的.Net Async CTP。

很容易低估Node.js和ASP.NET社区之间的文化差异。当然，IHttpAsyncHandler存在，并且自.NET 1.0开始就存在，因此它甚至可能不错，但是有关Node.js的所有代码和讨论都与异步I / O有关，对于.NET绝对不是这种情况。是否要使用LINQ To SQL？你有点可以，有点。要记录东西吗？也许“ CSharp DotNet Logger”可以工作。

所以，是的，IHttpAsyncHandler就在那儿，如果您真的很小心，则可以编写事件驱动的Web服务，而不必在某个地方跳过一些阻塞的I / O，但是我并没有真正得到很多人正在使用的印象它（它当然不是编写ASP.NET应用程序的主要方式）。相比之下，Node.js仅涉及事件I / O，所有代码示例，所有库，这是人们使用它的唯一方式。因此，如果您要押注某个事件的I / O模型实际上一直有效，那么Node.js可能就是您的首选。

根据当前时代的技术进步和以下链接的阅读，我可以说，这取决于专业知识，并根据特定情况选择完美的组合。NodeJS越来越成熟，并且在ASP.NET方面，我们拥有ASP.NET MVC，WebAPI和SignalR等，可以使事情变得更好。

Node.js与.Net的性能

http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/ 和

http://www.hanselman.com/blog/InstallingAndRunningNodejsApplicationsWithinIISOnWindowsAreYouMad.aspx

谢谢。