前言:
今天大家对“webflux 分页”大致比较关注,大家都想要分析一些“webflux 分页”的相关资讯。那么小编同时在网上网罗了一些关于“webflux 分页””的相关内容,希望看官们能喜欢,姐妹们快快来了解一下吧!文章来源:
作者:瑾年
前言
在当今互联网飞速发展的时代,业务需求不断的更新和产品的迭代给系统开发过程和编程模式也带来巨大挑战,Spring Cloud微服务也随之应用而生,从springboot1.x到springboot2.x,springcloud也提供了相应的集成,而特别引人注目的是spring5的诞生确实为java编程模式带来重大革命。
Spring5框架集成的project Reactor响应式开发框架为构建响应式RESTful服务、响应式数据访问组件、响应式消息通信组件、响应式微服务带来更好的便利之处。
接下来的文章会从“响应式编程模型和Reactor框架”,“构建响应式RESTful服务”,“构建响应式数据访问组件”、“响应式消息通信组件”、“响应式微服务”等方面全面了解掌握如何利用Reactor框架中的Mono和Flux两个核心组件,如何利用Spring5中的Spring WebFlux支持使用注解式编程模型和函数式编程模型构建响应式RESTful服务。
同时也会全面讲解springboot中WebFlux,如何利用Spring Data提供的 spring Reactive Data 构建响应式数据访问组件,如何使用Reactiv Spring Cloud Stream实现响应式消息通信组件。
通过使用 Spring Cloud框架实现响应式微服务,我们将会从服务发现、服务治理、负载均衡、服务容错、服务网关、服务监控等方面全面了解响应式微服务的核心组件及其实现方案。
在我们全面了解和掌握构建响应式微服务后将会有实际的项目源码供大家学习交流。
作者的水平和经验也有限,文章中难免会有纰漏之处和错误之处,恳请各位看官理解、批评和指正。
响应式编程模型和Reactor框架
响应式编程模型(简称RP Reactive Programming)是一种全新的编程模型,包含流、背压等核心概念。
百度百科解释:响应式编程是一种面向数据流和变化传播的编程范式。这意味着可以在编程语言中很方便地表达静态或动态的数据流,而相关的计算模型会自动将变化的值通过数据流进行传播。
Reactor 框架是 Pivotal 公司(开发 Spring 等技术的公司)开发的,实现了 Reactive Programming 思想,符合 Reactive Streams 规范(Reactive Streams 是由 Netflix、TypeSafe、Pivotal 等公司发起的)的一项技术。其名字有反应堆之意,反映了其背后的强大的性能。
1.1响应式编程模型
首先从传统编程模型到响应式编程模型我们需要一个转变。我们将从简单的接口定义实力开始,引出响应式编程中的一系列核心概念。
例如我们定义一个属于数据访问层的接口访问use对象数据列表:
public interface userMapper{ List<User> getUsers();}
从上面的接口我们可以看出User对象可能是一个也可能是成千上万个,在真实数据返回之前,我们无法知道具体的对象个数,显然在日常开发中我们认为这种方式定义是有问题的,如果返回的数据量过大,则可能会导致内存溢出等问题,所以我们在日常开发中对返回的数据做了一下调整:
public interface userMapper{ Page<User> getUsers(Page page);}
可以看到我们传入了办函分页的Page对象,返回一个分页结果对象Page。
在这个分页机制当中,我们一般需要传入每一页的大小参数,也就是我们所理解的pageSize,以及我们想要获取的页码参数(pageNum)。也就是说每次请求返回对象的个数是固定的。
那么我们在响应式编程中该如何处理这种数据返回呢?
在响应式编程模型中,这件事情就会变的简单很多。我们将会返回一个容器,让客户端自己去选择需要的对象个数,客户端想要多少该容器就会为他返回多少。为了达到效果代码可以这样书写:
public interface userMapper{ Flux<User> getUsers();}
在这里我们引入了一个全新的对象模型Flux,这是Reactor框架中特有的一个对象类型,它包含0到n个元素的异步序列。我们将会在《1.2Reactor框架》中详细讲解Flux。
1.1.1流
1.什么是流
简单的说流就是由生产者生产给一个或者多个消费者消费的元素的序列。像这种生产者/消费之组成的模型被称为Source/Sink模型或者发布者/订阅者模型。
关于流的处理一般有两种最基本的实现机制,一种是推模型另一种是拉模型。推模型就是由生产者推送给消费者,拉模型是由消费者主动向生产者拉取元素。
除此之外关于流的处理还有一个同步和异步的区别,如果说消费者请求生产者的元素不可用时就必须进入等待直到元素可用,这种情况我们称之为同步请求。解决这种现象就是在两端进行异步处理,生产者可以在消费者请求元素之后处理其他业务,当元素准备就绪时由生产者再异步发送给消费者。
2.流量的控制
我们再来假设一个场景,假如生产者发出的数据速度和消费者处理数据的速度不同,消费者应该采取特定的cel来消费数据流中的数据。通常情况下,如果消费者处理数据的速度快,一般不会有问题,反之,如果不进行流量的控制就会出现消费者会被生产者快速生产的数据所淹没。一般情况下流量的控制有4种情况:
a.节流
节流很简单,就是消费者直接丢弃无法消费的元素。
b.使用缓冲区
当生产者生产的数据速度比消费者处理数据的速度快时,消费者可以采用一个边缘界缓冲区来保存快速传入的元素。
缓冲区的作用相当于在生产者和消费者之间添加了保存并转发的一中机制,把生产者发出的数据暂时存储起来供消费者慢慢消费。
c.调用栈阻塞
调用栈阻塞是最直接的方法就是同步线程。相当于很多车行驶在同一条公路上,儿公路只有一条车道,那么排在前面的车就挡住了后面车的道路,只能等待前面的车行驶通过后撤才可以行驶。
d.使用背压
背压是一个全新的概念,意思也很明确,就是消费者需要多少生产者就生产多少,既不会出现生产者生产数据的速度比消费者过快,也不会出现生产者生产数据速度比消费者消费数据速度过慢的现象。类似于我们在银行柜台办理业务一样,只被叫好的人才可以去办理业务。
小结
本章节关于响应式编程模型和Reactor框架就暂时讲解到这里,目前我们提出了很多概念都需要加强理解,下一节我们将会全面讲解“背压”和“响应式流”这也是做好响应式微服务的关键所在。
前面几节的文字描述会比较多,但这也是我们详细了解响应式编程模型的关键和基础,希望大家坚持。
标签: #webflux 分页