阅读 Spring in action 第 5 版第 11 章，第 11.1.2 节的最后一段
通过接受 Mono 作为输入，立即调用该方法 无需等待从请求正文中解析 Taco。和 因为存储库也是反应式的，它会接受一个 Mono 和 立即返回一个 Flux，从中调用 next() 并返回 生成的 Mono ... 甚至在处理请求之前！
服务如何在请求被处理之前立即返回？这不是违反直觉吗？ 我的意思是在返回响应之前应该先处理请求吗？
【问题讨论】：
标签： spring spring-webflux
这本书有你需要的一切。这是一本写得很好的书，只要确保在实际运行代码时仔细阅读（确保从 Manning 下载源代码）。它将帮助您更好地理解。
来自本书（https://livebook.manning.com/book/spring-in-action-fifth-edition/chapter-11/v-7/6）：
11.1 使用 Spring WebFlux
典型的基于 Servlet 的 Web 框架，例如 Spring MVC，是阻塞的 并且本质上是多线程的，每个连接使用一个线程。作为 处理请求时，从线程池中拉出一个工作线程到 处理请求。同时，请求线程被阻塞，直到它 由工作线程通知它已完成。
因此，阻塞式 Web 框架在以下情况下无法有效扩展 请求量大。缓慢的工作线程中的延迟使事情变得均匀 更糟糕的是，因为工作线程需要更长的时间 返回池以准备处理另一个请求。
在某些用例中，这种安排是完全可以接受的。实际上， 这在很大程度上是大多数 Web 应用程序的开发方式 十多年。但是时代在变，这些网络的客户 应用程序已经从偶尔查看网站的人发展而来 经常消费内容和使用的人的网络浏览器 使用 API 的应用程序。而现在所谓的“互联网 在汽车、喷气发动机、 和其他非传统客户不断交换数据 我们的 API。随着越来越多的客户使用我们的网络 应用程序，可扩展性比以往任何时候都更重要。
异步网络框架，相比之下，实现更高的可扩展性 使用更少的线程——通常每个 CPU 内核一个。通过应用一种技术 称为事件循环（如图 11.1 所示），这些 框架能够处理每个线程的许多请求，使得 每个连接的成本要便宜得多。
在事件循环中，一切都作为事件处理，包括 来自密集操作的请求和回调（例如数据库和 网络操作）。当需要昂贵的操作时，事件循环 为要并行执行的操作注册回调 而事件循环继续处理其他事件。 当 操作完成，完成被视为一个事件 事件循环与请求相同。因此，异步 web 框架能够在大量请求下更好地扩展 更少的线程（从而减少线程管理的开销）。
阅读本节的其余部分，它将澄清任何其他问题。
另外，检查反应堆https://github.com/reactor/reactor-core
如果您仍然遇到困难，请提供完整示例https://www.baeldung.com/spring-webflux
【讨论】：