java SpringBoot Reactor整合
网上资料不多而且太杂这里整合了一下方便以后查阅
SpringBoot中的Http应用---WebFlux
https://blog.51cto.com/13884944/2314600
SpringBoot——Spring Reactor Web
https://blog.csdn.net/No_Game_No_Life_/article/details/101450810
为了应对高并发的服务器端开发，在2009年的时候，微软提出了一个更优雅地实现异步编程的方式 —— Reactive Programming，中文称反应式编程。随后，其它技术也迅速地跟上了脚步，像 ES6 通过 Promise 引入了类似的异步编程方式。Java 社区也没有落后很多，Netflix 和 TypeSafe 公司提供了 RxJava 和 Akka Stream 技术，让 Java 平台也有了能够实现反应式编程的框架。
其实，在更早之前，像 Mina 和 Netty 这样的 NIO 框架其实也能搞定高并发的服务器端开发任务，但这样的技术相对来说只是少数高级开发人员手中的工具。对于更多的普通开发者来说，难度显得大了些，所以不容易普及。
很多年过去了，到了2017年，虽然已经有不少公司在实践反应式编程。但整体来说，应用范围依旧不大。原因在于缺少简单易用的技术将反应式编程推广普及，并同诸如 MVC 框架、HTTP 客户端、数据库技术等整合。
终于，在2017年9月28日，解决上面问题的利器浮出水面 —— Spring 5 正式发布。Spring 5 其最大的意义就是能将反应式编程技术的普及向前推进一大步。而作为在背后支持 Spring 5 反应式编程的框架 Reactor，也相应的发布了 3.1.0 版本。
java 1.4起，jdk支持了NIO(NEW IO)，因NIO(os nonblocking)的非阻塞式工作方式，让应用服务器可以极大的优化线程模型，相比传统的阻塞式IO线程和链路一对一的模式，NIO只需少量的线程即可处理所有的链路，这对广大的java开发者来说是一大福音，基于NIO能开发出更高效的网络应用。
然而使用JDK原生的api开发NIO，编程模型是非常复杂的，开发者需要理解Selector、Channel、ByteBuffer三大组件，此外JDK原生NIO实现上还存在一些稳定性问题。netty把三大组件交互代码封装在框架内部有效的简化了编程模型让使用者能够更高效的开发出NIO网络应用，保障了系统的稳定性。
一篇文章读懂阻塞，非阻塞，同步，异步
https://www.jianshu.com/p/b8203d46895c
IO多路复用的三种机制Select，Poll，Epoll
https://www.jianshu.com/p/397449cadc9a
Java NIO、Reactor、Netty
https://blog.csdn.net/ZXW601498616/article/details/88839863
使用前提
1、使用 Reactor，Java 版本最低需要 Java 7。
若要充分发挥函数组件潜力，需要 Java 8 Lambdas 支持。采用 Spring，Clojure 和 Groovy 扩展作为后备。
2、JVM 支持非安全访问时 Reactor 可满负荷运行 (比如不是Android的情况)。
若没有非安全访问策略，基于环形缓冲区的所有特性都不起作用。
3、Reactor 在 Maven Central 中以传统 JAR 格式打包，你可以用你所习惯的构建工具在任何 JVM 工程中安装该依赖。
https://www.cnblogs.com/doit8791/p/7461479.html
第一个阶段：服务器用一个while循环，不断监听端口是否有新的套接字连接。
缺点：无法并发，效率太低，请求可能长时间阻塞。
第二个阶段：使用多线程，connection per thread，即每一个连接用一个线程处理。
缺点：在一个线程里只能处理一个socket，如果连接数太高，系统无法承受，而且，线程的反复创建-销毁也需要代价。
第三阶段：使用线程池。
缺点：线程同步的粒度太大了，限制了吞吐量。
第四阶段：Reactor阶段。把一次连接的操作分为更细的粒度或者过程，这些更细的粒度是更小的线程。整个线程池的数目会翻倍，但是线程更简单，任务更加单一。
在Reactor中，这些被拆分的小线程或者子过程对应的是handler，每一种handler会出处理一种event。这里会有一个全局的管理者selector，我们需要把channel注册感兴趣的事件，那么这个selector就会不断在channel上检测是否有该类型的事件发生，如果没有，那么主线程就会被阻塞，否则就会调用相应的事件处理函数即handler来处理。
优点
1）响应快，不必为单个同步时间所阻塞，虽然Reactor本身依然是同步的；
2）编程相对简单，可以最大程度的避免复杂的多线程及同步问题，并且避免了多线程/进程的切换开销；
3）可扩展性，可以方便的通过增加Reactor实例个数来充分利用CPU资源；
4）可复用性，reactor框架本身与具体事件处理逻辑无关，具有很高的复用性；
缺点
1）相比传统的简单模型，Reactor增加了一定的复杂性，因而有一定的门槛，并且不易于调试。
2）Reactor模式需要底层的Synchronous Event Demultiplexer支持，比如Java中的Selector支持，操作系统的select系统调用支持，如果要自己实现Synchronous Event Demultiplexer可能不会有那么高效。
3） Reactor模式在IO读写数据时还是在同一个线程中实现的，即使使用多个Reactor机制的情况下，那些共享一个Reactor的Channel如果出现一个长时间的数据读写，会影响这个Reactor中其他Channel的相应时间，比如在大文件传输时，IO操作就会影响其他Client的相应时间，因而对这种操作，使用传统的Thread-Per-Connection或许是一个更好的选择，或则此时使用Proactor模式。
这次，我们把目光转向 SpringBoot，在SpringBoot 2.0版本之后，提供了对响应式编程的全面支持。因此在升级到 2.x版本之后，便能方便的实现事件驱动模型的后端编程，这其中离不开 webflux这个模块。其同时也被 Spring 5 用作开发响应式 web 应用的核心基础。那么, webflux 是一个怎样的东西？
Webflux
Webflux 模块的名称是 spring-webflux，名称中的 Flux 来源于 Reactor 中的类 Flux。该模块中包含了对 响应式 HTTP、服务器推送 和 WebSocket 的支持。
Webflux 支持两种不同的编程模型：
- 第一种是 Spring MVC 中使用的基于 Java 注解的方式，一个使用Reactive风格的Controller如下所示：
@RestControllerpublic class EchoController {
@GetMapping("/echo")
public Mono<String> sayHelloWorld() {
return Mono.just("Echo!");
}}
- 第二种是 基于 Java 8 的 lambda 表达式的函数式编程模型。
- SpringBoot、Webflux、Reactor 可以说是层层包含的关系，其中，响应式能力的核心仍然是来自 Reactor组件。由此可见，掌握Reactor的用法 必然是熟练进行 Spring 响应式编程的重点。
tomcat的线程模型
Tomcat支持四种接收请求的处理方式：BIO、NIO、APR和AIO
- NIO 同步非阻塞，比传统BIO能更好的支持大并发，tomcat 8.0 后默认采用该模型。 使用方法(配置server.xml)：
改为 protocol="org.apache.coyote.http11.Http11NioProtocol" - BIO 阻塞式IO，tomcat7之前默认，采用传统的java IO进行操作，该模型下每个请求都会创建一个线程，适用于并发量小的场景。 使用方法(配置server.xml)：protocol =" org.apache.coyote.http11.Http11Protocol"
- APR tomcat 以JNI形式调用http服务器的核心动态链接库来处理文件读取或网络传输操作，需要编译安装APR库。 使用方法(配置server.xml)：protocol ="org.apache.coyote.http11.Http11AprProtocol"
- AIO 异步非阻塞 (NIO2)，tomcat8.0后支持。多用于连接数目多且连接比较长（重操作）的架构，比如相册服务器，充分调用OS参与并发操作，编程比较复杂，JDK7开始支持。 使用方法(配置server.xml)：protocol ="org.apache.coyote.http11.Http11Nio2Protocol"
Jdbc
https://blog.csdn.net/weixin_47067712/article/details/106267418