数据库分库分表的演进
背景
在互联网初创时期，企业往往采用单体架构去搭建自己的应用系统，但是，随着企业的不断壮大，系统访问量不断随之上升，数据量也急剧增长。数据的存储是首先要解决的问题，在这个大数据时代，数据就是企业的命根子，数据库的单体架构很难满足数据的存储，这时，我们要对数据进行切分，数据的切分又分为垂直切分和水平切分。
数据切分和数据库架构
在数据切分之前，我们的所有业务都放在一个数据库中，比如：我们的用户业务，商品业务，订单业务。数据库的架构如下：
在业务发展到一定规模时，一个数据库很难满足数据的存储，并且导致数据的访问比较慢，导致用户的流失。这时，我们要对数据进行切分，使其从单一的数据库的存储分散到多个数据库的存储。在进行数据切分时，我们要遵循先垂直后水平的原则。
数据的垂直切分也就是数据的纵向切分，按照业务将数据进行切分。在上面的例子中，我们将一个数据库切分为：用户库，商品库，订单库。将原来的一个数据库分为了三个数据库，分散了数据的存储压力，同时也分散了数据的读取压力。如图所示：
但是，随着业务的发展，单个业务库也会遇到存储的瓶颈，比如：用户的急剧增长，导致单一的用户库无法存储，用户访问的速度变慢等。这时，我们就要对数据进行水平切分了，将用户按照某种规则平均分配到多个数据库中，也就是将原来的单一的用户库进行了水平扩展。如图所示：
这里，我们只是水平的拆分了两个库，大家可以根据自己的系统情况，拆分成更多的数据库。
分库分表中间件MyCAT
数据库的整体架构我们规划好了，那么我们在进行开发的时候，怎么确定一条数据从哪个数据库读取呢？或者插入一条数据的时候，这条数据要插入到哪一个数据库呢？数据库的选择是交给开发人员负责呢？还是统一的设置一个代理层呢？开发人员在开发的时候，关注的焦点是业务，复杂的业务已经占据了他们大部分的精力，如果再让他们去考虑数据库的问题，对他们的压力是非常大的，而且每个开发人员的代码风格也不一样，导致项目混乱，臃肿，难以维护。所以，我们往往采用代理层统一处理数据的分片，这时，我们的MyCAT分库分表中间件就登场了，它去做统一的数据库层的代理。如图：
MyCAT统一做数据库层的代理，对外暴露一个地址，应用系统直接连接MyCAT，就像连接普通的MySQL一样，没有任何的区别。所有的CRUD操作都直接对应MyCAT，再由MyCAT做具体的数据分片，数据分片的过程对于开发人员来说是透明的，不需要额外的处理，这样，开发人员只需要关注业务就可以了。
MyCAT集群
可用性对于一个系统来说是非常重要的，尤其是在当今的互联网时代，系统宕机1分钟，带来的损失都是非常严重的，所以，我们在搭建系统时，往往采用集群方式，某一个节点的不可用，不影响整体系统的可用性。在前面的例子中，我们所有的节点都是单节点，存在着单点故障，这是我们不希望看到的，所以我们要搭建集群。6个业务数据库我们都可以做主从，这时，用户1库可以搭建为 用户1（主）和用户1（从），用户2库可以搭建为 用户2（主）和用户2（从）。订单库和商品库也可以做同样的操作，如图：
这样我们的业务数据库不存在单点故障了，但是MyCAT成为了单点，如果MyCAT发生故障，或者MyCAT承载了大量的数据库的请求，MyCAT成了整个系统的唯一瓶颈。那么MyCAT我们如何搭建集群呢？有的小伙伴可能会说了，我们再部署一个MyCAT，这个MyCAT和前一个MyCAT配置一样就可以了。是的，这只是其中的第一步，我们有了两个MyCAT连接数据库，那么我们的应用系统也需要连接两个MyCAT吗？两个MyCAT我们要如何分配请求呢？这是不是又增加了应用系统的复杂性呢？所以，我们在两个MyCAT上面再增加一个负载均衡器，它可以将请求按照某种规则分配到两个MyCAT上，这个负载均衡器我们采用HAProxy。整体架构如图：
这样MyCAT的单点故障解决了，但是HAProxy又成了单点，这是不是很有意思，似乎总有一个单点解决不了。在这里最后一个单点HAProxy，我们使用KeepAlived做故障转移就可以解决了，两个KeepAlived可以提供一个虚拟IP，业务系统直接连接这个虚拟IP，后面的过程对于应用系统是透明的。如图所示：
这就是我们最终的数据库架构，不存在任何的单点故障。
分布式事务与分布式ID
进行了分库分表后，随之而来的问题也就出现了，那就是ID的问题和分布式事务的问题，分布式ID和分布式事务在MyCAT中都有相应的解决方案，我们在MyCAT中进行配置就可以了。