MyCAT缺点

提起MyCAT，我的脑海里，总是浮现出这样一首偈。弘忍觉得自己老了，需要找一个接班人，于是，弘忍要求弟子们每人写一个偈子，根据偈子观察各位弟子的开悟程度，从而传授正宗禅宗的衣钵。弟子们心里其实都很明白，都知道师傅的衣钵传人一定是神秀，于是大家都没有写这个偈子。神秀也知道自己这个偈子的重要性，迟迟没有交出来，直到反复斟酌之后，才将上面这首偈写在墙上。其最后两句：时时勤拂拭，莫使惹尘埃，让我印象深刻。一个可以用的系统和一个优秀的系统的核心差距之一，就是是否尽量避免了需要经常维护的组件，避免让用户提心吊胆，恐染尘埃。
　　MyCAT本应是最好的中间件。它继承了阿里cobar的衣钵，在此基础上增加了众多重要功能。只是浏览下其核心特性，就知道他们是多么的努力，让人敬佩。

• 支持MySQL、Oracle、DB2、SQL Server、PostgreSQL等DB的常见SQL语法
  
• 遵守Mysql原生协议，跨语言，跨平台，跨数据库的通用中间件代理。
  
• 基于心跳的自动故障切换，支持读写分离，支持MySQL主从，以及galera cluster集群。
  
• 支持Galera for MySQL集群，Percona Cluster或者MariaDB cluster
  
• 基于Nio实现，有效管理线程，解决高并发问题。
  
• 支持数据的多片自动路由与聚合，支持sum,count,max等常用的聚合函数,支持跨库分页。
  
• 支持单库内部任意join，支持跨库2表join，甚至基于caltlet的多表join。
  
• 支持通过全局表，ER关系的分片策略，实现了高效的多表join查询。
  
• 支持多租户方案。
  
• 支持分布式事务（弱xa）。
  
• 支持XA分布式事务（1.6.5）。
  
• 支持全局序列号，解决分布式下的主键生成问题。
  
• 分片规则丰富，插件化开发，易于扩展。
  
• 强大的web，命令行监控。
  
• 支持前端作为MySQL通用代理，后端JDBC方式支持Oracle、DB2、SQL Server 、 mongodb 、巨杉。
  
• 支持密码加密
  
• 支持服务降级
  
• 支持IP白名单
  
• 支持SQL黑名单、sql注入攻击拦截
  
• 支持prepare预编译指令（1.6）
  
• 支持非堆内存(Direct Memory)聚合计算（1.6）
  
• 支持PostgreSQL的native协议（1.6）
  
• 支持mysql和oracle存储过程，out参数、多结果集返回（1.6）
  
• 支持zookeeper协调主从切换、zk序列、配置zk化（1.6）
  
• 支持库内分表（1.6）
  

　　这些功能的背后，是一帮开发人员在默默的奉献。翻开这些核心人员的简历，他们身上都有一个共同的深深的JAVA烙印。他们懂JAVA,然而他们对数据库的理解和经验总是差了几分。
　　举个简单例子，数据层高可用是中间件系统的核心功能之一。从数据库高可用来分，可以分为读高可用与写高可用。现在就主从复制场景下的写高可用，来一探MyCAT的功力。
 
　　MyCAT对底层数据库高可用的管理，依赖于第三方软件。当主库挂掉之后，通过MHA或者DRDB等方案，来将另外一台主机升级为主库，该主库使用原主库的VIP，对外提供服务。这种实现方式，一旦虚拟IP机制出现故障，比如误漂移，就会造成写入错误节点、双写或者无法写入等重大故障。甚至在某些环境中虚拟IP是不可能的，比如多个机器不在同一个网段。因此使用了MyCAT的方案后，你需要时时监控各个组件，免得系统出现故障。

　　如果对于数据库高可用有深入的理解，那么选写入节点的核心就在于究竟哪个节点是可以写入的。在几乎所有第三方高可用方案中，都会把从库或者不可使用的主库都设置为read only，在切换完成之后，都会把新的主库设置为read write状态。如果中间件去判断相应的设置，就可以匹配几乎所有的第三方高可用方案。如果使用这个方案，我们就可以避免某些不稳定的组件。正应了六祖慧能的那首偈
 　　
　　很小的一个例子，却可以看到MyCAT的JAVA开发者基因，也看到了对数据库理解不足的基因缺陷。正是对数据库理解的不足，导致了方案的复杂性和局限性。