Reactor

1、引言 Netty 是一个广受欢迎的异步事件驱动的Java开源网络应用程序框架，用于快速开发可维护的高性能协议服务器和客户端。 本文基于 Netty 4.1 展开介绍相关理论模型，使用场景，基本组件、整体架构，知其然且知其所以然，希望给大家在实际开发实践、学习开源项目方面提供参考。 3、JDK 原生 NIO 程序的问题 JDK 原生也有一套网络应用程序 API，但是存在一系列问题，主要如下： 1）NIO 的类库和 API 繁杂，使用麻烦：你需要熟练掌握 Selector、ServerSocketChannel、SocketChannel、ByteBuffer 等。 2）需要具备其他的额外技能做铺垫：例如熟悉 Java 多线程编程，因为 NIO 编程涉及到 Reactor 模式，你必须对多线程和网路编程非常熟悉，才能编写出高质量的 NIO 程序。 3）可靠性能力补齐，开发工作量和难度都非常大：例如客户端面临断连重连、网络闪断、半包读写、失败缓存、网络拥塞和异常码流的处理等等。NIO 编程的特点是功能开发相对容易，但是可靠性能力补齐工作量和难度都非常大。 4）JDK NIO 的 Bug：例如臭名昭著的 Epoll Bug，它会导致 Selector 空轮询，最终导致 CPU 100%。官方声称在 JDK 1.6 版本的 update 18 修复了该问题，但是直到 JDK 1.7

在学习Reactor模式之前，我们需要对“I/O的四种模型”以及“什么是I/O多路复用”进行简单的介绍，因为Reactor是一个使用了同步非阻塞的I/O多路复用机制的模式。 I/O的四种模型 I/0 操作 主要分成两部分 ① 数据准备，将数据加载到内核缓存 ② 将内核缓存中的数据加载到用户缓存 Synchronous blocking I/O Typical flow of the synchronous blocking I/O model Synchronous non-blocking I/0 Typical flow of the synchronous non-blocking I/O model Asynchronous blocking I/0 Typical flow of the asynchronous blocking I/O model (select) Asynchronous non-blocking I/0 Typical flow of the asynchronous non-blocking I/O model 堵塞、非堵塞的区别是在于第一阶段，即数据准备阶段。无论是堵塞还是非堵塞，都是用应用主动找内核要数据，而read数据的过程是‘堵塞’的，直到数据读取完。 同步、异步的区别在于第二阶段，若由请求者主动的去获取数据，则为同步操作，需要说明的是

本文链接：https://blog.csdn.net/king866/article/details/54427447 Netty是一个高性能、异步事件驱动的NIO框架，它提供了对TCP、UDP和文件传输的支持，作为一个异步NIO框架，Netty的所有IO操作都是异步非阻塞的，通过Future-Listener机制，用户可以方便的主动获取或者通过通知机制获得IO操作结果。 作为当前最流行的NIO框架，Netty在互联网领域、大数据分布式计算领域、游戏行业、通信行业等获得了广泛的应用，一些业界著名的开源组件也基于Netty的NIO框架构建 传统通信采用了同步阻塞IO，当客户端的并发压力或者网络时延增大之后，同步阻塞IO会由于频繁的wait导致IO线程经常性的阻塞，由于线程无法高效的工作，IO处理能力自然下降。 我们通过BIO通信模型图看下BIO通信的弊端 采用BIO通信模型的服务端，通常由一个独立的Acceptor线程负责监听客户端的连接，接收到客户端连接之后为客户端连接创建一个新的线程处理请求消息，处理完成之后，返回应答消息给客户端，线程销毁，这就是典型的一请求一应答模型。 该架构最大的问题就是不具备弹性伸缩能力，当并发访问量增加后，服务端的线程个数和并发访问数成线性正比，由于线程是JAVA虚拟机非常宝贵的系统资源，当线程数膨胀之后，系统的性能急剧下降，随着并发量的继续增加

在开篇之前，我们对JavaNIO 的使用方式不做过多介绍，这种API的介绍方式网上太多了，没必要详细介绍，我们假设NIO的使用方式，你能够熟练运用。这是NIO系列第三篇: 【NIO系列】——之TCP探秘 【NIO系列】——之IO模型 通过之前的Unix的IO模型介绍，想必也了解到了5种IO模型。java的NIO是属于同步非阻塞IO，关于IO多路复用，java没有相应的IO模型，但有相应的编程模式，Reactor 就是基于NIO中实现多路复用的一种模式。本文将从以下几点阐述Reactor模式： reactor 是什么 为何要用，能解决什么问题 如何用，更好的方式 其他事件处理模式 一、Reactor 是什么 关于reactor 是什么，我们先从wiki上看下: The reactor design pattern is an event handling pattern for handling service requests delivered concurrently to a service handler by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to the associated

这是NIO系列的第四篇，欢迎继续关注: 【NIO系列】——之TCP探秘 【NIO系列】——之IO模型 【NIO系列】——之Reactor模型 如果你看过前面三篇文章，我们从最低层来分解NIO底层原理和使用方式，帮忙我们理解了NIO是什么，解决了什么问题，以及又有那些不足。 原则上NIO的出现，已经提升和加快了网络IO的处理方式，但它只能帮忙我们解决了IO层次的读写问题，在软件层次上我们需要更好的编程架构模型，来解决扩展性以及高并发的问题。Netty正是用来解决这些问题的，这一篇我们将详细介绍Netty的知识点。 一、netty是什么 1、是什么 我们采用官方的话来说: Netty是一个高性能、异步事件驱动的网络应用框架。 基于Netty，可以快速的开发和部署高性能、 高可用的网络服务端和客户端应用。 简单来说，它是一个网络应用框架，帮你解决面向网络开发中的三个问题： 面向网络IO的读写，如TCP的socket连接 应用层协议编解码，如HTTP协议 高并发架构 那么他有哪些优点？ Fast —性能强悍，高并发，低延迟 Easy —高扩展，API使用简单，开发门槛低 Non-blocking — 无阻塞，支持NIO 2、有何不同 对于我们用惯了web容器的人来说，第一个疑惑就是netty究竟能干什么，为何要用它。既然Netty是一个网络应用框架，这些明明tomcat也能帮我们解决了

一、Netty 简介 Netty 是基于 Java NIO 的异步事件驱动的网络应用框架，使用 Netty 可以快速开发网络应用，Netty 提供了高层次的抽象来简化 TCP 和 UDP 服务器的编程，但是你仍然可以使用底层的 API。 Netty 的内部实现是很复杂的，但是 Netty 提供了简单易用的API从网络处理代码中解耦业务逻辑。Netty 是完全基于 NIO 实现的，所以整个 Netty 都是异步的。 Netty 是最流行的 NIO 框架，它已经得到成百上千的商业、商用项目验证，许多框架和开源组件的底层 rpc 都是使用的 Netty，如 Dubbo、Elasticsearch 等等。下面是官网给出的一些 Netty 的特性： 设计方面 对各种传输协议提供统一的 API（使用阻塞和非阻塞套接字时候使用的是同一个 API，只是需要设置的参数不一样）。 基于一个灵活、可扩展的事件模型来实现关注点清晰分离。 高度可定制的线程模型——单线程、一个或多个线程池。 真正的无数据报套接字（UDP）的支持（since 3.1）。 易用性 完善的 Javadoc 文档和示例代码。 不需要额外的依赖，JDK 5 (Netty 3.x) 或者 JDK 6 (Netty 4.x) 已经足够。 性能 更好的吞吐量，更低的等待延迟。 更少的资源消耗。 最小化不必要的内存拷贝。 安全性 完整的

序 本文主要研究一下spring cloud gateway的RetryGatewayFilter GatewayAutoConfiguration spring-cloud-gateway-core-2.0.0.RC2-sources.jar!/org/springframework/cloud/gateway/config/GatewayAutoConfiguration.java @Configuration @ConditionalOnProperty(name = "spring.cloud.gateway.enabled", matchIfMissing = true) @EnableConfigurationProperties @AutoConfigureBefore(HttpHandlerAutoConfiguration.class) @AutoConfigureAfter({GatewayLoadBalancerClientAutoConfiguration.class, GatewayClassPathWarningAutoConfiguration.class}) @ConditionalOnClass(DispatcherHandler.class) public class GatewayAutoConfiguration { //......