在互联网初创时期,企业往往采用单体架构去搭建自己的应用系统,但是,随着企业的不断壮大,系统访问量不断随之上升,数据量也急剧增长。数据的存储是首先要解决的问题,在这个大数据时代,数据就是企业的命根子,数据库的单体架构很难满足数据的存储,这时,我们要对数据进行切分,数据的切分又分为垂直切分和水平切分。
在数据切分之前,我们的所有业务都放在一个数据库中,比如:我们的用户业务,商品业务,订单业务。数据库的架构如下:
在业务发展到一定规模时,一个数据库很难满足数据的存储,并且导致数据的访问比较慢,导致用户的流失。这时,我们要对数据进行切分,使其从单一的数据库的存储分散到多个数据库的存储。在进行数据切分时,我们要遵循先垂直后水平的原则。
数据的垂直切分也就是数据的纵向切分,按照业务将数据进行切分。在上面的例子中,我们将一个数据库切分为:用户库,商品库,订单库。将原来的一个数据库分为了三个数据库,分散了数据的存储压力,同时也分散了数据的读取压力。如图所示:
但是,随着业务的发展,单个业务库也会遇到存储的瓶颈,比如:用户的急剧增长,导致单一的用户库无法存储,用户访问的速度变慢等。这时,我们就要对数据进行水平切分了,将用户按照某种规则平均分配到多个数据库中,也就是将原来的单一的用户库进行了水平扩展。如图所示:
这里,我们只是水平的拆分了两个库,大家可以根据自己的系统情况,拆分成更多的数据库。
数据库的整体架构我们规划好了,那么我们在进行开发的时候,怎么确定一条数据从哪个数据库读取呢?或者插入一条数据的时候,这条数据要插入到哪一个数据库呢?数据库的选择是交给开发人员负责呢?还是统一的设置一个代理层呢?开发人员在开发的时候,关注的焦点是业务,复杂的业务已经占据了他们大部分的精力,如果再让他们去考虑数据库的问题,对他们的压力是非常大的,而且每个开发人员的代码风格也不一样,导致项目混乱,臃肿,难以维护。所以,我们往往采用代理层统一处理数据的分片,这时,我们的MyCAT分库分表中间件就登场了,它去做统一的数据库层的代理。如图:
MyCAT统一做数据库层的代理,对外暴露一个地址,应用系统直接连接MyCAT,就像连接普通的MySQL一样,没有任何的区别。所有的CRUD操作都直接对应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和分布式事务在MyCAT中都有相应的解决方案,我们在MyCAT中进行配置就可以了。