甚至在处理请求之前?

阅读Spring in action第五版第11章,第11.1.2节的最后一段

  

通过接受Mono作为输入,该方法将立即被调用   无需等待Taco从请求正文中解决。和   因为存储库也是反应性的,所以它将接受Mono和   立即返回磁通,从中调用next()并返回   产生的Mono…甚至在处理请求之前!

在处理请求之前,服务如何立即返回?那不是违反直觉的吗? 我的意思是应该先处理请求,然后再返回响应?

gansinimabi 回答:甚至在处理请求之前?

这本书包含您需要的一切。这是一本写得很好的书,只需确保在实际运行代码的同时认真阅读(确保从Manning下载源代码)。它将帮助您更好地理解。

摘自本书(https://livebook.manning.com/book/spring-in-action-fifth-edition/chapter-11/v-7/6):

Event Loop

  

11.1使用Spring WebFlux

     

典型的基于Servlet的Web框架(例如Spring MVC)正在阻塞   本质上是多线程的,每个连接使用一个线程。如   处理请求后,将工作线程从线程池中拉至   处理请求。同时,请求线程被阻塞直到   由工作线程通知已完成。

     

因此,在以下情况下,阻止式Web框架无法有效扩展   大量请求。慢的工作线程中的延迟使事情变得均匀   更糟糕的是,因为工作线程需要花费更长的时间   返回到池中以准备处理另一个请求。

     

在某些用例中,这种安排是完全可以接受的。事实上,   这很大程度上是大多数Web应用程序开发良好的方式   十多年来。但是时代在变,这些网络的客户   人们偶尔浏览以下网站上的应用程序的数量有所增加   经常浏览内容并使用的人的Web浏览器   使用API​​的应用程序。如今,所谓的“互联网   “物联网”中,甚至在汽车,喷气发动机,   和其他非传统客户正在不断地与   我们的API。随着越来越多的客户使用我们的网站   应用程序,可扩展性比以往任何时候都重要。

     相反,

异步Web框架实现了更高的可扩展性   具有更少的线程-通常每个CPU内核一个线程。通过应用技术   这些称为事件循环(如图11.1所示),   框架能够处理每个线程的许多请求,这使得   每次连接的成本要便宜得多。

     

在事件循环中,一切都作为事件处理,包括   密集操作(例如数据库和   网络操作)。当需要进行昂贵的操作时,事件循环   注册该操作要并行执行的回调   事件循环继续进行以处理其他事件。 当   操作完成后,系统会将完成视为事件   事件循环与请求相同。因此,异步网络   框架能够在大量请求下更好地扩展   更少的线程(从而减少了线程管理的开销)。

阅读本节的其余部分,它将澄清其他问题。

还要检查Reactor https://github.com/reactor/reactor-core

举一个完整的例子,如果您仍然遇到困难https://www.baeldung.com/spring-webflux

本文链接:https://www.f2er.com/3163920.html

大家都在问