MINA及其在高性能通讯应用中的突出问题（NIO架构及应用之二）
前面写过一个博文高：高吞吐高并发Java NIO服务的架构，http://maoyidao.iteye.com/admin/blogs/1149015。这个架构是和MINA一致的，或者可以说MINA是基于同样的思路构架的。想阅读MINA源代码的朋友可用参考这个架构来研究MINAsource code。但是考虑到在已经有比较可靠的开源实现的情况下，现在朋友们很少会自己去实现一个NIO模块。就想到把它做成一个系列，第一篇主要是讲解一种业内普遍采用的NIO架构，及其架构上的两个要点，即：1. 基于提高的性能的线程池设计；2. 基于网络通讯量的通讯完整性校验。这一篇来讲讲在基于MINA搭建高性能NIO服务时如何具体实施以上两点。有部分代码选自openfire（openfire是一个实现XMPP协议的开源项目，其底层通讯模块为MINA）
MINA的使用相信朋友们已经很熟悉了。把MINA应用于高性能分布式应用的时候，表现出来比较突出的问题还是协议解析的问题和容量规划的问题。
1，协议解析的正确性问题
MINA已经给我们提供了非常方便的接口来实现NIO。coding的重点可能会是在协议解析上，即实现ProtocolCodecFactory接口中规定的encoder、decoder。当收到一个NIO包并从中解析出协议消息体并不困难，且容易测试。但高负荷的通信使得协议数据不能在TCP的一个packet中完全到达，即所谓断包。我经历过某团队到性能测试时才发现这一问题，花了很多时间在海量的tcpdump包中寻找问题，花费了很多时间，而且非常痛苦。如能从一开始了解TCP通讯和MINA架构，则轻松很多。
TCP socket发送大数据时会将其拆分成一个个小数据包发出，由于接收窗口和拥塞窗口的限制，这些数据包可能不能一次发送出去。这时后继的数据包等待在发送缓冲区，等待窗口的扩大。比如在Linux系统，通过修改/proc/sys/net/core/rmem_max改变最大的TCP数据接收缓冲，通过修改/proc/sys/net/core/wmem_max改变最大的TCP数据发送缓冲。另外，即使是比较小的数据包，为了达到最好的性能，我们总是尽可能多的把小数据包拼接起来填充每个报文，以减少发送数据包的个数。比如MINA默认的参数会把John Nagle算法设为false。如下代码，socketSessionConfig.isTcpNoDelay()返回false。
这里需要调用远程资源，可以认为是memcached，也可以是其他socket资源。最后还要通过socket发送到其他模块。这时则要求即使这些资源访问全部挂掉，也不能让线程等待很久，否则前端的queue就会堆积溢出。因此resource的调用必须有很快的超时返回，而socket则必须有心跳和很快的超时返回。在这个项目中，经过容量规划我们认为后端socket的超时应该为3秒。这个时间相对是比较短的，但是为了保证整个系统的健康，是必须的。?
在发送端设置发送缓冲的意义我想引用Timyang的一篇博客中所说的，
?
1.Socket占满后写socket会block, 或者设置了TCP_NODELAY则不管SOCKET buffer是否占满都会block
2. 如果应用写入操作没有队列概念则应用程序会出现异常，所有操作会阻塞。
3. 强壮的应用会对发送数据做应用层的buffer，像Connection Manager/Openfire之间是使用发送 Thread Pool，在对方不可到达的时段内，内存占用会急剧上升。
4. 如果网络层恢复正常，首先是socket buffer中的数据会被发送，然后应用层堆积的数据也随后发送。
5. 如果网络层长时间不可用，有2种方法可以判断，通过达到SO_SNDTIMEO Socket返回错误检测，应用层如果需要更早知道错误，可以调低SO_SNDTIMEO。另外一种检测方法是应用检测发送队列达到上限临界值来做进一步 处理。避免服务器内存溢出造成崩溃。实际环境中需要结合这2种方式一起考虑。?
对于第五点，我提供的经验是，对LinkedBlockingQueue size做一个定时健康监控。如果前端queue内容发生堆积，说明系统中有锁定的情况；如果后端queue堆积，说明网络状况不好。
?
总结一下，设计和开发广泛适用于分布式的通讯模块，需处理
1，收不到，
2，收到处理不了，
3，和发不出去
这三种情况下的健壮性。
?
