【发布时间】：2013-03-13 02:49:46
【问题描述】：
在阅读了几篇关于事件驱动和 nodejs 的帖子后，我看到的唯一优点是事件驱动避免了线程的内存分配，并在可能的情况下用通知代替了轮询。
其他优点都是有争议的：
-
多线程程序比单线程程序更容易出错。
争论：对于网络应用来说，请求是相互独立的，只要处理函数没有副作用；如果所有 IO 部分都由数据库服务器处理，则无需担心多线程。
-
事件驱动的方法不会阻塞 IO，因此可以处理更多的请求。这种优势似乎是事件驱动的最重要特征。在this 示例中，它与医生办公室进行了比较，我认为这是不合适的。
争论：在医生办公室的例子中，接待员不等待病人填写表格，而是在前一个病人填写表格时为其他病人服务。这是一个误导性的例子。
一个。如果我们将患者解释为向服务器发送请求的客户端。服务器当然不会阻止客户在自己的浏览器中填写表格。当客户端完成表单并向服务器发送 http POST 时，服务器将开始工作。在 nodejs 存在之前，Web 已经是一个事件驱动的系统。所以这个例子对于解释服务器端事件驱动编程是无效的。
b.有人会说我们应该把病人填表理解为服务端IO密集型操作。但不同的是：我们不为患者填写表格付费，而是为 IO 密集型手术付费。
所以我的观点是，即使耗时的操作并没有阻塞你当前的线程，也会有其他线程，或者进程或数据库服务器被阻塞。我多次看到 nodejs 可以提供 10k 个并发连接，因为它没有阻塞。我想说的是，如果没有足够的其他线程或进程或服务器来处理耗时的部分，那是不可能的。
在这种情况下，事件驱动无非就是使用 nginx 进行负载均衡，只不过负载均衡是对应用程序的请求进行均衡，而事件驱动是把请求均衡到耗时的操作上，将负载均衡层往后移。这样做的唯一好处是我在这个问题开头提到的两个：1.它避免了线程的内存分配。 2. 尽可能用通知代替轮询。
感谢您阅读到这里，我的问题是：我的理解是否正确？我在论证中犯了什么错误？
【问题讨论】：
-
归根结底，您仍然需要编写处理
"events"的代码。当你应该更多地关注实质时，你似乎开始关注的是风格。"Is my code maintainable, performant, reliable?" -
检查这个问题的答案，因为我认为它可能会增强你的理解：stackoverflow.com/questions/3629784/…
-
@Phairoh 感谢您提供信息。所以我认为基本上我理解它是正确的。通过做异步和回调，任务调度更高效，因为更少轮询更多通知。
标签： multithreading node.js load-balancing event-driven