异步、非阻塞、事件基体系结构之间有什么区别？

Question

1. ：

有什么区别？

- **Asynchronous**,
- **Non-Blocking**, and
- **Event-base** architectures?

​

event-based)?

• What's

1. 可以是异步的和非阻塞的(而且在编程中最重要的是
2. )：异步、非阻塞和/或事件基(或全部3)?

。

如果你能提供例子，那就太好了。

之所以问这个问题，是因为我读了一篇关于类似主题的伟大的StackOverflow文章，但它没有回答我上面的问题。

Answer 1

异步异步字面意思是不同步。电子邮件是异步的。你发了一封邮件，你就不会指望得到回复了。但它并不是非阻塞的。本质上，它的意思是一种体系结构，其中“组件”相互发送消息，而不需要立即响应。HTTP请求是同步的。发送请求并得到答复。

非阻塞这个术语主要与IO一起使用.这意味着，当您进行系统调用时，它将立即返回，得到任何结果，而不会使线程进入休眠状态(概率很高)。例如，非阻塞的读/写调用会随它们所能做的一切返回，并期望调用者再次执行调用。例如，try_lock是非阻塞调用.只有在获得锁的情况下，它才会锁定。系统调用的通常语义是阻塞。read将等到它有一些数据，并将调用线程进入睡眠状态。

事件基这个词来自libevent。非阻塞的读/写调用本身是无用的，因为它们不会告诉您“什么时候”应该回电话(重试)。select/epoll/IOCompletionPort等是从OS中查找“当”这些调用被期望返回“有趣”数据时的不同机制。libevent和其他这样的库提供了由各种OSes提供的这些事件监视工具的包装器，并提供了一个可以跨操作系统运行的一致的API。非阻塞IO与事件库携手并进.

我认为这些术语是重叠的。例如，HTTP协议是同步的，但是使用非阻塞IO的HTTP实现可以是异步的。同样，像读/写/try_lock这样的非阻塞API调用是同步的(它会立即给出响应)，但是“数据处理”是异步的。

Answer 2

在异步硬件中，代码要求某个实体执行某些操作，并在操作完成时可以自由地执行其他操作；一旦操作完成，该实体通常会以某种方式向代码发出信号。非阻塞架构将记录代码可能感兴趣的自发发生的操作，并允许代码询问这些操作发生了什么，但是代码只有在显式询问这些操作时才会注意到这些操作。当事件自发发生时，基于事件的体系结构将肯定地通知代码。

考虑一个串行端口，代码将从该端口接收1000个字节。

在阻塞读取体系结构中，代码将等待1,000个字节到达或决定放弃。

在异步读取体系结构中，代码将告诉驱动程序它想要1000个字节，并在1000个字节到达时得到通知。

在非阻塞体系结构中，代码可以在任何时候询问有多少字节到达，并且在它认为合适时可以读取任何或所有此类数据，但是它能够知道所有数据何时到达的唯一方法是询问；如果代码希望在第1000个字节到达时在四分之一秒内找到答案，它必须每隔四分之一秒左右检查一次。

在基于事件的体系结构中，串口驱动程序将在任何数据到达时通知应用程序。驱动程序将不知道应用程序需要多少字节，因此应用程序必须能够处理数量小于或大于应用程序所需数量的通知。

Answer 3

因此，要回答你的第一个和第二个问题：

非阻塞实际上等同于异步调用，稍后会得到结果，但当这种情况发生时，您可以做其他的事情。阻塞正好相反。在你继续你的旅程之前，你要等电话回来。

现在，异步/非阻塞代码听起来非常棒，而且确实如此。但我有话要警告。异步/非阻塞在受限制的环境中工作是很好的，例如在移动电话中.考虑有限的CPU /内存。它也有利于前端开发，在前端开发中，代码需要以某种方式对UI小部件做出反应。

异步是所有操作系统需要如何工作的基础--它们在后台为您做了一些事情，当它们完成了您所要求的操作时，它们会唤醒您的代码；当调用失败时，您会被告知它不工作，无论是异常还是某种类型的返回代码/错误对象。

当您的代码要求一些需要一段时间才能响应的内容时，您的操作系统知道它可以忙着做其他事情。您的代码-一个进程，线程或等效，块。您的代码完全忽略了操作系统中正在发生的其他事情，当它等待网络连接建立时，或者当它等待来自HTTP请求的响应时，或者当它等待那个读/写文件时，等等。您的代码可以“简单地”等待鼠标单击。在这段时间里，你的操作系统实际上是无缝地管理、调度和响应“事件”--比如管理内存、I/O (键盘、鼠标)。磁盘、互联网)、其他任务、故障恢复等。

操作系统是他妈的硬核。他们非常善于向程序员隐藏所有复杂的异步/非阻塞内容。这就是大多数程序员是如何用软件达到今天的水平的。现在我们达到了CPU的限制，人们说可以并行地做一些事情来提高性能。这意味着异步/非阻塞似乎是一件非常有利的事情，是的，如果您的软件需要它，我可以同意。

如果您正在编写后端web服务器，请小心进行。记住，你可以以更便宜的价格水平地进行缩放。不过，Netflix / Amazon / Google / Facebook显然是这条规则的例外，这纯粹是因为他们使用较少的硬件成本更低。

我会告诉你为什么异步/非阻塞代码是后端系统的噩梦.

1)它变成了对生产力的拒绝服务.你要想得更多，而且在这过程中你会犯很多错误。

2)反应代码中的堆栈跟踪变得难以辨认--很难知道什么叫做什么、什么时候、为什么和如何。祝您调试顺利。

( 3)你必须更多地思考事情是如何失败的，特别是当许多事情恢复到你发送的方式上时。在旧世界里，你一次只做一件事。

( 4)测试难度大。

( 5)维护起来更难。

6)这是痛苦的。编程应该是一个joy和乐趣。只有受虐狂喜欢痛苦。编写并发/反应性框架的人都是吝啬鬼。

是的，我写过同步和异步。我更喜欢同步，因为99.99的后端应用程序可以通过这个范例。前端应用程序需要反应式的代码，这是毫无疑问的，而且一直是这样的。

是的，代码可以是异步的、非阻塞的和event-based.

• The的，编程中最重要的事情是确保代码在可接受的时间内工作和响应。坚持这一关键原则，你就不会出错。--