数据库中间件 -- 不背锅

最近一个群里面有人问问题，关于MYSQL中间件怎么选型的问题，以及怎么读写问题的问题。我当时嘴比较欠，就说了几句。后面想想当时说的有不少有漏洞，所以写一篇文章，为中间件，或者说数据库的中间件来 平反。

在使用到数据库中间件的时候，大多主要的诉求

1 分库分表，尤其分库

2 读写分离

3 通过中间件来将数据进行某个特殊的导向

数据库中间件本身出现的时间比较长了，但是一个好的数据库中间件却不是太多，如果你说MYCAT 是一个好的中间件，我就笑了，他是不是好的中间件我不知道，但我知道在现在的情况下，我宁可去用TIDB ,OB 等分布式数据库，我也不会使用MYCAT 这样的开源产品。除去一些非技术因素，之前使用MYCAT 是因为当时此类的产品，就只有他，并且MYSQL 兴盛但是所以MYCAT 火热了一阵，但细心的人都知道，你要不要上这个贼船。

1 MYCAT 本身是否需要高可用

2 MYCAT 在分库的情况下如果一个节点失效了，则MYCAT 怎么来处理这个问题，是否有能力控制数据库或者说控制MYSQL，或有节点失败后的补偿机制。

3 新加或去除一个MYSQL 几点时使用MYCAT 是否方便。

在你问了这些问题后，如果你还选择MYCAT ，那么我只能给你 两个字 呵呵。

一个数据库中间件的产品首先要考虑

1 数据库中间件是否与你的业务契合

比如中间件本身不支持高可用，而你使用了这个中间件你是否要考虑对你整体的系统的 SLA 进行一个低评，因为你存在了问题点。如果你的业务仅仅是一个离线的日志系统，你大可以用这个数据库中间件，但如果你的业务是一个核心的关系你公司死活的业务，此时你还要用MYCAT 这样的中间件吗？ 你需要分辨你的业务是否能承受某些由于中间件导致的不稳定和无法进行恢复的情况，而不是别人都用，你就用，别人在无污染的天山喝了一口泉水，你难道也要在你家门口的臭水沟来一口，你所在的环境是一个重点，而不光是技术本身。

2 中间件不是万能的，他是需要配合的

这点是需要明确的，比如读写分离，读写分离中的事务是如何撰写的，如果一个事务里面封装了 DML 和 DQL ，那么作为一个中间件他是如何聪明到，分辨你的这个事务里面的操作的关联性的，如果他能够分辨你的数据应该去主库还是去从库而不会要从库没有数据的情况，或者本身业务就需要在主库进行读取避免延迟带来的问题，这些都是需要你考虑的，因为中间件不是 “神药”，他是需要你的开发进行配合，并根据业务的逻辑进行合理的拆分后才能进行的有效使用。所以考虑问题，要考虑上下文，一个中间件不是你唯一的英雄，你现在需要的是大配合，团队作战。

3 中间件是要看基础出身的，不看底层的出身，中间件只能是花拳绣腿

中间件是基于数据库上层的部分产生的一个具有路由或简单逻辑数据定式化读取的产品，他可以有更多的功能，但是他无法改变的是数据库，也就是如果中间件是一次语文背诵考试，那么数据库就是你每天背诵文章的熟悉的程度或基础。中间件做的再好，你的数据库不给力那留下的就是无奈。一个MYSQL的事务导致数据同步延迟2分钟，但是你的业务强制读写分离了，那么此时你的数据无法从从库读取，那么业务可能失败，甚至业务可能给出错误的数据导致业务逻辑错乱，造成经济损失，所以为什么说有些数据库中间件只是一个花拳绣腿，不是因为她不好，是因为她所在的基础，数据库本身 他不好，或先天不足。

所以你细心留意，在云端的RDS 产品都没有太好的中间件支持，而云原生的数据库产品尤其shard storage 的产品都有比较好的中间件支持，并且在大部分情况都比较有效的可以支持你自动化的读写分离，不需要你在费心担心复制延迟的问题。

说到最后，数据库中间件好不好，和你的开发人员对于业务理解以及事务的读写拆分，以及你底层的数据库是否有好的基因是一个强相关的关系，任何对于中间件有着强需求的情况，需要你能分辨出来你到底需要不需要中间件，中间件是否会导致你系统的稳定性降低，SLA 降低。