message server一般的处理方法：

1)       发布者发送消息到message server，当message server收到消息，首先保存消息，然后发送成功响应给发布者，这样正常情况下发布者会收到message的回执

2)       当网络异常时(网络中断，或者网络延迟)，在发布者发送消息到message server的过程中就有问题，此时message server跟这条消息没有任何的关系，发布者会收到发送失败的回执(message client发的，即发布者底层的message依赖的jar包中的网络层，message client和message server建立socket连接后才可能发送消息)，这个时候发布者的业务处理代码可以根据这个发送失败的回执进行相应的处理：继续发送消息或者忽略.

3)       当发布者发送消息给message server，message server保存消息时有问题的话，message server会发送一个失败的回执给发布者，发布者接收到回执后，处理方法同2)，其中又有问题，这个回执发送给发布者的时候，网络异常，这个时候在发布者这端的message client是有超时设置的，当超时一段时间没有接收到回执消息的时候，message client就认定此次发送是失败了，自己生产失败消息返回给业务代码，业务代码处理同2)。

4)       当发布者发送消息给message server，message server保存消息成功，message server发送成功回执给发布者，这个时候网络异常，没有发送成功，这个时候发布者这端的message client有超时设置，产生失败消息给业务代码，业务代码处理同2)。

5)      message   server投递给订阅者时，发送成功的话，订阅者业务处理成功后，发送回执给message server，message server收到成功回执会删除保存的消息的

6)       message server投递给订阅者时，发送不成功的话，message server有超时处理的，超时后会重新发送，重试的策略是时间间隔越来越长的，所以先到达message server的消息不一定在后到达的消息前面被投递成功。

7)       message server投递给订阅者时，发送成功了，但是订阅者业务处理失败发送失败回执或者订阅者发送成功回执时网络异常(比如超时)了，message server会认为发送失败，这样就会重新发送，策略同6)，

从上面的分析可知，message server的可靠性是要发布者和订阅者一同保证的。当出现上面的2) 3)

的情况时，发布者的业务代码要检查消息回执，然后在出错的情况下继续发送消息。在出现6) 7)的情况时，订阅者不能吃掉异常，不能提前返回。

因为要保证出现上面的几点问题时的可靠性，那么重复消息和发送的顺序就不能得到保证了。

分布式事务

高性能

NIO socket配合的是java.nio.buffer,byteBuffer分DirectByteBuffer和NO_DirectByteBuffer,

DirectByteBuffer就是操作系统的内存直接分配，而NO_DirectByteBuffer是jvm里面堆里面分配的，

所以DirectByteBuffer会比NO_DirectByteBuffer稍快，因为NO_DirectByteBuffer多了一次从os到jvm heap的拷贝。

上图中Acceptor是接受NIO socket中的连接事件，Reactor是NIO socket读写事件的loop，然后loop中根据各种事件分发到事件处理的业务代码，具体的可以看:

http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf

NIO socket本质上面是多路复用非阻塞IO，java里使用Selector类表示多路复用器，在此上面注册的SocketChannel都对应有一个SelectionKey，所以如果有多个连接的话Selector内部就有多个SelectionKey组成一个集合，程序需要遍历这个集合，检查有没有需要处理的key，这里需要处理的意思是至少一个连接注册了且其对应的连接通道已为 I/O 操作准备就绪。

所以这个遍历还是被阻塞的。