需求

• 数百万条并发连接的可伸缩性
• 从输入通道获取数据到目标actor的邮箱，这个过程中的最低延迟
• 最大的吞吐量
• 可选的双向 back-pressure（例如，限制本地发送者，并允许本地读者在协议允许的情况下限制远程发送者。）
• 一个纯粹的基于actor的API，具有不可变的数据表示
• 通过一个非常精简的SPI来整合新传输的可扩展性。

基本架构

每一个传输的实现将会作为单独的Akka扩展，提供一个ActorRef代表客户端的初始接触点，这个“manager”接收建立通信通道的请求（连接或监听Tcp socket），每个通信通道由一个专用的actor表示，该actor在其整个生命周期内与此通道的所有交互都公开给客户端。
实现的中心元素是 特殊的传输“选择器”actor.（Tcp情况下，包装java.nio.channels.Selector）。通道actor通过发送消息给指定的选择器actor来注册自己的可读性和可写性。然而，实际的通道读取和写入是由通道actor自己执行的，这使得选择器actor从耗时的任务中解放出来，从而确保低延迟。选择器actor唯一的职责就是管理底层selector的key集合与select操作。
通道对选择器的分配由manager执行，并且在一个通道的整个生命周期中保持不变。基于特定于实现的分布逻辑，manager actor的新通道跨越一个或多个selector。这种逻辑可以委托给selector actor，例如，当他们认为自己有能力时，可以选择拒绝新通道的分配。
一个传输实现有三层actor层次结构：manager actor 创建 selector actor 因此也负责监管它。从而也监督它们的 channel actor。
通过启用输出的 Back-pressure，从而允许用户在其写消息中指定是否希望接收到写入O/S内核的队列的确认。启用输入的Back-pressure，