WebFlux、Reactive编程特性
在阻塞编程模式里,任何一个请求,都需要一个线程去处理,如果io阻塞了,那么这个线程也会阻塞在那,此时会有一个线程卡在那卡10秒。
线程资源是很珍贵的,这种大延迟的场景并发量很难上去,毕竟一个并发就消耗一个线程。
而webflux里面,一个请求进来,除了一些数据封装,其他逻辑都放到worker线程里执行,在io阻塞的时候,实际上是把数据直接写入socket就不管了,不需要消耗一个线程。
一直等到对方发回数据,再拿一个worker线程去处理数据,这中间只需要一些内存保存上下文信息,基本不消耗任何其他资源,这也就是webflux特别推荐的场景:io集中并且延迟较大,并且延迟越大优势体现越明显。
若在非Reactive模式下执行完需要10s,那么用了WebFlux返回给前端的耗时还是10s。
WebFlux真正的意义是,当耗时的,像访问文件或者数据库那样的处理发生时,它可以把使用的线程让渡出来,供其它请求去使用。
所以它提高的是整个系统的吞吐率,而不是单个请求的执行速度(甚至比非Reactive稍慢),JDBC等访问方式也在慢慢朝Reactive过度。
对前端来说,每个请求的处理速度并未变快,但是后端却可以更充分的提高硬件利用率,能处理更多的请求,提高后端系统的整体并发量。
什么webFlux的delay方法没有阻塞线程,因为它的延时处理都交给了ScheduledExecutorService执行器处理,调用delay方法的主线程就直接返回了,
等到延时时间过后,ScheduledExecutorService就会从线程池就获取一个线程来处理延时后的任务逻辑。
通过反应式编程范式,将所有阻塞都修改为类似于delay之于sleep的形式,就能大幅度提升服务性能了。
最后,也是非常重要的一点:异步非阻塞并不会使程序运行得更快。
WebFlux并不能使接口的响应时间缩短,它仅仅能够提升后端服务吞吐量和伸缩性。
SpringWebFlux作为一个异步非阻塞的Web框架,它特别适合应用在IO密集型的服务中,比如微服务网关这样的网络IO密集型应用中。
Reactive and non-blocking generally do not make applications run faster.