本人觉得这一章很重要，那就是 Spring默认的channel 的实现 DirectChannel，这个要大家多按照原文理解，开发者为何提供这样的一个channel，以及该channel适用的场景。

DirectChannel

TheDirectChannelhas point-to-point semantics（语义） but otherwise is more similar to thePublishSubscribeChannelthan any of the queue-based channel implementations described above. It implements theSubscribableChannelinterface instead of thePollableChannelinterface, so it dispatches（分发） Messages directly to a subscriber（订阅者）. As a point-to-point channel, however, it differs from thePublishSubscribeChannelin that it will only send each Message to a single subscribed（理解这句话，如果有多个订阅者 该Channel 仅仅选择其中一个订阅者发送，而忽略其他订阅者）MessageHandler.

(PS:DirectChannel 从字面理解是 基于 点对点 传输模式。事实上，他更像是一个 PublishSubscribeChannel 的实现，除了内部实现消息队列机制以外。 该类实现了 SubscribableChannel 接口 而不是 PollableChannel 接口。所以他会直接分发消息给订阅者。 同时作为 点对点 的传输队列，他有不同于传统意义的 PublishSubscribeChannel。他每次仅仅发消息发送给订阅者之一)

In addition to（除了） being the simplest point-to-point channel option, one of its most important features is that it enables a single thread to perform（扮演，充当） the operations on "both sides" of the channel. For example, if a handler is subscribed to aDirectChannel, then sending a Message to that channel will trigger invocation of that handler'shandleMessage(Message)method directly in the sender's thread, before the send() method invocation can return.（这里要是有个时序图就好了，第一次阅读这里是无法理解的，NND，坑爹的老外，伤不起的外语水平）

(PS:除了上述提到的点对点传输模式是 DirectChannel 的特性外，还有一个比较重要的特征就是，该通道允许单线程同时 充当 发送 与接受的角色，例如：一个订阅者 注册到 DirectChannel后，当一个消息发送到该 channel，则直接触发handleMessage(Message)方法在 send 方法执行完之前。)

The key motivation（动机） for providing a channel implementation with this behavior（行为） is to support transactions（事务） that must span across the channel while still benefiting（受益） from the abstraction and loose coupling that the channel provides. If the send call is invoked within the scope of a transaction, then the outcome of the handler's invocation (e.g. updating a database record) will play a role in determining the ultimate result of that transaction (commit or rollback).

(PS:这样做的动机是 为了 让通道两端的操作能包含在一个事务中。大概意思是这样子的，其余的读者自己理解)

TheDirectChannelinternally delegates to a Message Dispatcher to invoke its subscribed Message Handlers, and that dispatcher can have a load-balancing（负载均衡） strategy. The load-balancer determines how invocations（调用） will be ordered in the case that there are multiple handlers subscribed to the same channel. When using the namespace support described below, the default strategy is "round-robin"(轮询) which essentially（本质上，基本的） load-balances across the handlers in rotation（轮流）.

（PS：DirectChannel 可以充当消息分发的角色定位，并且该分发是基于负载均衡策略。负载均衡实现了对订阅该通道 的消息订阅者按照顺序循环调用。其内部实现的默认策略是 循环 机制。这个是负载均衡的最基本的一种实现。 ）

The load-balancer also works in combination with（与.....组 合） a boolean failover（故障转 移） property. If the "failover" value is true (the default), then the dispatcher will fall back to（回滚到） any subsequent（随后的） handlers as necessary when preceding（前面的） handlers throw Exceptions. The order is determined by an optional order value defined on the handlers themselves or, if no such value exists, the order in which the handlers are subscribed（订阅）.

(PS:负载均衡 常与 故障转移 配合使用，对于DirectChannel的 failover 值，默认是 开启的。当前一个订阅者调用发生异常 分发器会回滚当前状态到下一个订阅者重新处理，其调用的顺序是由handlers自身的 order 属性决定。如果不存在这样的值 则有订阅者默认的顺序决定。 )

If a certain（某些） situation requires that the dispatcher always try to invoke the first handler, then fallback in the same fixed order sequence every time an error occurs, no load-balancing strategy should be provided. In other words, the dispatcher still supports the failover boolean property even when no load-balancing is enabled. Without load-balancing, however, the invocation of handlers will always begin with the first according to their order. For example, this approach works well when there is a clear definition of primary, secondary, tertiary, and so on. When using the namespace support, the "order" attribute on any endpoint will determine that order.

(PS:假如在某一场景下需要分发器总是尝试调用第一个 handler，发生异常 回滚也是采用固定的序列，不需要负 载均衡的策略支持。换句话说：分发器支持在关闭负载均衡的模式下仍旧对 failover 有效。因此，调用handlers顺序总是 按照第一次排序的顺序进行。例如 当清晰的定义了 第一 、第二 、第三 等顺序，那么这种工作机制将会很好的运行)

ExecutorChannel

TheExecutorChannelis a point-to-point channel that supports the same dispatcher configuration asDirectChannel(load-balancing strategy and the failover boolean property). The key difference between these two dispatching channel types is that theExecutorChanneldelegates to an instance ofTaskExecutorto perform the dispatch. This means that the send method typically will not block, but it also means that the handler invocation may not occur in the sender's thread. It therefore does not support transactions spanning the sender and receiving handler.

(PS:ExecutorChannel 是 点对点 通道的实现，同时他支持 DirectChannel 的分发器特性，（负载均衡与故障转移）。 两者之间一个显著的不同之处是 ExecutorChannel 内部是通用一个 TaskExecutor 实例实现的。这意味着调用该 通道的 send 方法不会发生阻塞，同时这将意味着 对handler的调用将不会与sender 公用统一线程， 该模式不支持事务，发送与接受分别受限与不同的线程 )

<int:channel id="threadScopedChannel" scope="thread"><int:queue /></int:channel><bean class="org.springframework.beans.factory.config.CustomScopeConfigurer"><property name="scopes"><map><entry key="thread" value="org.springframework.context.support.SimpleThreadScope" /></map></property></bean>

The channel above also delegates to a queue internally, but the channel is bound to（绑定） the current thread, so the contents of the queue are as well. That way the thread that sends to the channel will later be able to receive those same Messages, but no other thread would be able to access them. While thread-scoped channels are rarely（很少，极少） needed, they can be useful in situations（场景） whereDirectChannelsare being used to enforce（执行） a single thread of operation but any reply Messages should be sent to a "terminal" channel. If that terminal channel is thread-scoped, the original sending thread can collect its replies from it.

(PS : 上述的channel 同时作用于其内部的队列。由于channel 绑定了当前的工作线程，所以其内部队列同样被作用。 这样线程不经可以发送，还可以接受这些消息。当时其他线程是无法访问该channel的。事实上，基于thread-scoped 的channle 很少被用到。一个比较有用的场景是 当通过 DirectChannels 在单线程下执行一个消息发送后任何响应的消息 可以发送到这个终端的 channel 中。如果这个channel 是基于 thread-scoped，那么原先的发送线程可以通过他获取任何响应的消息)