Spring+Reactive

Spring+Reactive

idea项目中使用Reactor 的EventBus报找不到import javax.annotation.Nonnull; import javax.annotation.Nullable;

回复

全栈开发cloud 发起了问题 • 1 人关注 • 0 个回复 • 859 次浏览 • 2017-11-21 10:22 • 来自相关话题

什么是 Reactor?

全栈开发cloud 发表了文章 • 0 个评论 • 792 次浏览 • 2017-11-21 10:16 • 来自相关话题

简单说,Reactor 是一个轻量级 JVM 基础库,帮助你的服务或应用高效,异步地传递消息。

 "高效"是指什么?
     消息从A传递到B时,产生很少的    内存    *垃圾,甚至不产生。
     解决消费者处理消息的效率低于生产者时带来的    溢出    *问题。
     尽可能提供非阻塞    异步流    *。
从经验可知(主要是 #rage 和 #drunk 的推特),异步编程很难,而像 JVM 这类提供众多可选参数的平台则尤其困难。 Reactor 旨在帮助大多数用例真正非阻塞地运行。我们提供的 API 比 JDK 的 java.util.concurrent 库低级原语更高效。Reactor 提供了下列功能的替代函数 (并建议不使用 JDK 原生语句):

• 阻塞等待:如 Future.get()
• 不安全的数据访问:如 ReentrantLock.lock()
• 异常冒泡:如 try…catch…finally
• 同步阻塞:如 synchronized{ }
• Wrapper分配(GC 压力):如 new Wrapper<T>(event)
当消息传递效率成为系统性能瓶颈的时候(10k msg/s,100k msg/s,1M...),非阻塞机制就显得尤为重要。
虽然这个有理论支持 (参见 Amdahl’s Law(http://en.wikipedia.org/wiki/Amdahl%27s_law)),但读起来太无聊了。我们举例说明,比如你用了个 Executor(https://docs.oracle.com/javase ... s.html) 方法:
private ExecutorService  threadPool = Executors.newFixedThreadPool(8);

final List<T> batches = new ArrayList<T>();

Callable<T> t = new Callable<T>() { // *1

        public T run() {
                synchronized(batches) { // *2
                        T result = callDatabase(msg); // *3
                        batches.add(result);
                        return result;
                }
        }
};

Future<T> f = threadPool.submit(t); // *4
T result = f.get() // *5

1. Callable 分配 -- 可能导致 GC 压力。
2. 同步过程强制每个线程执行停-检查操作。
3. 消息的消费可能比生产慢。
4. 使用线程池(ThreadPool)将任务传递给目标线程 -- 通过 FutureTask 方式肯定会产生 GC 压力。
5. 阻塞直至 callDatabase() 回调。
在这个简单的例子中,很容易指出为什么扩容是很有限的:

• 分配对象可能产生GC压力,特别是当任务运行时间过长。
• 每次 GC 暂停都会影响全局性能。
• 默认,队列是无界的,任务会因为数据库调用而堆积。
• 积压虽然不会直接导致内存泄漏,但会带来严重副作用:GC 暂停时要扫描更多的对象;有丢失重要数据位的风险;等等 …
• 典型链式队列节点分配时会产生大量内存压力。
• 阻塞回调容易产生恶性循环。
• 阻塞回调会降低消息生产者的效率。在实践中,任务提交后需要等待结果返回,此时流式过程几乎演变为同步的了。
• 会话过程抛出的任何带数据存储的异常都会以不受控的方式被传递给生产者,否定了任何通常在线程边界附近可用的容错性。
要实现完全非阻塞是很难办到的,尤其是在有着类似微服务架构这样时髦绰号的分布式系统的世界里。因此 Reactor 做了部分妥协,尝试利用最优的可用模式,使开发者觉得他们是在写异步纳米服务,而不是什么数学论文。
没有什么传播得比光快(除了绯闻和网红猫的视频),正如到了某个阶段,延迟是每一个系统到都要面对的实实在在的问题。为此:

 Reactor 提供的框架可以帮助减轻应用中由延迟产生的副作用,只需要增加一点点开销:
     使用了一些聪明的结构,通过启动预分配策略解决运行时    分配问题    *;
     通过确定信息传递主结构的    边界    *,避免任务的无限堆叠;
     采用主流的    响应与事件驱动构架    模式,提供包含反馈在内的    非阻塞端对端流    *;
    * 引入新的     Reactive Streams(http://projectreactor.io/docs/ ... treams)    标准,拒绝超过当前容量请求,从而保证限制结构的有效性;
     在    IPC(http://projectreactor.io/docs/ ... erview)    上也使用了类似理念,提供对流控制友好的    非阻塞 IO 驱动    *;
     开放了帮助开发者们以    零副作用    *方式组织他们代码的函数接口,借助这些函数来处理容错性和线程安全。
关于该项目
该项目始于 2012 年。 经过长时间的内部孵化,于 2013 年发布 Reactor 1.x 版本。 Reactor 1 在各种架构下都能成功部署,包括开源的(如 Meltdown)和商业的(如 Pivotal RTI)。2014年,我们开始与一些新兴的响应式数据流规范(http://projectreactor.io/docs/ ... treams)合作,重新设计并于 2015年4月发布 Reactor 2.0版本。响应式数据流规范填补了指派机制的最后一个缺口:传输过程中,数据设置多大,才不会触发线程边界问题
同时,随着响应式扩展(http://projectreactor.io/docs/ ... l%23rx)日益普及,文档逐渐完善,我们也不断调整部分事件驱动和任务协作类 API。
Pivotal(http://pivotal.io/) 不仅是 Spring 框架发起者,许多员工都曾是各种 Spring 代码核心贡献者;Pivotal 也资助着 Reactor,两名 Reactor 核心开发人员在 Pitoval 工作。我们提供 Reactor 到 Spring 的整合支持,以及部分 Spring 框架重要功能的支持,如 spring-messaging 的 STOMP 中继代理。尽管如此,我们并不强求使用 Reactor 用户必须采用 Spring。我们为"Reactive 大众"保留可嵌入工具箱。实际上,Reactor 仅仅致力于解决异步和函数调用问题。
Reactor 遵循 Apache 2.0 许可(http://www.apache.org/licenses/LICENSE-2.0.html),可在 GitHub(https://github.com/reactor/reactor) 上获取。
使用前提

• 使用 Reactor,Java 版本最低需要 Java 7。
• 若要充分发挥函数组件潜力,需要 Java 8 Lambdas 支持。
• 采用 Spring,Clojure 和 Groovy 扩展作为后备。
• JVM 支持非安全访问时 Reactor 可满负荷运行 (比如不是Android的情况)。
• 若没有非安全访问策略,基于环形缓冲区的所有特性都不起作用。
• Reactor 在 Maven Central 中以传统 JAR 格式打包,你可以用你所习惯的构建工具在任何 JVM 工程中安装该依赖。 查看全部
简单说,Reactor 是一个轻量级 JVM 基础库,帮助你的服务或应用高效,异步地传递消息。

 "高效"是指什么?
     消息从A传递到B时,产生很少的    内存    *垃圾,甚至不产生。
     解决消费者处理消息的效率低于生产者时带来的    溢出    *问题。
     尽可能提供非阻塞    异步流    *。
从经验可知(主要是 #rage 和 #drunk 的推特),异步编程很难,而像 JVM 这类提供众多可选参数的平台则尤其困难。 Reactor 旨在帮助大多数用例真正非阻塞地运行。我们提供的 API 比 JDK 的 java.util.concurrent 库低级原语更高效。Reactor 提供了下列功能的替代函数 (并建议不使用 JDK 原生语句):

• 阻塞等待:如 Future.get()
• 不安全的数据访问:如 ReentrantLock.lock()
• 异常冒泡:如 try…catch…finally
• 同步阻塞:如 synchronized{ }
• Wrapper分配(GC 压力):如 new Wrapper<T>(event)
当消息传递效率成为系统性能瓶颈的时候(10k msg/s,100k msg/s,1M...),非阻塞机制就显得尤为重要。
虽然这个有理论支持 (参见 Amdahl’s Law(http://en.wikipedia.org/wiki/Amdahl%27s_law)),但读起来太无聊了。我们举例说明,比如你用了个 Executor(https://docs.oracle.com/javase ... s.html) 方法:
private ExecutorService  threadPool = Executors.newFixedThreadPool(8);

final List<T> batches = new ArrayList<T>();

Callable<T> t = new Callable<T>() { // *1

        public T run() {
                synchronized(batches) { // *2
                        T result = callDatabase(msg); // *3
                        batches.add(result);
                        return result;
                }
        }
};

Future<T> f = threadPool.submit(t); // *4
T result = f.get() // *5

1. Callable 分配 -- 可能导致 GC 压力。
2. 同步过程强制每个线程执行停-检查操作。
3. 消息的消费可能比生产慢。
4. 使用线程池(ThreadPool)将任务传递给目标线程 -- 通过 FutureTask 方式肯定会产生 GC 压力。
5. 阻塞直至 callDatabase() 回调。
在这个简单的例子中,很容易指出为什么扩容是很有限的:

• 分配对象可能产生GC压力,特别是当任务运行时间过长。
• 每次 GC 暂停都会影响全局性能。
• 默认,队列是无界的,任务会因为数据库调用而堆积。
• 积压虽然不会直接导致内存泄漏,但会带来严重副作用:GC 暂停时要扫描更多的对象;有丢失重要数据位的风险;等等 …
• 典型链式队列节点分配时会产生大量内存压力。
• 阻塞回调容易产生恶性循环。
• 阻塞回调会降低消息生产者的效率。在实践中,任务提交后需要等待结果返回,此时流式过程几乎演变为同步的了。
• 会话过程抛出的任何带数据存储的异常都会以不受控的方式被传递给生产者,否定了任何通常在线程边界附近可用的容错性。
要实现完全非阻塞是很难办到的,尤其是在有着类似微服务架构这样时髦绰号的分布式系统的世界里。因此 Reactor 做了部分妥协,尝试利用最优的可用模式,使开发者觉得他们是在写异步纳米服务,而不是什么数学论文。
没有什么传播得比光快(除了绯闻和网红猫的视频),正如到了某个阶段,延迟是每一个系统到都要面对的实实在在的问题。为此:

 Reactor 提供的框架可以帮助减轻应用中由延迟产生的副作用,只需要增加一点点开销:
     使用了一些聪明的结构,通过启动预分配策略解决运行时    分配问题    *;
     通过确定信息传递主结构的    边界    *,避免任务的无限堆叠;
     采用主流的    响应与事件驱动构架    模式,提供包含反馈在内的    非阻塞端对端流    *;
    * 引入新的     Reactive Streams(http://projectreactor.io/docs/ ... treams)    标准,拒绝超过当前容量请求,从而保证限制结构的有效性;
     在    IPC(http://projectreactor.io/docs/ ... erview)    上也使用了类似理念,提供对流控制友好的    非阻塞 IO 驱动    *;
     开放了帮助开发者们以    零副作用    *方式组织他们代码的函数接口,借助这些函数来处理容错性和线程安全。
关于该项目
该项目始于 2012 年。 经过长时间的内部孵化,于 2013 年发布 Reactor 1.x 版本。 Reactor 1 在各种架构下都能成功部署,包括开源的(如 Meltdown)和商业的(如 Pivotal RTI)。2014年,我们开始与一些新兴的响应式数据流规范(http://projectreactor.io/docs/ ... treams)合作,重新设计并于 2015年4月发布 Reactor 2.0版本。响应式数据流规范填补了指派机制的最后一个缺口:传输过程中,数据设置多大,才不会触发线程边界问题
同时,随着响应式扩展(http://projectreactor.io/docs/ ... l%23rx)日益普及,文档逐渐完善,我们也不断调整部分事件驱动和任务协作类 API。
Pivotal(http://pivotal.io/) 不仅是 Spring 框架发起者,许多员工都曾是各种 Spring 代码核心贡献者;Pivotal 也资助着 Reactor,两名 Reactor 核心开发人员在 Pitoval 工作。我们提供 Reactor 到 Spring 的整合支持,以及部分 Spring 框架重要功能的支持,如 spring-messaging 的 STOMP 中继代理。尽管如此,我们并不强求使用 Reactor 用户必须采用 Spring。我们为"Reactive 大众"保留可嵌入工具箱。实际上,Reactor 仅仅致力于解决异步和函数调用问题。
Reactor 遵循 Apache 2.0 许可(http://www.apache.org/licenses/LICENSE-2.0.html),可在 GitHub(https://github.com/reactor/reactor) 上获取。
使用前提

• 使用 Reactor,Java 版本最低需要 Java 7。
• 若要充分发挥函数组件潜力,需要 Java 8 Lambdas 支持。
• 采用 Spring,Clojure 和 Groovy 扩展作为后备。
• JVM 支持非安全访问时 Reactor 可满负荷运行 (比如不是Android的情况)。
• 若没有非安全访问策略,基于环形缓冲区的所有特性都不起作用。
• Reactor 在 Maven Central 中以传统 JAR 格式打包,你可以用你所习惯的构建工具在任何 JVM 工程中安装该依赖。

idea项目中使用Reactor 的EventBus报找不到import javax.annotation.Nonnull; import javax.annotation.Nullable;

回复

全栈开发cloud 发起了问题 • 1 人关注 • 0 个回复 • 859 次浏览 • 2017-11-21 10:22 • 来自相关话题

什么是 Reactor?

全栈开发cloud 发表了文章 • 0 个评论 • 792 次浏览 • 2017-11-21 10:16 • 来自相关话题

简单说,Reactor 是一个轻量级 JVM 基础库,帮助你的服务或应用高效,异步地传递消息。

 "高效"是指什么?
     消息从A传递到B时,产生很少的    内存    *垃圾,甚至不产生。
     解决消费者处理消息的效率低于生产者时带来的    溢出    *问题。
     尽可能提供非阻塞    异步流    *。
从经验可知(主要是 #rage 和 #drunk 的推特),异步编程很难,而像 JVM 这类提供众多可选参数的平台则尤其困难。 Reactor 旨在帮助大多数用例真正非阻塞地运行。我们提供的 API 比 JDK 的 java.util.concurrent 库低级原语更高效。Reactor 提供了下列功能的替代函数 (并建议不使用 JDK 原生语句):

• 阻塞等待:如 Future.get()
• 不安全的数据访问:如 ReentrantLock.lock()
• 异常冒泡:如 try…catch…finally
• 同步阻塞:如 synchronized{ }
• Wrapper分配(GC 压力):如 new Wrapper<T>(event)
当消息传递效率成为系统性能瓶颈的时候(10k msg/s,100k msg/s,1M...),非阻塞机制就显得尤为重要。
虽然这个有理论支持 (参见 Amdahl’s Law(http://en.wikipedia.org/wiki/Amdahl%27s_law)),但读起来太无聊了。我们举例说明,比如你用了个 Executor(https://docs.oracle.com/javase ... s.html) 方法:
private ExecutorService  threadPool = Executors.newFixedThreadPool(8);

final List<T> batches = new ArrayList<T>();

Callable<T> t = new Callable<T>() { // *1

        public T run() {
                synchronized(batches) { // *2
                        T result = callDatabase(msg); // *3
                        batches.add(result);
                        return result;
                }
        }
};

Future<T> f = threadPool.submit(t); // *4
T result = f.get() // *5

1. Callable 分配 -- 可能导致 GC 压力。
2. 同步过程强制每个线程执行停-检查操作。
3. 消息的消费可能比生产慢。
4. 使用线程池(ThreadPool)将任务传递给目标线程 -- 通过 FutureTask 方式肯定会产生 GC 压力。
5. 阻塞直至 callDatabase() 回调。
在这个简单的例子中,很容易指出为什么扩容是很有限的:

• 分配对象可能产生GC压力,特别是当任务运行时间过长。
• 每次 GC 暂停都会影响全局性能。
• 默认,队列是无界的,任务会因为数据库调用而堆积。
• 积压虽然不会直接导致内存泄漏,但会带来严重副作用:GC 暂停时要扫描更多的对象;有丢失重要数据位的风险;等等 …
• 典型链式队列节点分配时会产生大量内存压力。
• 阻塞回调容易产生恶性循环。
• 阻塞回调会降低消息生产者的效率。在实践中,任务提交后需要等待结果返回,此时流式过程几乎演变为同步的了。
• 会话过程抛出的任何带数据存储的异常都会以不受控的方式被传递给生产者,否定了任何通常在线程边界附近可用的容错性。
要实现完全非阻塞是很难办到的,尤其是在有着类似微服务架构这样时髦绰号的分布式系统的世界里。因此 Reactor 做了部分妥协,尝试利用最优的可用模式,使开发者觉得他们是在写异步纳米服务,而不是什么数学论文。
没有什么传播得比光快(除了绯闻和网红猫的视频),正如到了某个阶段,延迟是每一个系统到都要面对的实实在在的问题。为此:

 Reactor 提供的框架可以帮助减轻应用中由延迟产生的副作用,只需要增加一点点开销:
     使用了一些聪明的结构,通过启动预分配策略解决运行时    分配问题    *;
     通过确定信息传递主结构的    边界    *,避免任务的无限堆叠;
     采用主流的    响应与事件驱动构架    模式,提供包含反馈在内的    非阻塞端对端流    *;
    * 引入新的     Reactive Streams(http://projectreactor.io/docs/ ... treams)    标准,拒绝超过当前容量请求,从而保证限制结构的有效性;
     在    IPC(http://projectreactor.io/docs/ ... erview)    上也使用了类似理念,提供对流控制友好的    非阻塞 IO 驱动    *;
     开放了帮助开发者们以    零副作用    *方式组织他们代码的函数接口,借助这些函数来处理容错性和线程安全。
关于该项目
该项目始于 2012 年。 经过长时间的内部孵化,于 2013 年发布 Reactor 1.x 版本。 Reactor 1 在各种架构下都能成功部署,包括开源的(如 Meltdown)和商业的(如 Pivotal RTI)。2014年,我们开始与一些新兴的响应式数据流规范(http://projectreactor.io/docs/ ... treams)合作,重新设计并于 2015年4月发布 Reactor 2.0版本。响应式数据流规范填补了指派机制的最后一个缺口:传输过程中,数据设置多大,才不会触发线程边界问题
同时,随着响应式扩展(http://projectreactor.io/docs/ ... l%23rx)日益普及,文档逐渐完善,我们也不断调整部分事件驱动和任务协作类 API。
Pivotal(http://pivotal.io/) 不仅是 Spring 框架发起者,许多员工都曾是各种 Spring 代码核心贡献者;Pivotal 也资助着 Reactor,两名 Reactor 核心开发人员在 Pitoval 工作。我们提供 Reactor 到 Spring 的整合支持,以及部分 Spring 框架重要功能的支持,如 spring-messaging 的 STOMP 中继代理。尽管如此,我们并不强求使用 Reactor 用户必须采用 Spring。我们为"Reactive 大众"保留可嵌入工具箱。实际上,Reactor 仅仅致力于解决异步和函数调用问题。
Reactor 遵循 Apache 2.0 许可(http://www.apache.org/licenses/LICENSE-2.0.html),可在 GitHub(https://github.com/reactor/reactor) 上获取。
使用前提

• 使用 Reactor,Java 版本最低需要 Java 7。
• 若要充分发挥函数组件潜力,需要 Java 8 Lambdas 支持。
• 采用 Spring,Clojure 和 Groovy 扩展作为后备。
• JVM 支持非安全访问时 Reactor 可满负荷运行 (比如不是Android的情况)。
• 若没有非安全访问策略,基于环形缓冲区的所有特性都不起作用。
• Reactor 在 Maven Central 中以传统 JAR 格式打包,你可以用你所习惯的构建工具在任何 JVM 工程中安装该依赖。 查看全部
简单说,Reactor 是一个轻量级 JVM 基础库,帮助你的服务或应用高效,异步地传递消息。

 "高效"是指什么?
     消息从A传递到B时,产生很少的    内存    *垃圾,甚至不产生。
     解决消费者处理消息的效率低于生产者时带来的    溢出    *问题。
     尽可能提供非阻塞    异步流    *。
从经验可知(主要是 #rage 和 #drunk 的推特),异步编程很难,而像 JVM 这类提供众多可选参数的平台则尤其困难。 Reactor 旨在帮助大多数用例真正非阻塞地运行。我们提供的 API 比 JDK 的 java.util.concurrent 库低级原语更高效。Reactor 提供了下列功能的替代函数 (并建议不使用 JDK 原生语句):

• 阻塞等待:如 Future.get()
• 不安全的数据访问:如 ReentrantLock.lock()
• 异常冒泡:如 try…catch…finally
• 同步阻塞:如 synchronized{ }
• Wrapper分配(GC 压力):如 new Wrapper<T>(event)
当消息传递效率成为系统性能瓶颈的时候(10k msg/s,100k msg/s,1M...),非阻塞机制就显得尤为重要。
虽然这个有理论支持 (参见 Amdahl’s Law(http://en.wikipedia.org/wiki/Amdahl%27s_law)),但读起来太无聊了。我们举例说明,比如你用了个 Executor(https://docs.oracle.com/javase ... s.html) 方法:
private ExecutorService  threadPool = Executors.newFixedThreadPool(8);

final List<T> batches = new ArrayList<T>();

Callable<T> t = new Callable<T>() { // *1

        public T run() {
                synchronized(batches) { // *2
                        T result = callDatabase(msg); // *3
                        batches.add(result);
                        return result;
                }
        }
};

Future<T> f = threadPool.submit(t); // *4
T result = f.get() // *5

1. Callable 分配 -- 可能导致 GC 压力。
2. 同步过程强制每个线程执行停-检查操作。
3. 消息的消费可能比生产慢。
4. 使用线程池(ThreadPool)将任务传递给目标线程 -- 通过 FutureTask 方式肯定会产生 GC 压力。
5. 阻塞直至 callDatabase() 回调。
在这个简单的例子中,很容易指出为什么扩容是很有限的:

• 分配对象可能产生GC压力,特别是当任务运行时间过长。
• 每次 GC 暂停都会影响全局性能。
• 默认,队列是无界的,任务会因为数据库调用而堆积。
• 积压虽然不会直接导致内存泄漏,但会带来严重副作用:GC 暂停时要扫描更多的对象;有丢失重要数据位的风险;等等 …
• 典型链式队列节点分配时会产生大量内存压力。
• 阻塞回调容易产生恶性循环。
• 阻塞回调会降低消息生产者的效率。在实践中,任务提交后需要等待结果返回,此时流式过程几乎演变为同步的了。
• 会话过程抛出的任何带数据存储的异常都会以不受控的方式被传递给生产者,否定了任何通常在线程边界附近可用的容错性。
要实现完全非阻塞是很难办到的,尤其是在有着类似微服务架构这样时髦绰号的分布式系统的世界里。因此 Reactor 做了部分妥协,尝试利用最优的可用模式,使开发者觉得他们是在写异步纳米服务,而不是什么数学论文。
没有什么传播得比光快(除了绯闻和网红猫的视频),正如到了某个阶段,延迟是每一个系统到都要面对的实实在在的问题。为此:

 Reactor 提供的框架可以帮助减轻应用中由延迟产生的副作用,只需要增加一点点开销:
     使用了一些聪明的结构,通过启动预分配策略解决运行时    分配问题    *;
     通过确定信息传递主结构的    边界    *,避免任务的无限堆叠;
     采用主流的    响应与事件驱动构架    模式,提供包含反馈在内的    非阻塞端对端流    *;
    * 引入新的     Reactive Streams(http://projectreactor.io/docs/ ... treams)    标准,拒绝超过当前容量请求,从而保证限制结构的有效性;
     在    IPC(http://projectreactor.io/docs/ ... erview)    上也使用了类似理念,提供对流控制友好的    非阻塞 IO 驱动    *;
     开放了帮助开发者们以    零副作用    *方式组织他们代码的函数接口,借助这些函数来处理容错性和线程安全。
关于该项目
该项目始于 2012 年。 经过长时间的内部孵化,于 2013 年发布 Reactor 1.x 版本。 Reactor 1 在各种架构下都能成功部署,包括开源的(如 Meltdown)和商业的(如 Pivotal RTI)。2014年,我们开始与一些新兴的响应式数据流规范(http://projectreactor.io/docs/ ... treams)合作,重新设计并于 2015年4月发布 Reactor 2.0版本。响应式数据流规范填补了指派机制的最后一个缺口:传输过程中,数据设置多大,才不会触发线程边界问题
同时,随着响应式扩展(http://projectreactor.io/docs/ ... l%23rx)日益普及,文档逐渐完善,我们也不断调整部分事件驱动和任务协作类 API。
Pivotal(http://pivotal.io/) 不仅是 Spring 框架发起者,许多员工都曾是各种 Spring 代码核心贡献者;Pivotal 也资助着 Reactor,两名 Reactor 核心开发人员在 Pitoval 工作。我们提供 Reactor 到 Spring 的整合支持,以及部分 Spring 框架重要功能的支持,如 spring-messaging 的 STOMP 中继代理。尽管如此,我们并不强求使用 Reactor 用户必须采用 Spring。我们为"Reactive 大众"保留可嵌入工具箱。实际上,Reactor 仅仅致力于解决异步和函数调用问题。
Reactor 遵循 Apache 2.0 许可(http://www.apache.org/licenses/LICENSE-2.0.html),可在 GitHub(https://github.com/reactor/reactor) 上获取。
使用前提

• 使用 Reactor,Java 版本最低需要 Java 7。
• 若要充分发挥函数组件潜力,需要 Java 8 Lambdas 支持。
• 采用 Spring,Clojure 和 Groovy 扩展作为后备。
• JVM 支持非安全访问时 Reactor 可满负荷运行 (比如不是Android的情况)。
• 若没有非安全访问策略,基于环形缓冲区的所有特性都不起作用。
• Reactor 在 Maven Central 中以传统 JAR 格式打包,你可以用你所习惯的构建工具在任何 JVM 工程中安装该依赖。