在阅读了几篇关于事件驱动和nodejs的帖子之后，我能看到的唯一优势是事件驱动避免了线程的内存分配，并在可能的情况下用通知替换轮询。
其他优点都是有争议的：
多线程程序比单线程更容易出错。
争论：对于Web应用程序，只要处理程序函数没有副作用，请求就彼此独立;如果所有IO部分都由数据库服务器处理，则无需担心多线程。
事件驱动方法不会阻止IO，因此可以处理更多请求。这种优势似乎是事件驱动的最重要特征。在this示例中，它与医生办公室进行了比较，我认为这是不恰当的。
争论：在医生办公室的例子中，接待员不等待患者填写表格，而是在前一位患者填写表格时为其他患者服务。这是一个误导性的例子。
一个。如果我们将患者解释为客户端向服务器发送请求。服务器当然不会阻止客户端在自己的浏览器中填写表单。当客户端完成表单并向服务器发送http POST时，服务器将开始工作。在nodejs存在之前，web已经是一个事件驱动的系统。因此，此示例无法解释服务器端事件驱动编程。
湾有人会说我们应该解释填写表格的患者作为服务器端IO密集型操作。但不同的是：我们不支付患者填写表格，但我们支付IO密集型操作。
所以我的论点是，即使耗时的操作也没有阻止你当前的线程，也会阻塞其他一些线程或进程或数据库服务器。我多次看到nodejs可以服务10k并发连接，因为它没有阻塞。我会说，如果没有足够的其他线程或进程或服务器来处理耗时的部分，那就不可能了。
在这种情况下，事件驱动只不过是使用nginx进行负载均衡，除了负载均衡将请求与应用程序进行平衡，而事件驱动将请求与耗时的操作进行平衡，从而使负载均衡层向后移动。这样做的唯一好处是我在这个问题的开头提到的两个：1。它避免了线程的内存分配。 2.尽可能用通知替换轮询。
感谢您阅读到目前为止，我的问题是：我的理解是否正确？我在论证中犯了什么错误？
答案 0 :(得分：3)
正如ChaosPandion在评论中所说的那样，你似乎陷入了风格。基于事件的编程只是通过不同权衡来管理程序数据流的另一种方式。对于某些应用程序，它使事情变得非常容易，对于其他应用程序（例如CPU驱动的问题），它并不是特别好。
许多应用程序没有任何耗时的操作。在您访问数据库的示例中，这只是等待响应的应用程序（事件）。
基于事件还可以节省大量编程工作，管理线程之间的通信。
有关其他观点，请参阅“concurrency is not parallelism”和concurrency section in Effective Go。