Reactor

阅读文本大概需要3分钟。 JDK 7 引入了 Asynchronous I/O， 即AIO。在进行 I/O 编程中， 常用到两种模式： Reactor 和 Proactor。 Java的NIO就是Reactor， 当有事件触发时， 服务器端得到通知， 进行相应的处理。 AIO即NIO2.0，叫做异步不阻塞的IO。 AIO引入异步通道的概念， 采用了 Proactor 模式， 简化了程序编写，有效的请求才启动线程， 它的特点是先由操作系统完成后才通知服务端程序启动线程去处理， 一般适用于连接。 异步IO功能的关键点，它们是Channel 类的一些子集，Channel在处理IO操作的时候需要被切换成一个后台进程。一些需要访问较大，耗时的操作，或是其它的类似实例，可以考虑应用此功能。 在这里只单独讲解针对文件IO操作的AsynchronousFileChannel，但是需要注意的是，还有一些其他的异步管道，包括： AsynchronousFileChannel：针对文件； AsynchronousSocketChannel ：针对客户端的socket； AsynchronousServerSocketChannel：针对服务器端的异步socket，用来接收到来的连接。 针对异步管道的交互有两种不同的方式： Future 风格； callback 风格。 0x01：Future风格的异步

1.Netty 是什么？ Netty是 一个异步事件驱动的网络应用程序框架，用于快速开发可维护的高性能协议服务器和客户端。Netty是基于nio的，它封装了jdk的nio，让我们使用起来更加方法灵活。 2.Netty 的特点是什么？ 高并发：Netty 是一款基于 NIO（Nonblocking IO，非阻塞IO）开发的网络通信框架，对比于 BIO（Blocking I/O，阻塞IO），他的并发性能得到了很大提高。 传输快：Netty 的传输依赖于零拷贝特性，尽量减少不必要的内存拷贝，实现了更高效率的传输。 封装好：Netty 封装了 NIO 操作的很多细节，提供了易于使用调用接口。 3.Netty 的优势有哪些？ 使用简单：封装了 NIO 的很多细节，使用更简单。 功能强大：预置了多种编解码功能，支持多种主流协议。 定制能力强：可以通过 ChannelHandler 对通信框架进行灵活地扩展。 性能高：通过与其他业界主流的 NIO 框架对比，Netty 的综合性能最优。 稳定：Netty 修复了已经发现的所有 NIO 的 bug，让开发人员可以专注于业务本身。 社区活跃：Netty 是活跃的开源项目，版本迭代周期短，bug 修复速度快。 4.Netty 的应用场景有哪些？ 典型的应用有：阿里分布式服务框架 Dubbo，默认使用 Netty 作为基础通信组件，还有 RocketMQ

Redis是单线程的，这话搁以前，是横着走的，谁都知道的真理。 现在不一样， Redis 变了。 再说这句话，多少得有质疑的语气来跟你辩驳一番。 意志不坚定的，可能就缴械投降，顺着别人走了。 到底是什么样的，各位看官请跟我一起往下看： - 思维导图 - Reactor模式 反应器模式，你可能不太认识，如果看过上篇文章的话应该会有点印象。涉及到 Redis 线程它是一个绕不过去的话题。 1、传统阻塞IO模型 在讲反应器模式前，这里有必要提一下传统阻塞IO模型的处理方式。 在传统阻塞IO模型中，由一个独立的 Acceptor 线程来监听客户端的连接，每当有客户端请求过来时，它就会为客户端分配一个新的线程来进行处理。当同时有多个请求过来，服务端对应的就会分配相应数量的线程。这就会导致CPU频繁切换，浪费资源。 有的连接请求过来不做任何事情，但服务端还会分配对应的线程，这样就会造成不必要的线程开销。这就好比你去餐厅吃饭，你拿着菜单看了半天发现真他娘的贵，然后你就走人了。这段时间等你点菜的服务员就相当于一个对应的线程，你要点菜可以看作一个连接请求。 同时，每次建立连接后，当线程调用读写方法时，线程会被阻塞，直到有数据可读可写， 在此期间线程不能做其它事情。还是上边餐厅吃饭的例子，你出去转了一圈发现还是这家性价比最高。回到这家餐厅又拿着菜单看了半天，服务员也在旁边等你点完菜为止

Redis是单线程的，这话搁以前，是横着走的，谁都知道的真理。现在不一样，Redis 变了。再说这句话，多少得有质疑的语气来跟你辩驳一番。意志不坚定的，可能就缴械投降，顺着别人走了。 到底是什么样的，各位看官请跟小莱一起往下： 图注：思维导图 Reactor模式 反应器模式，你可能不太认识，如果看过上篇文章的话应该会有点印象。涉及到 Redis 线程它是一个绕不过去的话题。 1、传统阻塞IO模型 在讲反应器模式前，这里有必要提一下传统阻塞IO模型的处理方式。 在传统阻塞IO模型中，由一个独立的 Acceptor 线程来监听客户端的连接，每当有客户端请求过来时，它就会为客户端分配一个新的线程来进行处理。当同时有多个请求过来，服务端对应的就会分配相应数量的线程。这就会导致CPU频繁切换，浪费资源。 有的连接请求过来不做任何事情，但服务端还会分配对应的线程，这样就会造成不必要的线程开销。这就好比你去餐厅吃饭，你拿着菜单看了半天发现真他娘的贵，然后你就走人了。这段时间等你点菜的服务员就相当于一个对应的线程，你要点菜可以看作一个连接请求。 同时，每次建立连接后，当线程调用读写方法时，线程会被阻塞，直到有数据可读可写， 在此期间线程不能做其它事情。还是上边餐厅吃饭的例子，你出去转了一圈发现还是这家性价比最高。回到这家餐厅又拿着菜单看了半天，服务员也在旁边等你点完菜为止

点击上方 “ 慧响智凝 ” 可以订阅哦！ 本文字数： 5160字 阅读时间： 10分钟 最近阅读了一本架构方面的入门图书叫《从零开始学架构：照着做，你也能成为架构师》，部分内容比较不错，先做书摘总结，以便加深印象与未来回顾学习。 本文是该书第二部分，是书中第四、五章，主要介绍存储高性能、计算高性能，涉及到关系型数据库分库分表与读写分离、NoSQL类型、缓存穿透与热点、单服高性能、集群高性能等内容。 目录 ▪ 第四章 存储高性能 ▪第五章 计算高性能 ▪其他相关摘要 第四章 存储高性能 关系型数据库 读写分离 本质： 将访问压力分散到集群中的多个节点，但是没有分散存储压力。 读写分离的基 ‍ 本实现： 数据库服务器搭建主 ‍ 从集群，一主一从、一主多从都可以。 数据库主机负责读写操作，从机只负责读操作。 数据库主机通过复制将数据同步到从机，每台数据库服务器都存储了所有的业务数据。 业务服务器将 ‍ 写操作发给数据库主机，将读操作发给数据库从机。 读写分离在实际应用过程中需要应对复制延迟带来的复杂性。 解决主从复制延迟的方法： 写操作后的读操作指定发给数据库主服务器。 读从机失败后再读一次主机。 关键业务读写操作全部指向主机，非关键业务采用读写分离。 分库分表 本质： 既可以分散访问压力，又可以分散存储压力。 为了满足业务数据存储的要求，就需要将存储分散到多台数据库服务器上。

今天大概总结一下编写服务端程序常用的编程模型。参考UNP第三版第三十章和陈硕的muduo那本书，强烈建议仔细阅读。注意以下代码只是为了显式框架或者说编程模型，不是完整的程序，深夜写的比较任性，不要见怪。 accept + read/write 这个不是并发服务器，而是迭代服务器（iterative server）。 它一次服务一个客户。不适合长连接，适合 daytime 这种 write-only 短连接服务。 void handle (client_socket, client_address) { while ( true ) { data = client_socket . recv( 4096 ); if ( data ) client_socket . send( data ); else do_error(); } } while ( true ){ connfd = server_socket . accept(); handle (client_socket, client_address); } accept + fork 这种模型也叫 process-per-connection，编写出的是多进程并发服务器程序，为每个客户调用 fork 派生一个子进程，使得服务器能够同时服务多个客户。这是传统的 Unix 并发网络编程方案，适合并发连接数不大的情况，适合

NIO（Non-blocking I/O，在Java领域，也称为New I/O），是一种同步非阻塞的I/O模型，也是I/O多路复用的基础，已经被越来越多地应用到大型应用服务器，成为解决高并发与大量连接、I/O处理问题的有效方式。 那么NIO的本质是什么样的呢？它是怎样与事件模型结合来解放线程、提高系统吞吐的呢？ 本文会从传统的阻塞I/O和线程池模型面临的问题讲起，然后对比几种常见I/O模型，一步步分析NIO怎么利用事件模型处理I/O，解决线程池瓶颈处理海量连接，包括利用面向事件的方式编写服务端/客户端程序。最后延展到一些高级主题，如Reactor与Proactor模型的对比、Selector的唤醒、Buffer的选择等。 注：本文的代码都是伪代码，主要是为了示意，不可用于生产环境。 传统BIO模型分析 让我们先回忆一下传统的服务器端同步阻塞I/O处理（也就是BIO，Blocking I/O）的经典编程模型： { ExecutorService executor = Excutors.newFixedThreadPollExecutor(100);//线程池 ServerSocket serverSocket = new ServerSocket(); serverSocket.bind(8088); while(!Thread.currentThread.isInturrupted

专栏其他文章： 理论篇： （一）深入浅出TCPIP之理解TCP报文格式和交互流程 (二）深入浅出TCPIP之再识TCP，理解TCP三次握手（上） (三）深入浅出TCPIP之再识TCP，理解TCP四次挥手（上） (四）深入浅出TCPIP之TCP三次握手和四次挥手（下）的抓包分析 (五）深入浅出TCPIP之TCP流量控制 (六）深入浅出TCPIP之TCP拥塞控制 (七）深入浅出TCPIP之深入浅出TCPIP之TCP重传机制 (八）深入浅出TCPIP之TCP长连接与短连接详解 (九）深入浅出TCPIP之网络同步异步 (十）深入浅出TCPIP之网络阻塞和非阻塞 （十一）深入浅出TCPIP之TCP粘包问题 (十二）深入浅出TCPIP之Nagle算法 (十三) 深入浅出TCPIP之TCP套接字参数 (十四）深入浅出TCPIP之初识UDP理解报文格式和交互流程 (十五）非常全面的TCPIP面试宝典-进入大厂必备总结 (十六)深入浅出TCPIP之Hello CDN .... （二十）深入浅出TCPIP之epoll的一些思考 实践篇： 深入浅出TCPIP之实战篇—用c++开发一个http服务器（二十一） 其他实践篇+游戏开发中的网络问题疑难杂症解读 正在完善。。。 在当前的网络编程专栏前十几篇文章里，我已经说明了TCPIP常用的一些原理，那么接下来我将逐步进入到实战编程阶段： 本篇文章我将带大家用C

本章节继续介绍：Flux和Mono操作符（二） 1.条件操作符 Reactor中常用的条件操作符有defaultIfRmpty、skipUntil、skipWhile、takeUntil和takeWhile等。 1、defaultIfRmpty defaultIfRmpty操作符返回来自原始数据流的元素，如果原始数据流中没有元素，则返回一个默认元素。 defaultIfRmpty操作符在实际开发过程中应用广泛，通常用在对方法返回值的处理上。如下controller层对service层返回值的处理。 @GetMapper("/article/{id}" ) public Mono<ResponseEntity<Article>> findById(@PathVariable String id){ return articleService.findOne(id) .map(ResponseEntity::ok) .defaultIfRmpty(ResponseEntity.status( 404).body( null )); } 2、takeUntil takeUntil操作符的基本用法是 takeUntil(Predicate<? super T>> predicate) ，其中Predicate代表一种断言条件，takeUntil将提取元素直到断言条件返回true。

swoole协程要点： 上下文换入换出 swoole协程使用boost.context进行上下文的换入换出，从而保存C栈和寄存器的执行数据 swoole在保存C栈的同时需要存储没有分配在C栈上的php上下文，在yield和resume时调用相应的回调函数保存恢复php的上下文 调度方式 使用reactor事件循环 同步I/O操作会开启进程或线程池处理，处理完成后通知reactor恢复对应的协程上下文 来源： oschina 链接： https://my.oschina.net/u/3687259/blog/3067378