Node.js 的事件驱动有什么不同? 我们不能在 ASP.Net 的 HttpAsyncHandler 中这样做吗？

我在网络编程方面不是很有经验, 我实际上还没有在 Node.js 中编写任何代码，只是对 事件驱动方法事件驱动方法感到好奇。

本文解释了当我们使用基于线程的方法处理请求时可能发生的一些不好的事情，并且应该选择事件驱动的方法。 在线程为基础，收银员/线程是坚持我们，直到我们的食物/资源准备就绪。在事件驱动的情况下，收银员将我们发送到请求队列之外的某个地方，这样我们在等待食物时就不会阻止其他请求。 要缩放基于阻塞线程的线程，需要增加线程的数量。 对我来说，这似乎是一个不正确使用线程/线程池的糟糕借口。

使用 IHttpAsyncHandler 不能正确处理这个问题吗？ Net 接收请求，使用 ThreadPool 并运行处理程序(BeginProcessRequest) ，然后在其中用回调加载文件/数据库。然后，该线程应该可以自由地处理其他请求。完成文件读取之后，ThreadPool 再次被调用并执行剩余的响应。 对我来说没什么不同，那么为什么它不是可扩展的呢？

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

所以，基于事件驱动和线程驱动(不要提出“因为它是 Javascript 和每个浏览器... ...”的论点) ，有人能告诉我使用 Node.js 而不是现有技术的实际好处是什么吗？

这是一个很长的问题。谢谢:)

28199 次浏览
小开
最佳答案

首先，Node.js 不是多线程的。这很重要。您必须是一个非常有才华的程序员，才能设计出在线程环境中能够完美工作的程序。线太硬了。

你必须是一个 天啊来维护一个线程化的项目，在那里它没有被正确设计。在非常大的项目中，有太多的问题是很难避免的。

其次，对整个平台进行了异步运行设计。你见过任何一个 ASP.NET 项目中的每一个 IO 交互都是异步的吗？简单地说，ASP.NET 的设计并不是为了事件驱动的。

然后，还有内存占用问题，这是由于每个开放连接都有一个线程，以及整个伸缩问题。如果我说错了请纠正我，但我不知道如何避免为 ASP.NET 中的每个连接创建一个新线程。

另一个问题是 Node.js 请求在没有被使用或等待 IO 时处于空闲状态。另一方面，C # 线程处于睡眠状态。现在，这些线程的睡眠数量是有限制的。在 Node.js 中，您可以轻松地在一台开发机器上同时并行处理10k 个客户机。您可以尝试在一台开发机器上并行处理10k 个线程。

JavaScript 本身作为一种语言使得异步编码更加容易。如果您仍然使用 C # 2.0，那么异步语法将是一个真正的痛苦。如果到处定义 Action<>和 Function<>并使用回调，许多开发人员会感到困惑。以事件方式编写的 ASP.NET 项目是普通 ASP.NET 开发人员无法维护的。

至于螺纹和芯子。Js 是单线程的，通过创建多节点进程来扩展。如果您有一个16核心，那么您将运行16个 Node.js 服务器实例，并且在它前面有一个 Node.js 负载平衡器。(如果需要，可以使用 nginx 负载平衡器)。

从一开始，这些都是在非常低的级别写入平台的。这不是一些功能螺栓后来的线。

其他优势

Node.js 还有更多内容。以上就是为什么 Node.js 处理事件循环的方式比 ASP.NET 中使用异步功能更好的原因。

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

Node.js 的缺点

这很难。很年轻。作为一名 熟练 JavaScript 开发人员，我在使用 Node.js 编写网站时面临困难，这仅仅是因为它的低级本质和我所拥有的控制水平。感觉就像 C。很大的灵活性和力量，要么用在我身上，要么用来吊死我。

API 没有被冻结。变化很快。我可以想象不得不在5年内完全重写一个大型网站，因为届时 Node.js 的数量将会改变。它是可行的，你只需要知道在 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 社区之间的 文化差异。当然，IHttpAsyncHandler 存在从那时起就存在了。NET 1.0，所以它甚至可能是好的，但所有围绕 Node.js 的代码和讨论都是关于异步 I/O 的，当涉及到。NET.要使用 LINQToSQL 吗？有点像 你可以的。想要记录东西吗？可能是 也许“ CSharp DotNet Logger”能行。

所以，是的，IHttpAsyncHandler 就在那里，如果你真的很小心，你可能能够编写一个事件驱动的 Web 服务，而不会被某些阻塞的 I/O 绊倒，但我真的没有得到很多人正在使用它的印象(当然它不是编写 ASP.NET 应用程序的主要方式)。相比之下，Node.js 完全是关于事件 I/O、所有的代码示例、所有的库，这是人们使用它的唯一方式。所以，如果你打算赌哪个事件的 I/O 模型实际上可以一直工作下去，Node.js 可能会是你的选择。

小开

关于 node.js 和 ASP.Net 以及异步编程，有很多误解。你可以做 ASP.NET 中的非阻塞 IO。中使用 start/end 模式执行 Web 服务调用或其他 I/O 绑定操作时，大多数人不知道底层的 . Net 框架使用 Windows 的 iocomplete 端口。净值2.0及以上。IO 完成端口是 Windows 操作系统支持非阻塞 IO 的方式，这样应用程序线程就可以释放 IO 操作完成的原因。有趣的是，node.js 通过 Cygwin 在 Windows 中使用了一个不太理想的非阻塞 IO 实现。一个新的 Windows 版本正在路线图中，在微软的指导下，它将使用 IO 完成端口。在这一点上，根本没有什么区别。

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

同步 IO (阻塞)使得控制流更加清晰，因此它变得流行起来。计算机环境为什么是多线程的原因只是表面上与此有关。它更一般地与多 CPU 的时间分配和利用率有关。

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

就我个人而言，我还没有看到任何引入这样一个 node.js 的附加技术的令人信服的论据。然而，可能有很好的理由，但是在我看来，它们与通过非阻塞 IO 服务大量连接没有什么关系，因为这也可以通过 ASP.NET 来完成。

TWtamejs 可以使您的 nodejs 代码更易读，类似于即将推出的.NetAsync CTP。

小开

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

Js vs. Net 性能

Http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/ 还有

Http://www.hanselman.com/blog/installingandrunningnodejsapplicationswithiniisonwindowsareyoumad.aspx

谢谢。


提交答案