一步步带你了解分布式数据库的架构演变之路！
MyCat 是一个数据库分库分表中间件，使用 MyCat 可以非常方便地实现数据库的分库分表查询，并且减少项目中的业务代码。今天我们将通过MyCat的功能来介绍数据库架构发展的演变。
单数据库架构
一个项目在初期的时候，为了尽可能快地验证市场，其对业务系统的最大要求是快速实现。在这个阶段，代码开发人员为了能快速实现业务系统，一般都是将所有层级（MVC）的业务代码都写在同一个项目中，所有的业务数据都存放在同一个数据库中。
从上图可以看到，我们在一个项目中集中了注册、登陆、购物三个模块的业务代码，并且这三个业务模块都读取同一个业务数据库。
但随着项目的不断推进，用户量不断增长，单台应用服务器已经无法承受如此巨大的流量了。此时常见的做法是把项目进行分布式部署，分散单台服务器的流量，从而可以暂时缓解用户增长带来的应用服务器压力。
但随着我们部署的应用服务器越来越多，后端的单台数据库服务器已经无法承受如此巨大的流量了。为了尽快缓解用户访问压力，我们一般是在应用服务器与数据库服务器中间加多一个缓存层，通过缓存可以抵消掉一部分的数据库查询操作。
但是增加数据库缓存层只能缓解数据库访问压力，拦截部分数据库访问请求。随着用户访问量的进一步增长，数据库访问的瓶颈还是会进一步凸显。这个时候，我们不得不对数据层的架构进行改造。
主从数据库架构
这个时候常用的解决方案就是将原本单台数据库服务器变成主从模式的数据库服务器，即一台数据库作为主库支持写入数据，一台数据库作为读库支持查询数据。
我们通过数据库主从同步实现了读写分离，将所有读操作都引导到从库进行，将所有写操作都引导到主库进行。因为我们对数据库层进行了改造，规定所有读数据库操作要访问从库，所有写数据库操作要访问主库，那么我们就必须对原来的代码进行改造。
其实这个就是 MyCat 的用途之一，即作为一个数据库中间件去解决数据源判断问题。如果我们使用 MyCat 作为数据库中间件，那么我们不需要关心我应该使用哪个数据源。MyCat 帮我们屏蔽了不同数据源的差异，对于我们来说就只有一个数据源，这个数据源能处理写操作，也能处理读操作。
垂直切分数据库架构
此时为了各个业务模块不互相影响，我们把应用层进行垂直拆分，即把注册模块、登陆模块、购物模块都单独作为一个应用系统，分别读写独立的数据库服务器。
实现了垂直拆分之后，我们可以成功解决上面说到的三个问题：业务模块相互影响问题、单数据库压力问题。
随着业务的进一步扩大，我们又增加了许多业务模块：客服模块、钱包模块、个人中心模块、收藏夹模块、订单模块等。按照我们之前所设计的数据库架构，我们会存在许多个数据源，这些数据源分散在各个项目中。
使用MyCat 作为数据库中间件的话，MyCat 就可以帮你解决这个问题。对于所有项目来说，它们只需要统一连接 MyCat 对外提供的一个地址，而 MyCat 则帮这些项目联系所有后端的 MySQL 数据库。对于前端的项目俩说，它们只知道 MyCat 这个数据库中间件，而不需要去理会我到底连接哪个数据库，MyCat 通过自身配置可以完成这个任务。
水平切分数据库架构
当数据库架构经历了主从架构、垂直拆分架构之后，应对一般的业务读写是没有什么问题了。但对于一些核心的业务数据，可能还是会有瓶颈问题，例如用户模块。
我们就不得不对这些高数据量的核心业务表进行水平拆分，即将海量的数据记录拆分到多张表中保存。
MyCat 通过配置一系列的分库分表规则，让 MyCat 帮我们自动判断应该查询哪一个分表。通过使用 MyCat 数据库中间件，我们可以省去在代码层判断查询哪个表的冗余代码，从而让开发人员更专注于业务逻辑的开发。
总结
结合MyCat 中间件实现的功能，我们了解到数据库优化过程，从单一的数据库架构，到主从读写分离的数据库架构，再到垂直拆分、水平拆分的数据库架构。这些是一个基本的思路，具体项目怎么做需要小伙伴具体问题具体分析。