前面的集群成员维护服务为我们提供了集群内所有成员的地址端口等信息，可以通过MembershipService可以轻易从节点本地的成员列表获取集群所有的成员信息，有了这些成员信息后就可以使用可靠的TCP/IP协议进行通信了。这节讨论的正是实际中真正用于消息传送通道的相关机制及实现细节。
如下图，四个节点本地都拥有了一张集群成员的信息列表，这时节点1有这么一个需求：为了保证数据的安全可靠，在往自己的内存存放一份数据的同时还要同步到其他三个节点的内存中。节点1有一个专门负责发送的组件ChannelSender，首先从成员列表中获取其他三个节点的通信地址和端口，再分别向此三个节点建立TCP/IP通道发送数据，其他节点有一个负责接收数据的服务，将数据更新到内存中。
最理想的状态是发送给节点2、3、4都成功了，这样从整体看来ChannelSender像是提供了一个多通道的平行发送方式，所以也称为平行发送器。但现实中并不能保证同一批的消息往所有节点发送都成功，有可能发送到节点3时因为某种原因失败了，而节点2、4都成功了，这时通常要采取一些策略来应对，例如重新发送。Tribes所使用的策略是优先进行若干次尝试发送，若干次失败后将向上抛出异常信息，异常信息包含哪些节点发送失败及其原因，默认的尝试次数是1次。
为确保数据确实被节点接收到，需要在应用层引入一个协议保证传输的可靠性，即是通知机制，发送者发送消息给接收者，接受者接收到后返回一个ACK表示自己已经接收成功。Tribes中详细的协议报文定义如下：START_DATA（7bytes）+消息长度（4bytes）+消息长度（nbytes）+END_DATA（7bytes）。START_DATA为数据开始标识，为固定数组值70,76,84,50,48,48,50，END_DATA为数据结束标识，为固定数组值84,76,70,50,48,48,51，ACK_DATA表示通知报文，为固定数组值6,2,3。所以如果传输的是通知报文的话即为START_DATA+ACK_DATA的长度+ACK_DATA+END_DATA。所以整个集群的消息同步如下图，节点1通过ChannelSender发送消息给节点2、3、4，发送成功的判定标准就是节点2、3、4返回给节点1一个ack标识，节点1接收到了则认为发送成功。
为提高通信效率这里默认使用了NIO模式而非BIO模式（也可设置为BIO模式），使用NIO模式能统一管理所有通信的channel，避免了等待一个通道发送完毕另一个通道才能发送，如果逐个通信将导致阻塞IO时间很长通信效率低下。另外平行发送的过程需要一个锁保证消息的正确发送，例如有data1、data2、data3三个数据需要发送，应该是一个接一个数据包发送的而不能data1发一部分data2发一部分。
这节介绍了Tribes如何向集群其他成员发送数据，通过本地获取其他成员节点的地址和端口，再通过平行消息发送通道发送给其他节点，其中有ack机制和重发机制保证数据成功接收。
喜欢java的同学可以交个朋友：
