1.一直在用SpringMVC？不妨认识下SpringWebflux
2.java最常用的技术栈有哪些
3.（WebFlux）003、多数据源R2dbc事务失效分析
4.反应式Web架构SpringWebFlux详解（上）
5.反应式Web架构SpringWebFlux详解（下）
一直在用SpringMVC？不妨认识下SpringWebflux
Spring-webflux是Spring框架在5.0版本后提供的响应式编程风格的web开发框架。它包含spring-framework和spring mvc，运行在包括Netty、Undertow和Servlet容器在内的多个环境。你可以在项目中同时使用spring-webmvc和spring-webflux，亿启MACD指标源码或者选择其中一个来开发web应用。
响应式编程意味着异步非阻塞的流式编程。在API调用获取数据时，无需阻塞等待数据返回，而是当数据可用时进行通知。这提高了系统吞吐量，因为CPU在等待数据时可以执行其他任务。
Reactor框架是Spring-webflux的基础，提供了Mono和Flux两种API类型。Spring-webflux能够与其他响应式框架并存，如RxJava。选择使用Spring-webmvc还是Spring-webflux取决于应用需求。Spring-webflux支持在各种服务器上运行，比如Netty、Undertow等，并默认使用Netty，因为Netty是基于非阻塞模型的。
与Spring-webmvc相比，Spring-webflux采用非阻塞的庄线指标源码并发模型。Webmvc基于Servlet，实现为阻塞式IO，使用线程池处理请求，限制了系统的吞吐量。而Spring-webflux基于NIO框架，如Netty，使用很少的几个工作线程就能处理请求，无需阻塞等待，CPU资源得到更有效利用。
Spring-webflux提高的是并发处理请求的能力，而不是程序执行速度。代码示例展示，使用Springboot构建一个webflux应用非常简单，只需添加依赖，并定义对象和控制器。通过RouterFunctions.route().GET()方法声明路由，处理HTTP请求。Spring-webflux默认使用Netty提供HTTP服务，项目启动后访问指定URL即可验证应用正常运行。
java最常用的技术栈有哪些
1、JDK。JDK的版本现在大部分转移到了8，超前一点的使用。在OracleJDK和OpenJDK之间推荐使用OpenJDK，长安引力软件源码避免引起不必要的商业纠纷。AmazonCorretto、AlibabaDragonwell都不错。
2、Web框架。主流还是Servlet系列的SpringMVC为主。Structs应该只有老项目在用。响应式框架SpringWebflux开始进入视野，尝试的人、问的人逐渐多了起来。
3、Web容器。目前应该还是Tomcat最多，但是近几年红帽的Undertow也起来了，Jetty实际生产并没有优势，测试可能会用。有能力的公司会选择Netty自行实现高性能的Web容器。
4、ORM框架。现在Mybatis在国内依然是老大的地位，国外却很少有相关的教程。其次是JPA体系，主要包括SpringDataJPA、Hibernate。哪里有ubuntu源码
5、Spring。谈到Java离不开Spring，Spring生态的统治地位依然不可动摇。目前单体应用还是SpringBoot一把梭，微服务SpringCloud体系还是占绝对优势。
（WebFlux）、多数据源R2dbc事务失效分析
在项目改造过程中，我们将SpringMVC替换为SpringWebflux，同时将Mybatis升级为R2dbc。项目进展顺利，直到新需求引入MongoDb，问题浮现。面对Mysql和MongoDb的多数据源挑战，事物操作出现异常。本文将深入分析问题原因与解决方案。
在本地测试时，强烈推荐使用虚拟机和Docker安装MySql与MongoDb，以避免Mac直连Docker带来的麻烦。SpringBoot版本为2.6.，本文基于已集成R2DBC与MongoDb的环境。
首先，我们创建了一个测试库r2dbc_test，包含user表。源码交付相关资料引入R2dbc并进行基本测试，实现事务操作，确保数据完整性。测试结果显示，R2dbc事务操作正常，当尝试删除并插入数据时，期望的异常和数据状态得到验证。
接着引入MongoDb，并开启事务支持。根据官方文档，除非手动配置MongoTransactionManager，否则事务支持默认禁用。在项目中添加相应代码，为Webflux环境配置MongoDB事务。然而，引入MongoDb后，事务操作再次出现问题，未按预期回滚。
为了解决此问题，我们深入分析了事务失效的原因。经过排查，发现事务管理器未能正确初始化，导致TransactionalOperator无法正常工作。通过查看源码，发现R2dbcTransactionManager的初始化依赖于是否存在ReactiveTransactionManager。由于MongoDb事务已先期初始化，导致R2dbcTransactionManager未能正确创建，从而影响了事物操作。
为解决此问题，我们采取了以下措施：创建两个配置类，分别为MongoConfig和R2dbcConfig，用于自定义事务管理器的初始化。通过别名方式创建两个TransactionalOperator，确保R2dbcTransactionManager的正确初始化。经过验证，设置正确的名称后，事务操作恢复正常，数据回滚验证成功。
本文提出了手动验证的方法，并指出了使用日志记录作为辅助工具的快捷途径。通过日志，可以清晰地追踪事务创建与回滚过程，验证操作的有效性。总结而言，在面对新工具和多数据源时，应充分实验、验证结果，面对问题时保持冷静，逐步解决问题。如有疑问，欢迎指正与交流。
反应式Web架构SpringWebFlux详解（上）
本文主要介绍了反应式Web架构SpringWebFlux的基本原理，与Servlet架构的对比以及实现机制。反应式架构之所以需要存在，是为了解决在高并发场景下，Servlet架构中的线程阻塞和CPU资源浪费问题。传统Servlet架构下，处理大量请求时，线程资源消耗大且频繁切换消耗CPU，而反应式架构通过非阻塞的编程模型，实现了事件驱动，使得请求的线程可以及时释放，等待外部交互完成后再重新获取资源处理其他请求，大幅提高了硬件资源的使用效率。
核心诉求在于利用发布订阅设计模式实现非阻塞的请求处理，同时保证流的组合性和可维护性，以及订阅者的反馈调节能力。SpringWebFlux通过底层的Reactor-Netty库实现了事件循环机制，使得单个/少量线程能够在事件循环中不断获取流程发布者处理事件、注册订阅者回调并执行事件，极大地提高了硬件资源的利用效率。
反应式架构的特点包括必须的订阅机制和非阻塞的back pressure，前者确保事件的顺序处理，后者则通过控制事件的速率来避免资源的过度消耗。流的组合性和可维护性体现在发布者和订阅者之间的交互上，能够灵活地支持事件的响应和结果的反馈。
在选择命令式还是反应式架构时，需要考虑到业务场景、性能需求和团队的熟悉度。反应式架构在高并发、流媒体支持和实时数据处理方面有明显优势，但集成外部库和维护成本相对较高。在产品涉及大量高并发场景或流媒体平台，且团队有足够时间适应反应式开发时，使用反应式架构搭建服务是值得考虑的。在其他情况下，传统命令式架构可能更为合适。
为了验证反应式架构的资源利用效率，文章提供了一个简单的WebFlux示例，展示了在模拟耗时外部交互场景下，反应式架构能够及时释放线程，而传统方式则会持续占用线程资源，导致高并发场景下的表现不佳。同时，文章还提到了数据库外部交互的相关包引入和前文的SpringReactive下的数据库交互内容。
参考资料包括Servlet和Reactive架构的选择、Spring WebFlux概述、Spring WebFlux和Reactor的线程模型、Spring Data Relational R2DBC、Reactor参考、Spring WebFlux并发机制、反应式架构中的back pressure机制、RxJava Wiki以及Spring WebFlux/Reactive常见问题集。
反应式Web架构SpringWebFlux详解（下）
介绍反应式Web架构SpringWebFlux的进阶使用，包括组合运算、冷热发布、合并广播、批处理、并行与上下文。
在组合运算中，通过指定手写方法变量，可将常用操作与其他业务分离，提高代码复用性，使用transform或transformDeferred实现操作延迟计算，满足不同订阅的处理需求。
冷热发布中，冷发布为每个订阅生成数据，热发布则不受订阅影响，后进入的订阅无法观测到之前数据。热发布示例代码展示其特性。
合并广播允许在订阅前执行其他操作，ConnectableFlux提供合并广播功能，实现订阅的灵活控制，可自定义触发逻辑。
批处理通过Grouping、Windowing和Buffering操作，将序列元素重新聚合，方便后续业务处理，示例代码展示操作方法。
并行处理使用.parallel和Schedulers.parallel结合，实现任务并行执行，提高高并发场景下的处理效率。
反应式框架中的上下文问题与传统命令式编程不同，线程处理多个请求时，使用Context替代ThreadLocal处理请求生命周期中的数据存储需求。
SpringWebFlux、Reactor和RxJava的相关文档提供详细参考，用于深入理解和实践。