* Scalable network services
* Event-driven processing
* Reactor pattern
    Basic version 
    Multithreaded versions 
    Other variants
* Walkthrough of java.nio nonblocking IO APIs

• 伸缩式的网络服务
• 事件驱动处理
• Reactor反应器模式（基础版本、多线程版本、其他变种）
• 浏览java.nio 包内的非阻塞IO api

• web 服务，分布式对象，等
• 通用的基础结构
  • 读请求
  • 解码请求
  • 处理服务
  • 编码回复
  • 发送回复
• 不同点和开销在每一步中
  • XML解析，文件传输，web页面生成，计算服务

• 每一事件在自己所属的线程中处理

每个连接在配置的线程中运行

• 持续增长负载下优雅降级
• 资源消耗平缓递增
• 可用性以及性能指标
  • 低延迟
  • 高吞吐
  • 服务质量可调节
• 类似分治法的弹性架构目标

• 拆分处理为小的任务；每个任务无阻塞的完成
• 执行每个可执行的任务；经常采用触发器的形式
• 运行被javaNio支持
  • 无阻塞的读写
  • 分发，任务与被感知到的IO时间连接
• 多种扩展可能性
  • 面向事件驱动的体系

• 比其他选择的区分点
  • 更少的资源依赖：不用经常分配线程给客户端
  • 更少的开销：更少的上下问切换，更少的锁操作
  • 除了事件分发会更慢：在非常多的活动与事件绑定情况下
• 编程难点
  • 需要把处理过程必须分解为简单的无阻塞行为
    • 比GUI事件驱动粒度更小
    • 不能消除所有阻塞，GC/页缓存等
  • 必须维持服务的逻辑状态

• IO事件驱动经常使用相似的思路，除了一些设计区别

通过分发给适当的处理来响应IO事件；对比AWT线程

提供无阻塞操作；对比AWT中的动作监听器

对比：AWT中的#addActionListener()

java Nio的支持

支持无阻塞的读取连接文件，socket

像数组一样可以被直接读写Channels里

告诉那个Channels有IO事件

负责IO事件状态和绑定

通过attachment 绑定合适的处理器

• 有策略的增加线程为了弹性伸缩；主要适合多处理器
• 工作线程
  • Reactors应该快速触发处理器（处理器处理会比Reactor慢）
  • 拆解非IO处理过程到其他线程中
• 多Reactor Threads
  • Reactor线程可以充分用于IO处理
  • 多Reactor之间做负载（合理利用CPU和IO速率）

• 拆解非IO处理已提高Reactor线程的处理速度
• Reactor线程，比POSA2 Proactor 设计的更小
• 计算绑定处理比转换事件驱动的形式更简单【个人理解：这里表达的是如果使用Worker Threads，方便了handler的实现，如果都通过事件驱动，那么handler的实现必须依照Reactor中的要求。类似于我业务的实现要受网络连接上的处理规则限制】
  • 应该保持非阻塞计算（足够的处理消耗大于额外的开销消耗）
• 对于IO的持续处理比较困难，最好是一开始就读取到所有的输入到一个缓冲区内
• 使用线程池可以协调和控制，通常需要更小的线程服务更多设备

• 传递：每个任务，触发，执行下一个；速度快但是容易被破坏
• 回调：分发后的处理器回调，是GOF 调节模式的变种
• 队列：不同阶段访问buffer
• Future 异步通知：当每个任务产生结果，协同层顶部需要同步处理 join或者 wait/notify

• 一个可控的工作线程池
• 核心方法 execute(Runnable r)
• 可以控制：
  • 任务队列类型
  • 最大、最小线程数
  • 比守护线程更柔和
  • 保活时间直到idle线程挂掉
  • 更加丰富的策略

• 使用Reactor线程
  • 用于匹配CPU和IO速率
  • 讲台或者动态的构造器，拥有自己的选择器，线程，分发循环
  • 主接收器分配给其他Reactor

#基于另外一套Reactor模型的组件分类形式