Mycat开发实践---Mycat的网络通信框架

1从一个测试说起

网上有人对Cobar和MyCAT做了一个简单的比较测试，过程如下：
1 测试环境
利用A、B、C三大类服务器，在A台上面安装配置MyCAT及Cobar，这样保证了硬件方面的一致性。B类服务器上安装Apache这一web服务，使用PHP语言。C类安装MySQL数据库，其中B类与C类均不止一台，主要目的是为了作压力的均分。C类服务器安装了4台，存放了相同的数据库，对其中一个表进行分片存储。
测试软件使用的是loadRunner。在对两个中间件分别进行测试的过程中，采用的web服务器执行页面及相关数据库，均未调整，仅在中间件上有分别。比对情况如下图：

表格中场景状态下，明显MyCAT通过事务达到27544个，而Cobar只有2998，原因应该是Cobar假死之后对相关请求处理，均不再响应。
另外Cobar的内存直接上到300000KB以上，手动使用页面对测试实例连接单独访问访问不了，涉及到测试表的所有操作均不能再操作。Cobar内部使用show cobar_status;命令回馈正常。但是使用show cobar_cluster;命令，cobar反馈不了cobar的节点信息，而是返回empty set。
测试过程中MyCAT行为正常。
Cobar存在上述致命问题的原因是后端采用了BIO，每个请求在等待应答时都会占用一个线程，当前端并发量大时，就产生了假死的现象。
MyCAT对Cobar的网络框架进行了重构，后端BIO改为为AIO和NIO，同时还做了其它方面的优化，下面就慢慢道来~~~

2 MyCAT网络框架

2.1 三种IO类型
系统I/O 可分为阻塞型, 非阻塞同步型（NIO）以及非阻塞异步型（AIO）.
阻塞型I/O意味着控制权直到调用操作结束了才会回到调用者手里. 结果调用者被阻塞了, 这段时间了做不了任何其它事情. 更郁闷的是,在等待IO结果的时间里,调用者所在线程此时无法腾出手来去响应其它的请求，这真是太浪费资源了。拿read()操作来说吧, 调用此函数的代码会一直僵在此处直至它所读的socket缓存中有数据到来.
相比之下，非阻塞同步是会立即返回控制权给调用者的。调用者不需要等等，它从调用的函数获取两种结果：要么此次调用成功进行了;要么系统返回错误标识告诉调用者当前资源不可用，你再等等或者再试度看吧。比如read()操作, 如果当前socket无数据可读，则立即返回EWOULBLOCK/EAGAIN，告诉调用read()者“数据还没准备好，你稍后再试”。
在非阻塞异步调用中，稍有不同。调用函数在立即返回时，还告诉调用者，这次请求已经开始了。系统会使用另外的资源或者线程来完成这次调用操作，并在完成的时候知会调用者（比如通过回调函数）。拿Windows的ReadFile()或者POSIX的aio_read()来说,调用它之后，函数立即返回，操作系统在后台同时开始读操作。
在以上三种IO形式中，理论上，非阻塞异步是性能最高、伸缩性最好的。
同步和异步是相对于应用和内核的交互方式而言的，同步需要主动去询问，而异步的时候内核在IO事件发生的时候通知应用程序，而阻塞和非阻塞仅仅是系统在调用系统调用的时候函数的实现方式而已。
对于JAVA的API来说：
- java.net.Socket就是典型的阻塞型IO
- java NIO非阻塞同步
- java AIO非阻塞异步
MyCAT起源于Cobar，Cobar前端为NIO后端为BIOÿ