反应堆响应式编程初探
起源
Reactor响应式编程起源于数据流和变化的传播概念,其核心概念是由底层的执行模型通过数据流自动传播变化。这种编程范式最早由.NET平台上的Reactive Extensions (Rx)库实现,后来迁移到Java平台后,产生了著名的RxJava库,并衍生出Reactor等响应式编程库。Reactor是Pivotal旗下的项目,与Spring框架有着紧密的联系,是Spring WebFlux等响应式模块的“御用”响应式流。
应用场景
Reactor响应式编程的用途广泛,主要应用场景包括:
Web应用程序:在处理高并发请求时,Reactor提供了一种基于事件的模型,能更高效地处理并发请求,并在I/O操作上提高效率。
数据库查询:Reactor可用于异步数据库查询,以更好地处理高并发负载,显著提高性能和可伸缩性。
网络编程:特别是在处理高并发连接时,Reactor的反应式编程模型能更好地处理连接和数据传输,提高网络应用程序的性能和可伸缩性。
优点
Reactor响应式编程的优点主要体现在以下几个方面:
异步非阻塞:Reactor提供了一种异步、非阻塞的编程模型,使得应用程序能够更高效地处理事件驱动的场景,避免了传统同步阻塞模型中的线程等待和资源浪费。
高性能:通过数据流自动传播变化,Reactor能够减少不必要的计算和资源消耗,从而提高应用程序的性能。
可伸缩性:Reactor的响应式编程模型使得应用程序能够更好地处理高并发场景,轻松应对流量增长带来的挑战。
简洁易用:Reactor提供了流畅的API和使用lambdas的便利,使得开发者能够更简洁地编写代码,同时处理同步或异步操作,对数据进行各种转换。
总的来说,Reactor响应式编程是一种高效、高性能、可伸缩的编程范式,适用于处理各种事件驱动的应用程序场景。
Project Reactor核心接口
Reactor项目核心为reactor-core,一个基于Java8的响应式流标准实现,实现了reactive streams标准。
reactive streams标准核心接口有四个:
Publisher
Subscriber
Subscription
Processor<T,R>
其中最重要的接口为Publisher,代表了一个响应式的流。
Publisher核心实现为Flux和Mono。
Flux
Flux代表了一个可以返回0…N个元素的响应式流。
该流起始于subscribe信号,根据request信号持续返回数据,结束于completion信号或者error信号。
Mono
Mono 也是标准的Publisher的实现,代表了一个可以返回0或1个元素的数据流。
该流接收到onComplete时返回一个元素并结束,接收到onError信号时返回0个元素并结束。
Mono可以用于表示无数据返回的异步流程,如等同于Runnable的概念,此时可以使用Mono。
参考文献
Project Reactor学习(1)–核心接口简介
:https://zhuanlan.zhihu.com/p/35964846
Reactor 3 Reference Guide:https://projectreactor.io/docs/core/release/reference/#flux
上一篇: 2023 如何使用国内手机号码注册 Google(谷歌账户
下一篇: 谷歌支付系统 - 金块
推荐阅读
-
反应堆响应式编程初探
-
趣谈留言队列,搞清楚留言队列到底是什么!-说到消息队列,洪觉大概能猜到人们听到消息队列的反应,大致可以分为以下几类人。 第一类人,懵懵懂懂,刚上大学接触编程,还没用过消息队列,甚至还以为消息队列就是代码里面要新建一个List之类的;第二类人,听过消息队列,了解消息队列,但具体是什么还不是太明白,只知道一说到消息队列,脑海里马上出现了三组词,削峰、异步、解耦;第三类人,用过消息队列,对它有一定了解,但不知道为什么要这样设计,消息队列有什么样的前世今生,是如何演化到现在的模式的?**第四类人,已经对消息队列有了足够的了解,可以阅读本帖作为复习和温习。**你属于哪一类?无论你对消息队列了解多少,读完这篇文章后,我相信你都会有所收获。 什么是消息队列?我们为什么要使用消息队列?真的只是因为它看起来很勉强、很常用吗?当然不是,一项技术的出现往往是为了解决某种痛点,我们就从这个痛点出发,看看消息队列到底是为了解决什么问题而诞生的。 相信大家在工作之前,或者工作中接触单片机的次数会多一点,不管什么业务都一股脑塞进一个系统里,这种情况下接触消息队列的场景会比较少。但随着业务的增长,量上去了,单机系统就很难维护了,也扛不住并发量的增长,就需要把原来的单体应用拆分成多个服务。例如,牛奇网采用分布式架构,将原来的单体系统拆分成用户服务、题库服务、求职服务、论坛服务等,每个分布式节点都有一个集群,保证高可用性。 那虽然在这样的微服务架构下,如果某个核心业务并发量过大,系统就扛不住了。比如淘宝、淘票票、拼多多、京东等电商场景中的支付场景,你在某宝下单并支付后,调用支付服务,完成支付后,还需要更新订单的状态,这个时候就需要调用订单服务,那我们平时也下单,除了简单完成这些操作外,还会给你相应的积分;商家也会收到订单消息,并给您发送旺旺消息,确认订单无误;同时,也会给您发送消息,确认订单无误。确认订单无误;同时您还可以查看您的物流状态;还有系统为了给您推荐更适合您的商品,会根据您的订单做类似的推荐等等,我说的这些都是当我们下单后,肉眼可以感知到系统所做的动作。 **一个支付动作如果还需要调用那么多服务,等他们响应成功,最后再告诉用户你支付成功了,用户在系统中的整个体验会非常糟糕。**设想一下,假设请求服务+处理请求+响应总共需要 50ms,我们上面列出的场景:支付服务、订单服务、积分服务、商家服务、物流服务、推荐服务,总共需要 300ms。
-
Swift 响应式编程:简化 KVO 观察和 UI 事件处理 | 《开源日报》第 110 期
-
玩转 Android架构:MVI模型的入门指南 - 结合响应式编程、单向数据流与唯一稳定数据源(下集)
-
函数式编程初探:C语言为什么不能算是函数式语言?
-
实战指南:如何将久草Spring Boot和Lettuce在线集成——响应式编程的基础教程