Reactor

1、是否简略形容下reactor线程模型？三个点，事件驱动、一个或者多个数据源、多路复用事件驱动简略了解 : 场景1 : 比如说小A HR要招聘一个NB的程序员，既要Java根底厉害，又波及大数据畛域(不单单只会皮毛的)的人，忽然小A在xxx招聘网站看到了一个小B，发现小B就是我想要找的人哈，怎么办？打个电话吧？嘟嘟嘟...，接通了，聊了聊，挺好，过去下班吧场景2 : 还有一种状况就是，小A和小B聊了聊，小A说，你先关注订阅一下咱们公司，咱们有新音讯了告诉你，因为我本人做不了主，须要主管看看，一个工夫，主管看了看，桌子一拍，唉吆喂，这不就是我想要找的人么，回调发一个邮件，来下班吧，小A收到邮件，高高兴兴来下班了 同步了解音讯驱动 :HR 小A在各种招聘网站都看，要么Java根底不行的，要么大数据不会的，肿么办？要不在xxx上公布一个招聘音讯吧，一旦有这样能力的人看到，说不定会分割我 总结 :简略了解 : 事件驱动就是我是被动的，比如说RPC，我被动来调用你，你有事件告诉我 ; 音讯驱动，我把音讯处理完毕了，放到这里了，你想生产就生产哈 一个或者多个数据源 : NIO 多路复用能够反对百万client连贯，承受客户端的Accept、Read、Write事件 多路复用 : client channel的注册到一个selector，轮询channel事件，事件处理 2、Kafka的 reactor线程模型能说说么？最好画个图吧？简略说说，Acceptor线程疯狂的承受客户端的连贯，come on，来和我建设连贯吧，Acceptor领有Processor线程的援用，过去了，是吧。好，打入到Processor线程中，一直的轮询打。一旦客户端有新的事件，我要读，好，Processor线程感知到了，而后又摔到一个线程平安的队列中，Handler线程池中，感知到了，会从队列中获取，比如说真正的IO操作(磁盘读/写操作，可能很浪费时间，没事，搞到线程池中，你干你的，不要阻塞我上游的线程)，一旦Handler线程操作实现，因为Handler线程领有Processor中的响应队列援用，间接写回去，Processor线程在轮询的时候，吆，Handler处理完毕了，好吧，我写给客户端，好的，客户端实现了一次读取操作 欢送点赞加关注，用最简略的话，聊艰涩难懂的技术

1 reactor 呈现的背景、初衷和要达到什么样的指标Reactor 我的项目始于 2012 年。 通过长时间的外部孵化，于 2013 年公布 Reactor 1.x 版本。 Reactor 1 在各种架构下都能胜利部署，包含开源的(如 Meltdown)和商业的(如 Pivotal RTI)。2014年，通过与一些新兴的响应式数据流标准单干，从新设计并于 2015 年 4 月公布 Reactor 2.0 版本。 1.1 阻塞浪费资源互联网企业基本上都有着大量的用户，即便当代硬件的性能曾经晋升了很多，然而性能问题始终是互联网企业不能疏忽的一个问题。通常有两种形式来晋升利用的性能： 应用更多的线程和硬件资源达到并行化。这也是很多企业采纳的形式；在以后应用的资源上寻求更高效的解决。这在寰球经济上行的背景下，是一种老本更低的形式；1.2 异步能援救所有嘛？通过编写异步非阻塞的代码，能够将执行切换到应用了雷同底层资源的另一流动工作上，而后在异步实现之后返回到当前任务。晋升资源利用率。 java 提供了两种编写异步（异步不肯定非阻塞）代码的形式。 Callbacks：不立刻返回对象，然而提供了一个 callback 参数，当后果可返回时调用。Future：这也是当初大部分程序员在应用的形式。异步办法会立刻返回一个 Future<T>。Future 对象对获取该值进行了包装，这个对象能够始终轮询晓得返回（除非设置了超时工夫）。例如,ExecutorService 应用 Future 对象执行 Callable<T> 工作。这些技术都有本人的问题： callback 不好组合，编写有难度，且很容易导致代码难以浏览和保护。 Future 比callback好很多，然而也有本人的问题。 调用 get() 办法会阻塞；不足对多值和高级错误处理的反对。1.3 从命令式到响应式作为响应式编程方向上的第一步，Microsoft在.NET生态中创立了响应式(Rx)扩大库。而后RxJava实现了JVM上的响应式编程。随着工夫的推移，通过Reactive Streams的致力，一套基于JVM为响应式库定义接口与交互规定的标准规范Reactive Streams 呈现了。其接口曾经集成到了Java9中的 Flow 类下。响应式旨在解决上述 JVM 提供的异步形式的毛病，同时关注了其余一些方面： 组合型和易读性数据作为 流 操作，有着丰盛的操作符在订阅之前什么都不会产生（有什么长处？）背压，消费者能够向生产者发送信号示意公布速率太快与并发无关的高阶形象reactor 是响应式编程的一种实现。 古代应用程序须要解决大量并发申请并解决大量数据。规范的阻塞代码不再足以满足这些要求。 反应式设计模式是一种基于事件的架构办法，用于异步解决来自单个或多个服务处理程序的大量并发服务申请。 Project Reactor 基于这种模式，并有一个明确而雄心勃勃的指标，即在 JVM 上构建非阻塞、反应式应用程序。 2 reactor 劣势和劣势别离是什么劣势异步非阻塞代码可读性高背压 解决音讯的生产可能比生产慢。劣势对于非响应式 java 开发者来说，学习曲线平缓。debug 难度高3 reactor 的实用场景创立事件驱动程序；亚马逊等大型在线购物平台的告诉服务为银行业提供宏大的交易解决服务股票价格同时变动的股票交易业务4 reactor 组成部分和要害节点4.1 Mono一种生成数据流的形式。蕴含0-1个后果的异步序列。 ...

1 作用不同1.2 映射？展平？map 只执行映射flatMap 既执行映射，也执行展平什么叫只能执行映射？ 我了解是把一个数据执行一个办法，转换成另外一个数据。举个例子：mapper 函数把输出的字符串转换成大写。map()办法执行这个 mapper 函数。 Function<String, String > mapper = String::toUpperCase; Flux<String> inFlux = Flux.just("hello", ".", "com"); Flux<String> outFlux = inFlux.map(mapper); // reactor 测试包提供的测试方法 StepVerifier.create(outFlux) .expectNext("HELLO", ".", "COM") .expectComplete() .verify();什么叫展平？ mapper 函数把字符串转成大写，而后宰割成一个一个字符。 Function<String, Publisher<String>> mapper = s -> Flux.just(s.toUpperCase().split("")); Flux<String> inFlux = Flux.just("hello", ".", "com"); // 这里只能应用 flatMap，因为参数是 Function<T, Publisher<V>> 模式 Flux<String> outFlux = inFlux.flatMap(mapper); List<String> output = new ArrayList<>(); outFlux.subscribe(output::add); // 输入 [H, E, L, L, O, ., C, O, M] System.out.println(output); 请留神，因为来自不同起源的数据项交织，它们在输入中的程序可能与咱们在输出中看到的不同。 ...

简介Reactor响应式编程（Reactive Programming）： Reactor is a fully non-blocking reactive programming foundation for the JVM, with efficient demand management (in the form of managing “backpressure”). It integrates directly with the Java 8 functional APIs, notably CompletableFuture, Stream, and Duration. It offers composable asynchronous sequence APIs — Flux (for [N] elements) and Mono (for [0|1] elements) — and extensively implements the Reactive Streams specification.翻译一下就是：Reactor是JVM的一个齐全无阻塞的响应式编程根底，具备高效的需要治理(以治理“背压”的模式)。它间接与Java 8性能api集成，尤其是CompletableFuture、Stream和Duration。它提供了可组合的异步序列api——Flux(用于[N]元素)和Mono(用于[0|1]元素)——并且宽泛地实现了反馈流标准。 背景咱们服务端的我的项目大多采纳了Spring WebFlux，reactor是 Spring WebFlux 的首选反馈库，WebFlux 须要 Reactor 作为外围依赖项。Reactor 存在肯定的学习老本，在开发中咱们遇到了些bug，相当一部分是因为咱们不够理解 reactor ，踩了很多坑。所以在本文档中咱们次要针对的是一些学习过程容易让新人感到迷茫的知识点（map、flatMap、异步、并发），冀望能让新人更好上手 Spring WebFlux。 ...

IO线程模型概述目前的IO线程解决模型个别能够分为以下三类 单线程阻塞I/O服务模型多线程阻塞IO服务模型Reactor模式依据Reactor的数量和解决资源池线程的数量不同，Reactor模式有如下3种典型的实现 单Reactor单线程单Reactor多线程主从Reactor多线程传统阻塞I/O线程模型传统阻塞的IO线程线程模型在解决IO事件的时候其实就是一直应用一个循环监听端口是否有新的套接字连贯，如果有就进行相应的解决，然而在业务逻辑较为简单的状况下，无奈疾速返回进行新的连贯操作，会导致后续的连贯阻塞，效率太低。其线程模型如下图所示：(对于多线程阻塞IO这里就不再赘述，就是一个线程对应一个连贯) Reactor模型针对传统阻塞I/O服务模型的毛病，解决方案个别有两个 基于 I/O 复用模型：多个连贯共用一个阻塞对象，应用程序只须要在一个阻塞对象期待，无需阻塞期待所有连贯。当某个连贯有新的数据能够解决时，操作系统告诉应用程序，线程从阻塞状态返回，开始进行业务解决。基于线程池复用线程资源：不用再为每个连贯创立线程，将连贯实现后的业务解决任务分配给线程进行解决，一个线程能够解决多个连贯的业务。I/O复用联合线程池，就是Reactor模式根本设计思维，如图所示： 单Reactor单线程模式长处：模型简略，没有多线程、过程通信、竞争的问题，全副都在一个线程中实现毛病： 性能问题，只有一个线程，无奈齐全施展多核 CPU 的性能。Handler 在解决某个连贯上的业务时，整个过程无奈解决其余连贯事件，很容易导致性能瓶颈。可靠性问题，线程意外终止，或者进入死循环，会导致整个零碎通信模块不可用，不能接管和解决内部音讯，造成节点故障应用场景：客户端的数量无限，业务解决十分疾速，比方 Redis在业务解决的工夫复杂度 O(1) 的状况 单Reactor多线程模型长处：能够充沛的利用多核cpu 的解决能力毛病：多线程数据共享和拜访比较复杂， reactor 解决所有的事件的监听和响应，在单线程运行， 在高并发场景容易呈现性能瓶颈. 主从Reactor多线程模型长处：父线程与子线程的数据交互简略职责明确，父线程只须要接管新连贯，子线程实现后续的业务解决。Reactor 主线程只须要把新连贯传给子线程，子线程无需返回数据。毛病：编程复杂度较高联合实例：这种模型在许多我的项目中宽泛应用，包含 Nginx 主从 Reactor 多过程模型，Memcached 主从多线程，Netty 主从多线程模型也进行了反对 Netty中的reactor模型Netty次要是基于主从Reactor多线程模式做了肯定的改良，其中主从Reactor都由单线程一个变成了多线程。Server 端蕴含 1 个 Boss的NioEventLoopGroup 和 1 个 Worker的NioEventLoopGroup。NioEventLoopGroup 相当于 1 个事件循环组，这个组里蕴含多个事件循环 NioEventLoop，每个 NioEventLoop 蕴含 1 个 Selector 和 1 个事件循环线程。每个Boss的NioEventLoop循环执行的工作蕴含 3 步： 轮询 Accept 事件；解决 Accept I/O 事件，与 Client 建设连贯，生成 NioSocketChannel，并将 NioSocketChannel 注册到某个 Worker NioEventLoop 的 Selector 上；解决工作队列中的工作，runAllTasks。工作队列中的工作包含用户调用eventloop.execute或schedule执行的工作，或者其余线程提交到该eventloop的工作。每个 Worker NioEventLoop 循环执行的工作蕴含 3 步： ...

1 源于生存的设计模式 咱们在生活中有一个十分不违心去然而却又不得不去的中央就是医院，咱们去医院看病须要经验一下流程： 第1步：挂号 第2步：期待叫号 第3步：找对应的医生讲述病情，医生依据症状开化验单 第4步：咱们带上化验单应用设施化验 第5步：期待化验后果进去之后咱们要拿上化验单再去找医生 第6步：医生依据化验后果隔靴搔痒。 每个人都不违心去医院，因为咱们感觉去医院十分麻烦，经验下面的流程一天的工夫就过来了，在这所有的流程中期待叫号和等化验后果工夫是最长的，有的化验单可能好几天能力进去，化验单进去之后也须要排队让医生看化验后果。 作为病人心愿到医院之后有一对一的服务，到医院之后有对应的医生给咱们全程跟踪看病。 然而如果咱们作为医院的管理者会怎么思考这个问题呢，医院的医生和设施数量是无限的，然而每天的病人却很多，基本上是医生的几十倍，如何应用无限的医生和设施资源解决更多病人的问题呢。 假如医院有10个医生，20台设施，医生执行第3步须要10分钟，执行第6步须要10分钟，设施执行第4步须要20分钟，第5步须要20分钟。如果医生接到病人之后给病人开化验单，而后等着病人出后果之后给病人开药，再送走，就是从第3步到第6步始终有医生跟着，这样会十分耗时，一个医生看一个病人须要破费 10+20+20+10=60分钟 的工夫，一天8小时只能给8病人看病，一个医院每天只能接待108=80个病人。然而如果医生开完化验单之后病人去化验这段时间给下个挂过号的病人看病，即执行完第3步之后，医生能够持续叫号执行第2步，病人拿到化验单之后即执行完第5步之后能够再去找医生执行第6步，这样就把资源充分利用起来了，一个医生看一个病人只须要精力第3步和第6不，破费10+10=20分钟，每天可能给860/20=24集体看病，整个医院每天能接待10*24=240个病人。这就是Reactor设计模式最外围的思维，解决了一对多的问题，大大晋升了资源的使用率。 【文章福利】须要C/C++ Linux服务器架构师学习材料加群1106747042（材料包含C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等） 2 Reactor设计模式实现 NIO是应用reactor设计模式十分经典的案例，传统的IO客户端过去一个连贯，服务端就须要专门一个线程来解决，每一个线程会将一次交互操作全副解决实现，包含读取和返回，外表上仿佛连贯不在线程外面，然而如果线程不够，新连贯将无奈失去解决。所以一个线程就肩负了连贯、读取、写入的责任。 这种解决模式海量并发的状况下即便引入线程池也不能满足需要，这个时候思考将一次残缺的申请切分为几个小的工作，就像医院把医生问诊和仪器查看离开一样，每个小工作都是非阻塞的，对于读写操作应用NIO对其进行读写。所以咱们把一次连贯操作拆分为多个工作，每个工作都是非阻塞的，这样就大大晋升了效率，然而这样做线程池中的线程数量业也会大大增长，然而线程更加简略且工作繁多，有点像咱们微服务的思维。 Reactor从线程池和Reactor的抉择上能够细分为：Reactor单线程模型，Reactor多线程模型，Reactor主从模型。 2.1 Reactor单线程模型 单线程模型是针对客户端申请应用一个专门的线程去解决，这个线程循环监听是否有客户端的申请到达，一旦收到客户端申请，将其分发给相应解决线程进行解决。这种模式采纳了基于事件驱动的设计，当有事件触发时才会调用处理器进行数据处理。应用Reactor模式能够对线程的数量进行管制，能够应用一个线程去解决大量的事件。 2.2 Reactor多线程模型 应用一个线程能够反对所有的IO解决，然而瓶颈也是不言而喻的，如果客户端屡次申请时在业务线程中解决较慢，后续的客户端会被积压，导致响应变慢，所以须要引入Reactor多线程模型。能够将工作线程引入线程池，将处理器的执行放入线程池，并应用多线程解决业务逻辑。 2.3 Reactor主从模型 对于多个CPU的机器，为了充分利用系统资源会将Reactor拆分为两局部。 1）Main Reactor 负责监听连贯，将监听到的连贯交给Sub Reactor解决，主Reactor用于响应连贯申请。 2）Sub Reactor 解决连贯，从Reactor用于解决IO操作申请。 3 架构模型 Handle：操作系统的句柄，能够是关上的文件、一个Socket连贯、Timer定时器等。 Synchronous Event Demultiplexer ：同步（多路）事件分离器，阻塞期待Handles中的事件产生。 Initiation Dispatcher ：初始事件散发器，提供了注册、删除、转发Event Handler的办法 Event Handler ：事件处理器的接口 Concrete Event Handler ：事件处理器的理论实现，而且绑定了一个Handle。因为在理论状况中，咱们往往不止一种事件处理器，因而这里将事件处理器接口和实现离开，与C++、Java这些高级语言中的多态相似。 ————————————————

摘要：无论是 Reactor，还是 Proactor，都是一种基于「事件散发」的网络编程模式，区别在于 Reactor 模式是基于「待实现」的 I/O 事件，而 Proactor 模式则是基于「已实现」的 I/O 事件。本文分享自华为云社区《高性能网络框架：Reactor和 Proactor》，原文作者：小林 coding。 这次就来图解 Reactor 和 Proactor 这两个高性能网络模式。 别小看这两个货色，特地是 Reactor 模式，市面上常见的开源软件很多都采纳了这个计划，比方 Redis、Nginx、Netty 等等，所以学好这个模式设计的思维，不仅有助于咱们了解很多开源软件，而且也能在面试时吹逼。 发车！ 演进如果要让服务器服务多个客户端，那么最间接的形式就是为每一条连贯创立线程。 其实创立过程也是能够的，原理是一样的，过程和线程的区别在于线程比拟轻量级些，线程的创立和线程间切换的老本要小些，为了形容简述，前面都以线程为例。 解决完业务逻辑后，随着连贯敞开后线程也同样要销毁了，然而这样不停地创立和销毁线程，不仅会带来性能开销，也会造成浪费资源，而且如果要连贯几万条连贯，创立几万个线程去应答也是不事实的。 要这么解决这个问题呢？咱们能够应用「资源复用」的形式。 也就是不必再为每个连贯创立线程，而是创立一个「线程池」，将连贯调配给线程，而后一个线程能够解决多个连贯的业务。 不过，这样又引来一个新的问题，线程怎样才能高效地解决多个连贯的业务？ 当一个连贯对应一个线程时，线程个别采纳「read -> 业务解决 -> send」的解决流程，如果以后连贯没有数据可读，那么线程会阻塞在 read 操作上（ socket 默认状况是阻塞 I/O），不过这种阻塞形式并不影响其余线程。 然而引入了线程池，那么一个线程要解决多个连贯的业务，线程在解决某个连贯的 read 操作时，如果遇到没有数据可读，就会产生阻塞，那么线程就没方法持续解决其余连贯的业务。 要解决这一个问题，最简略的形式就是将 socket 改成非阻塞，而后线程一直地轮询调用 read 操作来判断是否有数据，这种形式尽管该可能解决阻塞的问题，然而解决的形式比拟粗犷，因为轮询是要耗费 CPU 的，而且随着一个 线程解决的连贯越多，轮询的效率就会越低。 下面的问题在于，线程并不知道以后连贯是否有数据可读，从而须要每次通过 read 去试探。 那有没有方法在只有当连贯上有数据的时候，线程才去发动读申请呢？答案是有的，实现这一技术的就是 I/O 多路复用。 I/O 多路复用技术会用一个零碎调用函数来监听咱们所有关怀的连贯，也就说能够在一个监控线程外面监控很多的连贯。 咱们相熟的 select/poll/epoll 就是内核提供给用户态的多路复用零碎调用，线程能够通过一个零碎调用函数从内核中获取多个事件。 PS：如果想晓得 select/poll/epoll 的区别，能够看看小林之前写的这篇文章：这次许可我，一举拿下 I/O 多路复用！ select/poll/epoll 是如何获取网络事件的呢？ ...