阻塞http调用期间的反应性编程基础

Question

作为刚刚开始研究反应性编程的人，我有一个问题似乎没有在其他地方得到回答：

阻塞调用(即来自前端的http请求)是如何真正利用这个概念的？

我的理解是这样的，如果它是错误的，那么问题就在于纠正：

1. 前端用户点击一个按钮，然后进行ajax调用。
2. 然后浏览器制作一个普通的http
3. 后端，然后本质上仍然是一个阻塞服务器。这样，直到completes
4. Reactive特性出现时，http响应才会被提供回来，这样它就不用在1个线程中处理来自前端的1个请求，而是通过保存何时执行什么的回调来减少线程的使用。在某种程度上利用库API来管理这种复杂性。
5. 在一天结束时，我们从前端发出的http调用，仍然是一个阻塞调用。与基于线程的并发性不同的是，我们将阻塞调用委托给其他线程(实际上，为什么使用的线程较少？)例如DB调用、外部Rest调用等，最后，我们阻塞--等待它们全部完成.

这些假设正确吗？

更进一步让我们对基本的理解是正确的，是什么使这种方法更适合于基于线程的方法呢？

假设在我的情况下，预期的并发用户并不是真的那么大，500人同时。

Answer 1

你的假设大体上是正确的。这几乎是任何一个相当现代的网络应用程序，无论是vertx，micronaut还是spring+都是这样工作的。

如果用户希望请求是同步的(这意味着他在等待它完成)，那么服务器必须以阻塞的方式执行它，但不阻塞它自己，这样其他用户也可以并行地激发他们的请求。

它本身就是构建代码的方式，即在RxJava中而不是在回调(地狱)中使用方法链，但它一般不会改变请求处理的性质。