如前文所说，Amoeba、Cobar、MyCat等属于同宗一脉。若Amoeba能继续下去，Cobar就不会出来；若Cobar那批人不是都走光了的话，MyCAT也不会再另起炉灶。Cobar之后，有很多类似中间件仿照其架构以及思路，针对特定的业务场景，设计出了不同的中间件。MyCat算是其中业务场景比较全面，使用配置比较简便，性能优秀，而且功能算是稳定的。同类的中间件，都是针对特定场景或者功能进行设计，像某科技的hot某中间件，性能和功能更为稳定，但是业务场景有局限，扩展分布性不是很好。
所以，我们这里对MyCat进行较为全面的剖析，以供广大程序猿同志们的参考：）
首先，我们参考MyCat的社区文档。对比下Amoeba、Cobar、MyCat这三个中间件的架构
Amoeba在前端实现了MySQL协议栈，前端链接属于NIO实现，应用将SQL请求发往Amoeba，Amoeba经过请求解析请求路由将请求通过JDBC发到后端数据库集群。返回的结果经过合并与过滤返回到前端。
Cobar首先将后端JDBC换成了自己实现的原生MySQL通信层，并引入了池化的思想管理后端BIO连接池。实现自己的MySQL通信层，可以实现更多后端的功能，比如主备切换、读写分离、异步操作等。而且，实现了管理协议，可以进行动态配置
MyCat通过连接池管理前后端连接，并且前后端都有NIO与AIO的实现。功能与改造开发上更为丰富与灵活
MyCat实现了MySQL的协议栈，可以理解为，Mycat就是MySQL Server，而Mycat后面连接的MySQL Server，就好象是MySQL的存储引擎,如InnoDB，MyISAM等，因此，Mycat本身并不存储数据，数据是在后端的MySQL上存储的，因此数据可靠性以及事务等都是MySQL保证的，简单的说，Mycat就是MySQL最佳伴侣，它在一定程度上让MySQL拥有了能跟Oracle PK的能力：D
MyCat功能非常全面，从动态配置，集群配置，结果聚合，读写分离、到分表分库、容灾备份等。而且可以用于多租户应用开发、云平台基础设施、让你的架构具备很强的适应性和灵活性，借助于即将发布的Mycat智能优化模块，系统的数据访问瓶颈和热点一目了然，根据这些统计分析数据，你可以自动或手工调整后端存储，将不同的表映射到不同存储引擎上，而整个应用的代码一行也不用改变。MyCat的框架思路与源代码也有很多可圈可点的地方。
虽然MyCat功能很全面，但是某些功能受限于开源产品以及人的思路不同，MyCat的全面并不是那么“全面”。比如，它对于某些MySQL语句的支持并不是那么理想，后台数据库如果出现单点缓慢，性能会很受影响等的问题，还有弱XA分布式事务。我们在应用MyCat的时候，需要根据自己的业务，来改造MyCat。
改造MyCat不是一件很困难的事，对于MyCat源代码的研究与改造也是一件很锻炼团队的事，改造成功后相信MyCat能够撑住未来很长一段时间的数据库管理需求，这真是一石二鸟的事情。MyCat社区在中国的开源社区中也算是最活跃的几个之一，这也是件很难得的事情。
接下来我们将从MyCat的使用开始，一步一步深入到MyCat的源代码原理及设计思路，最后结合具体应用场景调优MyCat。敬请期待
本文出自 “张哈希的技术博客” 博客，请务必保留此出处http://zhxhash.blog.51cto.com/10645572/1743711
原文地址：http://zhxhash.blog.51cto.com/10645572/1743711
