reactor框架,parr reactor是什么反应器

reactor框架,parr reactor是什么反应器详细介绍

本文目录一览： 认识Spring - Reactor框架

我们都知道 reactor模式的优缺点， 也就是基于异步实现的， 但是这只是模式， 那么框架如何运作， 如何优美，则是另一回事。

最近在看 spring-cloud-gateway ， 我被老外写的代码吸引了， 一路到底就是 reactor框架整合netty的那段代码。 确实很优美。 主要是 reactor-netty 那个包。 确实写得不赖， 写了tcp ，udp 客户端和服务器端， 用户可以基于这个实现很多基于这个传输层的框架实现。

废话不多说， 先入门个 reactor吧，它是spring开发的一个子项目，spring的代码水平相当之高，尤其是封装和架构设计这块， github地址是 https://github.com/reactor/reactor-core 需要掌握它的写法和思想。

其中一个例子的地址是 https://www.infoq.com/articles/reactor-by-example/ ，我基本就是看的这个， 对于我们开发者而言， 其实不需要关注订阅， 对于reactor模式， 他是基于observer模式， 一个观察者模式， 发布订阅模式吧 ， 其中让大家不理解的是 ，Flux 和 Mono ， 这俩概念， 其实他俩都是发布者， 而订阅者我们接触不到，是因为spring框架帮我们订阅了。 也就是这个思想。 他的实现是基于 RxJava 2思想的。

我们开始吧。

上面这个就讲述了 Moon 和 Flux的区别, 其实就是 one / more 的区别. many one = more , 同时也可以分解.

快速开始前, 我们只需要加入 maven依赖

简单例子

上面输出 :

C++ POCO库中文编程参考指南（11） 如何使用Reactor框架？

1 Reactor 框架概述POCO 中的 Reactor 框架是基于 Reactor 设计模式进行设计的。其中由 Handler 将某 Socket 产生的事件，发送到指定的对象的方法上，作为回调。2 光说不练假把式PoechantReactorServer 类，基本与 PoechantTCPServer： class PoechantReactorServer: public ServerApplication { public: PoechantServer() {} //: _helpRequested(false) {} ~PoechantServer() {} protected: void initialize(Application& self) { loadConfiguration(); ServerApplication::initialize(self); } void uninitialize() { ServerApplication::uninitialize(); } int main(const std::vector& args) { // … return Application::EXIT_OK; } }PoechantServiceHandler 类定义如下。 class PoechantServiceHandler { public: PoechantServiceHandler(StreamSocket& socket, SocketReactor& reactor)； ~PoechantServiceHandler(); void onReadable(const AutoPtr& pNf); void onShutdown(const AutoPtr& pNf); private: enum { BUFFER_SIZE = 1024 }; StreamSocket _socket; SocketReactor& _reactor; char *_pBuffer; }；PoechantServiceHandler 实现： PoechantServiceHandler::PoechantServiceHandler(StreamSocket& socket, SocketReactor& reactor) :_socket(socket), _reactor(reactor), _pBuffer(new char[BUFFER_SIZE]) { Application& app = Application::instance(); app.logger().information("Connection from" + socket.peerAddress().toString()); _reactor.addEventHandler(_socket, NObserver(*this, &PoechantServiceHandler::onReadable)); _reactor.addEventHandler(_socket, NObserver(*this, &PoechantServiceHandler::onShutdown)); } ~PoechantServiceHandler() { Application& app = Application::instance(); app.logger().information("Disconnecting " + _socket.peerAddress().toString()); _reactor.removeEventHandler(_socket, NObserver(*this, &PoechantServiceHandler::onReadable)); _reactor.removeEventHandler(_socket, NObserver(*this, &PoechantServiceHandler::onShutdown)); delete [] _pBuffer; } void onReadable(const AutoPtr& pNf) { // Receive data from StreamSocket int n = _socket.receiveBytes(_pBuffer, BUFFER_SIZE); // Send data back the client if (n > 0) _socket.sendBytes(_pBuffer, n); else delete this; } // When ShutdownNotification is detected, this method will be invoked. void onShutdown(const AutoPtr& pNf) { delete this; }启动： int main(const std::vector& args) { unsigned short port = (unsigned short) config().getInt("PoechantReactor.port", 12345); ServerSocket serverSocket(port); SocketReactor reactor; SocketAcceptor acceptor(serverSocket, reactor); reactor.run(); waitForTerminationRequest(); reactor.stop(); return Application::EXIT_OK; } int main(int argc, char **argv) { return PoechantServer().run(argc, argv); }3 Clinet 测试代码同《POCO库中文编程参考指南（10）如何使用TCPServer框架？

ios reactor模式什么意思

说起C++ 的系统和网络编程开源库，恐怕没有人敢否认ACE的王者地位。其实ACE不光是一个实用的程序库和框架集，它更是一个设计模式的典范应用
reactor设计模式，是一种基于事件驱动的设计模式。Reactor框架是ACE各个框架中最基础的一个框架，其他框架都或多或少地用到了Reactor框架。
在事件驱动的应用中，将一个或多个客户的服务请求分离（demultiplex）和调度（dispatch）给应用程序。在事件驱动的应用中，同步地、有序地处理同时接收的多个服务请求。
《Pattern-Oriented Software Architecture, Volume 2》对这个模式做了详细的讲解。
这个模式的结构图如下：
图中的handle对应的是操作系统提供的句柄，例如I/O句柄，Event_Handler类持有这些句柄，reactor类内部提供一个事件循环：handle_events()，事件循环的代码实现利用了操作系统提供的多路分离函数，WaitForMultipleObjects或者select等，这些多路分离的函数的特点是，可以同时等待多个句柄，在等待过程中所在线程属于挂起状态，不消耗CPU时间，一旦某个句柄被触发，则线程被唤醒，函数将返回，线程可以执行后面的代码，利用多路分离函数的这一特点，根据被激活的句柄对应的特定事件，调用相关的事件处理函数。可以实现事件循环。
register_handler()函数用于将Event_Handler对象注册到事件驱动列表中，保证对于某一类型的事件，会调用Event_Handler类的响应函数handle_event()。
reactor类在做多路分离时需要操纵Event_Handler类的Handle，因此Event_Handler类需要提供get_handle()函数。
另外，当程序不需要再对特定事件响应时，需要把Event_Handler对象从事件驱动列表中删除，因此reactor类还实现了remove_handler函数。
因为reactor相对稳定，一旦实现，不需要再定制，所以没有提供一个抽象接口类，但Event_Handler是经常需要根据不同的需求定制的，因此需要提供一个抽象接口类，然后根据实际需求编写派生类，提供具体句柄，并实现相关虚函数。这个模式的优点是本身不涉及多线程，从而避免了线程的上下文切换。对于响应事件处理时间较短的情况下，可以考虑使用这个模式。如果处理一个事件需要花费大量时间，就不能使用这个模式，那样会导致其他事件处理被阻塞。
ACE_Reactor框架是这一模式的半成品，用户只要做三件事情就可以实现并使用这一模式：
1.从ACE_Event_Handler派生一个或多个类
2.向ACE_Reactor类登记应用的事件处理对象
3.运行ACE_Reactor事件循环。

parr reactor是什么反应器

reactor设计模式，是一种基于事件驱动的设计模式。Reactor框架是ACE各个框架中最基础的一个框架，其他框架都或多或少地用到了Reactor框架。 在事件驱动的应用中，将一个或多个客户的服务请求分离（demultiplex）和调度（dispatch）给应用程序。
parr是一个公司的名字，他们公司的反应器叫parr reactor. 反应器种类多种多样。。。

框架式电容器组包含那些具体设备

请问你是想问“框架式电容器组包含哪些具体设备”这个问题吗？该电容器组包括以下设备：1、框架（Rack）：框架式电容器组通常包括一个支架或框架，用于容纳和固定其他组件。2、电容器（Capacitors）：电容器是框架式电容器组的核心组件，它们用于存储电荷，并提供无功功率补偿。3、电抗器（Reactor）：电抗器是用来限制电流流动的装置，通常与电容器并联连接以形成谐振电路。4、断路器（Circuit Breaker）：断路器用于连接或断开电容器组与电力系统之间的电路。5、接触器（Contactors）：接触器是用于控制电容器组的开关装置，它们进行电容器的连接和断开操作，以满足电力系统的需求。6、保护设备（Protection Devices）：框架式电容器组通常配备各种保护设备，如过流保护、过压保护、过温保护等。

浅析libevent

libevent是一个轻量级的开源高性能网络库，基于事件驱动，跨平台支持WIN linux Mac 支持多种IO多路复用技术，支持 IO 定时器和信号等事件的统一调度，支持注册事件的优先级。memcache 使用libevent作为底层网络库。

Reactor 模式：

我们普通的函数调用 ，是程序调用某函数 ，函数执行中一直等待该函数执行完之后再继续执行下面的代码。Reactor 模式是一种事件驱动机制。和普通的函数调用不同的是这里的应用程序不是主动的调用某个API函数完成处理，而是恰恰相反，Reactor逆置了事件处理流程，应用程序需要提供相应的接口并注册到Reactor，如果相应的事件发生，Reactor将主动调用应用 注册的接口，这些函数是回调函数。开始用户会在相应的event中设置回调函数和相应监听句柄并由libevent中的Reactor实例进行管理。

采用Reactor模式是编写高性能网络服务器的必备技术之一：

优点：响应快，不会因为某个同步事件所阻塞，因为采用的是回调函数执行，虽然Reactor本身是同步的。

采用Reactor框架本身与具体事件的处理没有关系，只负责处理与用户的交互，具有很高复用性。

可以扩展多个Reactor实例来实现多CPU的资源利用

因为采用了阻塞的select epoll等IO复用函数进行阻塞监听批量的句柄，所以在事件到来时事件的处理逻辑，也就是回调函数不会阻塞住，而是非阻塞的执行。

应用场景：

1.初始化libevent的实例也就是struct event_base结构体也就是对应的Reactor模型在libevent中的实体

struct event_base *base = event_init();

2.用户初始化所要注册的事件 根据不同的事件，网络中主要包括 定时事件，IO事件，信号事件，libevent中使用宏方便用户根据不同的事件调用与事件名称相匹配的函数，但是内部全部都是调用一个借口event_set(),参数中对于所有时间都会有一个函数指针用于用户注册回调函数，一个句柄（对于IO事件就是文件描述符，信号就是信号的编号，对于定时事件不用设置）

3.将事件本身的基本信息设置好之后要和Reactor的实例也就是和某一个event_base 进行联系，因为可能存在多个event_base 实例

4.基本信息设置完成之后，调用event_add 函数将事件通过Reactor实例也就是struct_base的统一接口找到性能最高的IO复用函数注册到其中，包括设置超时时间。对于定时事件，libevent使用一个小根堆管理，key为超时时间，对于IO和信号事件，将该事件放到等待双向链表中，

5.进入无限循环等待就绪事件，以epoll为例，每次循环前，libevent都会检查定时事件中最小的超时时间tv,根据tv设置epoll的最大等待时间，以便后面及时处理超时事件，当epoll超时返回后就将超时事件添加到就绪队列如果是正确返回就不用添加超时事件，之后同样直接依次遍历就绪队列执行相应的回调函数处理逻辑。此处可以看出是同步处理逻辑的。（IO事件已经在epoll_wait中添加进了就绪队列了)

IO和timer事件的统一：

因为系统提供的IO机制像select或者epoll_wait 都允许程序制定一个最大的等待时间，也称作最大超时时间timeout，即使没有IO事件发生，也能保证能在timeout时间到达时候返回。

根据所有timer事件的最小超时事件来设置系统IO的timeout时间，当系统IO返回时候再激活所有继续的timer事件就可以了，这样就能将timer事件完美的融合到系统的IO机制中去了。这是Reactor 和Proactor模式中处理Timer事件最经典的方法了。

libevent支持多线程：

libevent代码本身不支持多线程，因为源代码没有同步机制。

但是可以采用消息通知机制来支持多线程:

1.暴力抢占：当一个线程正在执行的时候，此时主线程来了一个任务此时立即抢占执行主线程的任务，此时好处是任务可以立即得到处理，但是你必须处理好切换的问题，过多的切换也会为CPU带来效率问题。

2.消息通知机制:当主进程有一个任务需要处理的时候会发送一个消息通知你去执行任务，此时当前进程还是执行自己的任务，在自己的任务执行完后，查看消息说通知有一个任务，再去处理任务，但是通知消息不是立即查看的，没有很好的实时性。

3.消息通知+同步层 ：有个折中的处理方式，就是中间增减一个任务队列，这个任务队列是所有线程都可以看到的，每个线程都将新任务扔到这个队列中并且发送一个字符来通知，得到通知的当前线程只是取出其中的一个任务。当然，对于这个任务的操作都是同步的，也就是每一个线程操作要加锁，这就是一个加锁的队列。

微服务架构的分布式事务问题如何处理？

可以参考开源分布式事务管理器ByteTCC。ByteTCC特性：
1、支持Spring容器的声明式事务管理；
2、支持普通事务、TCC事务、业务补偿型事务等事务机制；
3、支持多数据源、跨应用、跨服务器等分布式事务场景；
4、支持长事务；
5、支持dubbo服务框架；
6、支持spring cloud；
7、提供框架层面的幂等性解决方案；
1. 性能和时延问题
在服务化之前，业务通常都是本地API调用，本地方法调用性能损耗较小。服务化之后，服务提供者和消费者之间采用远程网络通信，增加了额外的性能损耗：
1） 客户端需要对消息进行序列化，主要占用CPU计算资源。
2） 序列化时需要创建二进制数组，耗费JVM堆内存或者堆外内存。
3） 客户端需要将序列化之后的二进制数组发送给服务端，占用网络带宽资源。
4） 服务端读取到码流之后，需要将请求数据报反序列化成请求对象，占用CPU计算资源。
5） 服务端通过反射的方式调用服务提供者实现类，反射本身对性能影响就比较大。
6） 服务端将响应结果序列化，占用CPU计算资源。
7） 服务端将应答码流发送给客户端，占用网络带宽资源。
8） 客户端读取应答码流，反序列化成响应消息，占用CPU资源。
通过分析我们发现，一个简单的本地方法调用，切换成远程服务调用之后，额外增加了很多处理流程，不仅占用大量的系统资源，同时增加了时延。一些复杂
的应用会拆分成多个服务，形成服务调用链，如果服务化框架的性能比较差、服务调用时延也比较大，业务服务化之后的性能和时延将无法满足业务的性能需求。
1.1　RPC框架高性能设计
影响RPC框架性能的主要因素有三个。
1） I/O调度模型：同步阻塞I/O（BIO）还是非阻塞I/O（NIO）。
2） 序列化框架的选择：文本协议、二进制协议或压缩二进制协议。
3） 线程调度模型：串行调度还是并行调度，锁竞争还是无锁化算法。
1. I/O调度模型
在I/O编程过程中，当需要同时处理多个客户端接入请求时，可以利用多线程或者I/O多路复用技术进行处理。I/O多路复用技术通过把多个I/O的
阻塞复用到同一个select的阻塞上，从而使得系统在单线程的情况下可以同时处理多个客户端请求。与传统的多线程/多进程模型比，I/O多路复用的最大
优势是系统开销小，系统不需要创建新的额外进程或者线程，也不需要维护这些进程和线程的运行，降低了系统的维护工作量，节省了系统资源。
JDK1.5_update10版本使用epoll替代了传统的select/poll，极大地提升了NIO通信的性能，它的工作原理如图1-1所示。
图1-1　非阻塞I/O工作原理
Netty是一个开源的高性能NIO通信框架：它的I/O线程NioEventLoop由于聚合了多路复用器Selector，可以同时并发处理成
百上千个客户端Channel。由于读写操作都是非阻塞的，这就可以充分提升I/O线程的运行效率，避免由于频繁I/O阻塞导致的线程挂起。另外，由于
Netty采用了异步通信模式，一个I/O线程可以并发处理N个客户端连接和读写操作，这从根本上解决了传统同步阻塞I/O一连接一线程模型，架构的性能、弹性伸缩能力和可靠性都得到了极大的提升。
Netty被精心设计，提供了很多独特的性能提升特性，使它做到了在各种NIO框架中性能排名第一，它的性能优化措施总结如下。
1） 零拷贝：（1）Netty的接收和发送ByteBuffer采用DIRECT
BUFFERS，使用堆外直接内存进行Socket读写，不需要进行字节缓冲区的二次拷贝。如果使用传统的堆内存（HEAP
BUFFERS）进行Socket读写，JVM会将堆内存Buffer拷贝一份到直接内存中，然后才写入Socket中。相比于堆外直接内存，消息在发送
过程中多了一次缓冲区的内存拷贝。（2）Netty提供了组合Buffer对象，可以聚合多个ByteBuffer对象，用户可以像操作一个Buffer
那样方便地对组合Buffer进行操作，避免了传统通过内存拷贝的方式将几个小Buffer合并成一个大的Buffer。（3）Netty的文件传输采用
了transferTo方法，它可以直接将文件缓冲区的数据发送到目标Channel，避免了传统通过循环write方式导致的内存拷贝问题。
2）
内存池：随着JVM虚拟机和JIT即时编译技术的发展，对象的分配和回收是个非常轻量级的工作。但是对于缓冲区Buffer，情况却稍有不同，特别是对于
堆外直接内存的分配和回收，是一件耗时的操作。为了尽量重用缓冲区，Netty提供了基于内存池的缓冲区重用机制。性能测试表明，采用内存池的
ByteBuf相比于朝生夕灭的ByteBuf，性能高23倍左右（性能数据与使用场景强相关）。
3）
无锁化的串行设计：在大多数场景下，并行多线程处理可以提升系统的并发性能。但是，如果对于共享资源的并发访问处理不当，会带来严重的锁竞争，这最终会导
致性能的下降。为了尽可能地避免锁竞争带来的性能损耗，可以通过串行化设计，即消息的处理尽可能在同一个线程内完成，期间不进行线程切换，这样就避免了多
线程竞争和同步锁。为了尽可能提升性能，Netty采用了串行无锁化设计，在I/O线程内部进行串行操作，避免多线程竞争导致的性能下降。表面上看，串行
化设计似乎CPU利用率不高，并发程度不够。但是，通过调整NIO线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设
计相比一个队列-多个工作线程模型性能更优。
4） 高效的并发编程：volatile的大量、正确使用；CAS和原子类的广泛使用；线程安全容器的使用；通过读写锁提升并发性能。
2. 高性能序列化框架
影响序列化性能的关键因素总结如下。
1） 序列化后的码流大小（网络带宽的占用）。
2） 序列化&反序列化的性能（CPU资源占用）。
3） 是否支持跨语言（异构系统的对接和开发语言切换）。
4） 并发调用的性能表现：稳定性、线性增长、偶现的时延毛刺等。
相比于JSON等文本协议，二进制序列化框架性能更优异，以Java原生序列化和Protobuf二进制序列化为例进行性能测试对比，结果如图1-2所示。
图1-2　序列化性能测试对比数据
在序列化框架的技术选型中，如无特殊要求，尽量选择性能更优的二进制序列化框架，码流是否压缩，则需要根据通信内容做灵活选择，对于图片、音频、有大量重复内容的文本文件（例如小说）可以采用码流压缩，常用的压缩算法包括GZip、Zig-Zag等。
3. 高性能的Reactor线程模型
该模型的特点总结如下。
1） 有专门一个NIO线程：Acceptor线程用于监听服务端，接收客户端的TCP连接请求。
2） 网络I/O操作：读、写等由一个NIO线程池负责，线程池可以采用标准的JDK线程池实现，它包含一个任务队列和N个可用的线程，由这些NIO线程负责消息的读取、解码、编码和发送。
3） 1个NIO线程可以同时处理N条链路，但是1个链路只对应1个NIO线程，防止产生并发操作。
由于Reactor模式使用的是异步非阻塞I/O，所有的I/O操作都不会导致阻塞，理论上一个线程可以独立处理所有I/O相关的操作，因此在绝大多数场景下，Reactor多线程模型都可以完全满足业务性能需求。
Reactor线程调度模型的工作原理示意如图1-3所示。
图1-3　高性能的Reactor线程调度模型
1.2　业务最佳实践
要保证高性能，单依靠分布式服务框架是不够的，还需要应用的配合，应用服务化高性能实践总结如下：
1） 能异步的尽可能使用异步或者并行服务调用，提升服务的吞吐量，有效降低服务调用时延。
2） 无论是NIO通信框架的线程池还是后端业务线程池，线程参数的配置必须合理。如果采用JDK默认的线程池，最大线程数建议不超过20个。因为JDK的线程池默认采用N个线程争用1个同步阻塞队列方式，当线程数过大时，会导致激烈的锁竞争，此时性能不仅不会提升，反而会下降。
3）
尽量减小要传输的码流大小，提升性能。本地调用时，由于在同一块堆内存中访问，参数大小对性能没有任何影响。跨进程通信时，往往传递的是个复杂对象，如果
明确对方只使用其中的某几个字段或者某个对象引用，则不要把整个复杂对象都传递过去。举例，对象A持有8个基本类型的字段，2个复杂对象B和C。如果明确
服务提供者只需要用到A聚合的C对象，则请求参数应该是C，而不是整个对象A。
4） 设置合适的客户端超时时间，防止业务高峰期因为服务端响应慢导致业务线程等应答时被阻塞，进而引起后续其他服务的消息在队列中排队，造成故障扩散。
5） 对于重要的服务，可以单独部署到独立的服务线程池中，与其他非核心服务做隔离，保障核心服务的高效运行。
6） 利用Docker等轻量级OS容器部署服务，对服务做物理资源层隔离，避免虚拟化之后导致的超过20%的性能损耗。
7） 设置合理的服务调度优先级，并根据线上性能监控数据做实时调整。
2. 事务一致性问题
服务化之前，业务采用本地事务，多个本地SQL调用可以用一个大的事务块封装起来，如果某一个数据库操作发生异常，就可以将之前的SQL操作进行回滚，只有所有SQL操作全部成功，才最终提交，这就保证了事务强一致性，如图2-1所示。
服务化之后，三个数据库操作可能被拆分到独立的三个数据库访问服务中，此时原来的本地SQL调用演变成了远程服务调用，事务一致性无法得到保证，如图2-2所示。
图2-2　服务化之后引入分布式事务问题
假如服务A和服务B调用成功，则A和B的SQL将会被提交，最后执行服务C，它的SQL操作失败，对于应用1消费者而言，服务A和服务B的相关
SQL操作已经提交，服务C发生了回滚，这就导致事务不一致。从图2-2可以得知，服务化之后事务不一致主要是由服务分布式部署导致的，因此也被称为分布
式事务问题。
2.1　分布式事务设计方案
通常，分布式事务基于两阶段提交实现，它的工作原理示意图如图2-3所示。
图2-3　两阶段提交原理图
阶段1：全局事务管理器向所有事务参与者发送准备请求；事务参与者向全局事务管理器回复自己是否准备就绪。
阶段2：全局事务管理器接收到所有事务参与者的回复之后做判断，如果所有事务参与者都可以提交，则向所有事务提交者发送提交申请，否则进行回滚。事务参与者根据全局事务管理器的指令进行提交或者回滚操作。
分布式事务回滚原理图如图2-4所示。
图2-4　分布式事务回滚原理图
两阶段提交采用的是悲观锁策略，由于各个事务参与者需要等待响应最慢的参与者，因此性能比较差。第一个问题是协议本身的成本：整个协议过程是需要加
锁的，比如锁住数据库的某条记录，且需要持久化大量事务状态相关的操作日志。更为麻烦的是，两阶段锁在出现故障时表现出来的脆弱性，比如两阶段锁的致命缺
陷：当协调者出现故障，整个事务需要等到协调者恢复后才能继续执行，如果协调者出现类似磁盘故障等错误，该事务将被永久遗弃。
对于分布式服务框架而言，从功能特性上需要支持分布式事务。在实际业务使用过程中，如果能够通过最终一致性解决问题，则不需要做强一致性；如果能够避免分布式事务，则尽量在业务层避免使用分布式事务。
2.2　分布式事务优化
既然分布式事务有诸多缺点，那么为什么我们还在使用呢？有没有更好的解决方案来改进或者替换呢？如果我们只是针对分布式事务去优化的话，发现其实能改进的空间很小，毕竟瓶颈在分布式事务模型本身。
那我们回到问题的根源：为什么我们需要分布式事务？因为我们需要各个资源数据保持一致性，但是对于分布式事务提供的强一致性，所有业务场景真的都需
要吗？大多数业务场景都能容忍短暂的不一致，不同的业务对不一致的容忍时间不同。像银行转账业务，中间有几分钟的不一致时间，用户通常都是可以理解和容忍
的。
在大多数的业务场景中，我们可以使用最终一致性替代传统的强一致性，尽量避免使用分布式事务。
在实践中常用的最终一致性方案就是使用带有事务功能的MQ做中间人角色，它的工作原理如下：在做本地事务之前，先向MQ发送一个prepare消
息，然后执行本地事务，本地事务提交成功的话，向MQ发送一个commit消息，否则发送一个rollback消息，取消之前的消息。MQ只会在收到
commit确认才会将消息投递出去，所以这样的形式可以保证在一切正常的情况下，本地事务和MQ可以达到一致性。但是分布式调用存在很多异常场景，诸如
网络超时、VM宕机等。假如系统执行了local_tx()成功之后，还没来得及将commit消息发送给MQ，或者说发送出去由于网络超时等原因，MQ
没有收到commit，发生了commit消息丢失，那么MQ就不会把prepare消息投递出去。MQ会根据策略去尝试询问（回调）发消息的系统
（checkCommit）进行检查该消息是否应该投递出去或者丢弃，得到系统的确认之后，MQ会做投递还是丢弃，这样就完全保证了MQ和发消息的系统的
一致性，从而保证了接收消息系统的一致性。
3. 研发团队协作问题
服务化之后，特别是采用微服务架构以后。研发团队会被拆分成多个服务化小组，例如AWS的Two Pizza Team，每个团队由2~3名研发负责服务的开发、测试、部署上线、运维和运营等。
随着服务数的膨胀，研发团队的增多，跨团队的协同配合将会成为一个制约研发效率提升的因素。
3.1　共用服务注册中心
为了方便开发测试，经常会在线下共用一个所有服务共享的服务注册中心，这时，一个正在开发中的服务发布到服务注册中心，可能会导致一些消费者不可用。
解决方案：可以让服务提供者开发方，只订阅服务（开发的服务可能依赖其他服务），而不注册正在开发的服务，通过直连测试正在开发的服务。
它的工作原理如图3-1所示。
图3-1　只订阅，不发布
3.2　直连提供者
在开发和测试环境下，如果公共的服务注册中心没有搭建，消费者将无法获取服务提供者的地址列表，只能做本地单元测试或使用模拟桩测试。
还有一种场景就是在实际测试中，服务提供者往往多实例部署，如果服务提供者存在Bug，就需要做远程断点调试，这会带来两个问题：
1） 服务提供者多实例部署，远程调试地址无法确定，调试效率低下。
2） 多个消费者可能共用一套测试联调环境，断点调试过程中可能被其他消费者意外打断。
解决策略：绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直联方式将以服务接口为单位，忽略注册中心的提供者列表。
3.3　多团队进度协同
假如前端Web门户依赖后台A、B、C和D
4个服务，分别由4个不同的研发团队负责，门户要求新特性2周内上线。A和B内部需求优先级排序将门户的优先级排的比较高，可以满足交付时间点。但是C和
D服务所在团队由于同时需要开发其他优先级更高的服务，因此把优先级排的相对较低，无法满足2周交付。
在C和D提供版本之前，门户只能先通过打测试桩的方式完成Mock测试，但是由于并没有真实的测试过C和D服务，因此需求无法按期交付。
应用依赖的服务越多，特性交付效率就越低下，交付的速度取决于依赖的最迟交付的那个服务。假如Web门户依赖后台的100个服务，只要1个核心服务没有按期交付，则整个进度就会延迟。
解决方案：调用链可以将应用、服务和中间件之间的依赖关系串接并展示出来，基于调用链首入口的交付日期作为输入，利用依赖管理工具，可以自动计算出调用链上各个服务的最迟交付时间点。通过调用链分析和标准化的依赖计算工具，可以避免人为需求排序失误导致的需求延期。
3.4　服务降级和Mock测试
在实际项目开发中，由于小组之间、个人开发者之间开发节奏不一致，经常会出现消费者等待依赖的服务提供者提供联调版本的情况，相互等待会降低项目的研发进度。
解决方案：服务提供者首先将接口定下来并提供给消费者，消费者可以将服务降级同Mock测试结合起来，在Mock测试代码中实现容错降级的业务逻辑（业务放通），这样既完成了Mock测试，又实现了服务降级的业务逻辑开发，一举两得。
3.5　协同调试问题
在实际项目开发过程中，各研发团队进度不一致很正常。如果消费者坐等服务提供者按时提供版本，往往会造成人力资源浪费，影响项目进度。
解决方案：分布式服务框架提供Mock桩管理框架，当周边服务提供者尚未完成开发时，将路由切换到模拟测试模式，自动调用Mock桩；业务集成测试和上线时，则要能够自动切换到真实的服务提供者上，可以结合服务降级功能实现。
3.6　接口前向兼容性
由于线上的Bug修复、内部重构和需求变更，服务提供者会经常修改内部实现，包括但不限于：接口参数变化、参数字段变化、业务逻辑变化和数据表结构变化。
在实际项目中经常会发生服务提供者修改了接口或者数据结构，但是并没有及时知会到所有消费者，导致服务调用失败。
解决方案：
1） 制定并严格执行《服务前向兼容性规范》，避免发生不兼容修改或者私自修改不通知周边的情况。
2） 接口兼容性技术保障：例如Thrift的IDL，支持新增、修改和删除字段，字段定义位置无关性，码流支持乱序等。
分布式系统架构中，分布式事务问题是一个绕不过去的挑战。而微服务架构的流行，让分布式事问题日益突出！
下面我们以电商购物支付流程中，在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析！
如上图所示，假设三大参与平台（电商平台、支付平台、银行）的系统都做了分布式系统架构拆分，按上数中的流程步骤进行分析：
1、电商平台中创建订单：预留库存、预扣减积分、锁定优惠券，此时电商平台内各服务间会有分布式事务问题，因为此时已经要跨多个内部服务修改数据；
2、支付平台中创建支付订单（选银行卡支付）：查询账户、查询限制规则，符合条件的就创建支付订单并跳转银行，此时不会有分布式事务问题，因为还不会跨服务改数据；
3、银行平台中创建交易订单：查找账户、创建交易记录、判断账户余额并扣款、增加积分、通知支付平台，此时也会有分布式事务问题（如果是服务化架构的话）；
4、支付平台收到银行扣款结果：更改订单状态、给账户加款、给积分帐户增加积分、生成会计分录、通知电商平台等，此时也会有分布式事务问题；
5、电商平台收到支付平台的支付结果：更改订单状态、扣减库存、扣减积分、使用优惠券、增加消费积分等，系统内部各服务间调用也会遇到分布式事问题；
如上图，支付平台收到银行扣款结果后的内部处理流程：
1、支付平台的支付网关对银行通知结果进行校验，然后调用支付订单服务执行支付订单处理；
2、支付订单服务根据银行扣款结果更改支付订单状态；
3、调用资金账户服务给电商平台的商户账户加款（实际过程中可能还会有各种的成本计费；如果是余额支付，还可能是同时从用户账户扣款，给商户账户加款）；
4、调用积分服务给用户积分账户增加积分；
5、调用会计服务向会计（财务）系统写进交易原始凭证生成会计分录；
6、调用通知服务将支付处理结果通知电商平台；
如上图，把支付系统中的银行扣款成功回调处理流程提取出来，对应的分布式事务问题的代码场景：
/** 支付订单处理 **/
@Transactional(rollbackFor = Exception.class)
public void completeOrder() {
orderDao.update(); // 订单服务本地更新订单状态
accountService.update(); // 调用资金账户服务给资金帐户加款
pointService.update(); // 调用积分服务给积分帐户增加积分
accountingService.insert(); // 调用会计服务向会计系统写入会计原始凭证
merchantNotifyService.notify(); // 调用商户通知服务向商户发送支付结果通知
}
本地事务控制还可行吗？
以上分布式事务问题，需要多种分布式事务解决方案来进行处理。
订单处理：本地事务
资金账户加款、积分账户增加积分：TCC型事务（或两阶段提交型事务），实时性要求比较高，数据必须可靠。
会计记账：异步确保型事务（基于可靠消息的最终一致性，可以异步，但数据绝对不能丢，而且一定要记账成功）
商户通知：最大努力通知型事务（按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对）

类似mina的tcp框架还有哪些

mina与netty都是Trustin Lee的作品，所以在很多方面都十分相似，他们线程模型也是基本一致，采用了Reactors in threads模型，即Main Reactor + Sub Reactors的模式。由main reactor处理连接相关的任务：accept、connect等，当连接处理完毕并建立

什么是NIO框架

Java NIO框架MINA用netty性能和链接数、并发等压力测试参数好于mina。
特点：
1。NIO弥补了原来的I/O的不足，它再标准java代码中提供了高速和面向块的I/O
原力的I/O库与NIO最重要的区别是数据打包和传输方式的不同，原来的I/O以流的方式处理数据，而NIO以块的方式处理数据；
2.NIO以通道channel和缓冲区Buffer为基础来实现面向块的IO数据处理，MINA是开源的。
JavaNIO非堵塞应用通常适用用在I/O读写等方面，我们知道，系统运行的性能瓶颈通常在I/O读写，包括对端口和文件的操作上，过去，在打开一个I/O通道后，read()将一直等待在端口一边读取字节内容，如果没有内容进来，read()也是傻傻的等，这会影响我们程序继续做其他事情，那么改进做法就是开设线程，让线程去等待，但是这样做也是相当耗费资源的。
Java NIO非堵塞技术实际是采取Reactor模式，或者说是Observer模式为我们监察I/O端口，如果有内容进来，会自动通知我们，这样，我们就不必开启多个线程死等，从外界看，实现了流畅的I/O读写，不堵塞了。
Java NIO出现不只是一个技术性能的提高，会发现网络上到处在介绍它，因为它具有里程碑意义，从JDK1.4开始，Java开始提高性能相关的功能，从而使得Java在底层或者并行分布式计算等操作上已经可以和C或Perl等语言并驾齐驱。
如果至今还是在怀疑Java的性能，说明思想和观念已经完全落伍了，Java一两年就应该用新的名词来定义。从JDK1.5开始又要提供关于线程、并发等新性能的支持，Java应用在游戏等适时领域方面的机会已经成熟，Java在稳定自己中间件地位后，开始蚕食传统C的领域。
原理：
NIO 有一个主要的类Selector,这个类似一个观察者，只要我们把需要探知告诉Selector,我们接着做别的事情，当有事件发生时，他会通知我们，传回一组,我们读取这些Key,就会获得我们刚刚注册过的,然后，我们从这个Channel中读取数据，放心，包准能够读到，接着我们可以处理这些数据。Selector内部原理实际是在做一个对所注册的channel的轮询访问，不断的轮询(目前就这一个算法)，一旦轮询到一个channel有所注册的事情发生。比如数据来了，他就会站起来报告，交出一把钥匙，让我们通过这把钥匙来读取这个channel的内容。在使用上，也在分两个方向，一个是线程处理，一个是用非线程，后者比较简单。

面试题：Java框架Netty的io结构是什么？

主从Reactor多线程Nio结构，主从Reactor线程模型的特点是：服务端用于接收客户端连接的不再是个1个单独的NIO线程，而是一个独立的NIO线程池。Acceptor接收到客户端TCP连接请求处理完成后（可能包含接入认证等），将新创建的SocketChannel注册到IO线程池（sub reactor线程池）的某个IO线程上，由它负责SocketChannel的读写和编解码工作。Acceptor线程池仅仅只用于客户端的登陆、握手和安全认证，一旦链路建立成功，就将链路注册到后端subReactor线程池的IO线程上，由IO线程负责后续的IO操作。\x0d\x0a利用主从NIO线程模型，可以解决1个服务端监听线程无法有效处理所有客户端连接的性能不足问题。\x0d\x0a它的工作流程总结如下：\x0d\x0a从主线程池中随机选择一个Reactor线程作为Acceptor线程，用于绑定监听端口，接收客户端连接；\x0d\x0aAcceptor线程接收客户端连接请求之后创建新的SocketChannel，将其注册到主线程池的其它Reactor线程上，由其负责接入认证、IP黑白名单过滤、握手等操作；\x0d\x0a步骤2完成之后，业务层的链路正式建立，将SocketChannel从主线程池的Reactor线程的多路复用器上摘除，重新注册到Sub线程池的线程上，用于处理I/O的读写操作。