Node.js 的事件驱动有何不同？我们不能在 ASP.Net 的 HttpAsyncHandler 中做到这一点吗？
我对网络编程不太有经验， 我实际上还没有在 Node.js 中编写任何代码，只是对 事件驱动方法。看起来确实不错。
本文解释了当我们使用基于线程的方法来处理请求时可能会发生的一些不好的事情，并且应该选择事件驱动的方法。 在基于线程的情况下，收银员/线程会一直陪伴着我们，直到我们的食物/资源准备好。在事件驱动中，收银员将我们发送到请求队列之外的某个位置，这样我们在等待食物时就不会阻止其他请求。 要扩展基于线程的阻塞，您需要增加线程数量。 对我来说，这似乎是不正确使用线程/线程池的一个糟糕借口。
不能使用 IHttpAsyncHandler 正确处理吗？ ASP.Net 接收请求，使用 ThreadPool 并运行处理程序 (BeginProcessRequest)，然后在其中我们使用回调加载文件/数据库。然后该线程应该可以自由地处理其他请求。文件读取完成后，线程池将再次调用并执行剩余的响应。 对我来说并没有什么不同，那么为什么它不具有可扩展性呢？
据我所知，基于线程的缺点之一是，使用线程需要更多内存。但只有有了这些，你才能享受到多核的好处。我怀疑 Node.js 根本没有使用任何线程/核心。
因此，仅基于事件驱动与基于线程（不要带上“因为它是 Javascript 和每个浏览器......”的论点），有人可以指出我使用 Node.js 而不是的实际好处是什么吗？现有技术？
这是一个很长的问题。谢谢 ：）
I'm not very experienced in web programming,
and I haven't actually coded anything in Node.js yet, just curious about the event-driven approach. It does seems good.
The article explains some bad things that could happen when we use a thread-based approach to handle requests, and should opt for a event-driven approach instead.
In thread-based, the cashier/thread is stuck with us until our food/resource is ready. While in event-driven, the cashier send us somewhere out of the request queue so we don't block other requests while waiting for our food.
To scale the blocking thread-based, you need to increase the number of threads.
To me this seems like a bad excuse for not using threads/threadpools properly.
Couldn't that be properly handled using IHttpAsyncHandler?
ASP.Net receives a request, uses the ThreadPool and runs the handler (BeginProcessRequest), and then inside it we load the file/database with a callback. That Thread should then be free to handle other requests. Once the file-reading is done, the ThreadPool is called into action again and executes the remaining response.
Not so different for me, so why is that not as scalable?
One of the disadvantages of the thread-based that I do know is, using threads needs more memory. But only with these, you can enjoy the benefits of multiple cores. I doubt Node.js is not using any threads/cores at all.
So, based on just the event-driven vs thread-based (don't bring the "because it's Javascript and every browser..." argument), can someone point me out what is the actual benefit of using Node.js instead of the existing technology?
That was a long question. Thanks :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
首先，Node.js 不是多线程的。这很重要。您必须是一位非常有才华的程序员才能设计出在线程环境中完美运行的程序。线程很难。
你必须是一个上帝才能维护一个设计不正确的线程项目。在非常大的项目中，有很多难以避免的问题。
其次，整个平台被设计为异步运行。您是否见过每个 IO 交互都是异步的 ASP.NET 项目？简而言之，ASP.NET 并不是被设计为事件驱动的。
然后，由于每个打开连接只有一个线程以及整个扩展问题，因此存在内存占用问题。如果我错了，请纠正我，但我不知道如何避免为 ASP.NET 中的每个连接创建一个新线程。
另一个问题是 Node.js 请求在未使用或等待 IO 时处于空闲状态。另一方面，C# 线程处于休眠状态。现在，可以休眠的线程数量受到限制。在 Node.js 中，您可以轻松地在一台开发机器上同时并行处理 10k 个客户端。您尝试在一台开发机器上并行处理 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 的缺点
很难。还年轻啊作为一名熟练的 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/
First of all, Node.js is not multi-threaded. This is important. You have to be a very talented programmer to design programs that work perfectly in a threaded environment. Threads are just hard.
You have to be a god to maintain a threaded project where it wasn't designed properly. There are just so many problems that can be hard to avoid in very large projects.
Secondly, the whole platform was designed to be run asynchronously. Have you see any ASP.NET project where every single IO interaction was asynchronous? simply put, ASP.NET was not designed to be event-driven.
Then, there's the memory footprint due to the fact that we have one thread per open-connection and the whole scaling issue. Correct me if I'm wrong but I don't know how you would avoid creating a new thread for each connection in ASP.NET.
Another issue is that a Node.js request is idle when it's not being used or when it's waiting for IO. On the other hand, a C# thread sleeps. Now, there is a limit to the number of these threads that can sleep. In Node.js, you can easily handle 10k clients at the same time in parallel on one development machine. You try handling 10k threads in parallel on one development machine.
JavaScript itself as a language makes asynchronous coding easier. If you're still in C# 2.0, then the asynchronous syntax is a real pain. A lot of developers will simply get confused if you're defining
Action<>andFunction<>all over the place and using callbacks. An ASP.NET project written in an evented way is just not maintainable by an average ASP.NET developer.As for threads and cores. Node.js is single-threaded and scales by creating multiple-node processes. If you have a 16 core then you run 16 instances of your node.js server and have a single Node.js load balancer in front of it. (Maybe a nginx load balancer if you want).
This was all written into the platform at a very low-level right from the beginning. This was not some functionality bolted on later down the line.
Other advantages
Node.js has a lot more to it then above. Above is only why Node.js' way of handling the event loop is better than doing it with asynchronous capabilities in ASP.NET.
Disadvantages of Node.js
It's hard. It's young. As a skilled JavaScript developer, I face difficulty writing a website with Node.js just because of its low-level nature and the level of control I have. It feels just like C. A lot of flexibility and power either to be used for me or to hang me.
The API is not frozen. It's changing rapidly. I can imagine having to rewrite a large website completely in 5 years because of the amount Node.js will be changed by then. It is do-able, you just have to be aware that maintenance on node.js websites is not cheap.
further reading
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 框架在您进行 Web 操作时使用 Windows iocompletion 端口在 .Net 2.0 及更高版本中使用开始/结束模式的服务调用或其他 I/O 绑定操作。 IO 完成端口是 Windows 操作系统支持非阻塞 IO 的方式，以便释放应用程序线程以完成 IO 操作。有趣的是，node.js 通过 Cygwin 在 Windows 中使用了不太优化的非阻塞 IO 实现。新的 Windows 版本已在路线图上，在 Microsoft 的指导下，该版本将使用 IO 完成端口。到那时，就没有什么区别了。
也可以在 ADO.NET 中进行非阻塞数据库调用，但要注意 ORM 工具，例如 NHibernate 和 Entity Framework。它们仍然非常同步。
同步IO（阻塞）使控制流程更加清晰，因此变得流行。计算机环境是多线程的原因只是表面上与此有关。它更普遍地与多个CPU 的时间共享和利用有关。
只有一个线程可能会导致长时间操作期间的饥饿，这可能与 IO 和复杂计算有关。因此，即使经验法则是单线程 pr。当使用非阻塞 IO 时，仍然应该考虑足够的线程池大小，以便简单的请求不会因更复杂的操作（如果存在）而缺乏。多线程还允许在多个 CPU 之间轻松分割复杂的操作。像 Node.js 这样的单线程环境只能通过更多进程和消息传递来利用多核处理器来协调操作。
我个人还没有看到任何令人信服的论据来引入诸如 Node.js 之类的附加技术。然而，可能有充分的理由，但在我看来，它们与通过非阻塞 IO 服务大量连接无关，因为这也可以通过 ASP.NET 来完成。
BTW Tamejs 可以帮助您的 NodeJS 代码更具可读性，类似于即将推出的新 .Net Async CTP。
There are a lot of misconceptions regarding node.js vs. ASP.Net and asynchronous programming. You can do non blocking IO in ASP.NET. Most people don't know that the .Net framework uses Windows iocompletion ports underneath when you do web service calls or other I/O bound operations using the begin/end pattern in .Net 2.0 and above. IO completion ports is the way the Windows operating system supports non-blocking IO so that the app thread is freed why the IO operation completes. Interestingly, node.js uses a less optimal non blocking IO implementation in Windows through Cygwin. A new Windows version is on the road map, which with Microsoft's guidance will be using IO completions ports. At that point there is underneath no difference.
It is also possible to do non-blocking database calls in ADO.NET but be aware of ORM tools such as NHibernate and Entity Framework. They are still very much synchronous.
Synchronous IO (blocking) makes the control flow much clearer and it has for this reason become popular. The reason why computer environments are multithreaded has only superficially to do with this. It is more generally related to time sharing and utilization of multiple CPUs.
Having only a single thread can cause starvation during lengthy operations, which can be related to both IO and complex computations. So, even though the rule of thumb is one thread pr. core when utilizing non-blocking IO, one should still consider a sufficient thread pool size so that simple requests don't get starved by more complex operations if such exist. Multiple threads also allows complex operations to be split easily among multiple CPUs. A single threaded environment like node.js can only utilize multicore processors through more processes and message passing to coordinate action.
I have personally not yet seen any compelling argument to introduce an additional technology such a node.js. However, there may be good reasons but they have in my opinion little to do with servicing a large number of connections through non-blocking IO since this can also be done with ASP.NET.
BTW tamejs can help make your nodejs code more readable similar to the new upcoming .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 可能会是您的最佳选择。
It is easy to understate the cultural difference between the Node.js and ASP.NET communities. Sure, IHttpAsyncHandler exists and it's been around since .NET 1.0 so it might even be good, but all of the code and discussion around Node.js is about async I/O which is decidedly not the case when it comes to .NET. Want to use LINQ To SQL? You kind of can, kind of. Want to log stuff? Maybe "CSharp DotNet Logger" will work, maybe.
So yes, IHttpAsyncHandler is there and if you're really careful you might be able to write an event driven web-service without tripping over some blocking I/O somewhere, but I don't really get the impression a lot of people are using it (and it certainly isn't the prominent way for writing ASP.NET apps). In contrast, Node.js is all about evented I/O, all the code examples, all the libraries and it's the only way people are using it. So if you were going to bet on which one's evented I/O model actually worked all the way through, Node.js would probably be the one to pick.
根据当前时代的技术进步和阅读以下链接，我可以说，这取决于专业知识并根据重要的特定场景选择完美的组合。 NodeJS 正在变得成熟，ASP.NET 方面我们有 ASP.NET MVC、WebAPI 和 SignalR 等来让事情变得更好。
Node.js 与 .Net 性能
salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/" rel="nofollow noreferrer">http://www.salmanq.com/blog/net-and-node-js-性能比较/2013/03/
和
http://www.hanselman.com/blog/InstallingAndRunningNodejsApplicationsWithinIISOnWindowsAreYouMad.aspx
谢谢。
As per current age technology improvements and reading below links, I can say, it is matter of expertise and choosing perfect mix as per the particular scenario that matters. NodeJS is getting mature and ASP.NET side we have ASP.NET MVC, WebAPI, and SignalR etc. to make things better.
Node.js vs .Net performance
http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/
and
http://www.hanselman.com/blog/InstallingAndRunningNodejsApplicationsWithinIISOnWindowsAreYouMad.aspx
Thanks.