[置顶] MyCat - 背景篇(2)

数据库路由中间件MyCat - 背景篇(2)

MyCat的前世今生

如前文所说,Amoeba、Cobar、MyCat等属于同宗一脉。若Amoeba能继续下去,Cobar就不会出来;若Cobar那批人不是都走光了的话,MyCAT也不会再另起炉灶。Cobar之后,有很多类似中间件仿照其架构以及思路,针对特定的业务场景,设计出了不同的中间件。MyCat算是其中业务场景比较全面,使用配置比较简便,性能优秀,而且功能算是稳定的。同类的中间件,都是针对特定场景或者功能进行设计,像某科技的hot某中间件,性能和功能更为稳定,但是业务场景有局限,扩展分布性不是很好。
所以,我们这里对MyCat进行较为全面的剖析,以供广大程序猿同志们的参考:)

MyCat架构对比

首先,我们参考MyCat的社区文档。对比下Amoeba、Cobar、MyCat这三个中间件的架构
[置顶] MyCat - 背景篇(2)_第1张图片
Amoeba在前端实现了MySQL协议栈,前端链接属于NIO实现,应用将SQL请求发往Amoeba,Amoeba经过请求解析请求路由将请求通过JDBC发到后端数据库集群。返回的结果经过合并与过滤返回到前端。
[置顶] MyCat - 背景篇(2)_第2张图片
Cobar首先将后端JDBC换成了自己实现的原生MySQL通信层,并引入了池化的思想管理后端BIO连接池。实现自己的MySQL通信层,可以实现更多后端的功能,比如主备切换、读写分离、异步操作等。而且,实现了管理协议,可以进行动态配置
[置顶] MyCat - 背景篇(2)_第3张图片
MyCat通过连接池管理前后端连接,并且前后端都有NIO与AIO的实现。功能与改造开发上更为丰富与灵活

总结-为什么选择MyCat

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。敬请期待

你可能感兴趣的:(数据库,中间件,Mycat,数据库路由中间件)