单数据库架构
一个项目在初期的时候，为了尽量快地验证市场，其对业务系统的最大要求是快速实现。在这个阶段，代码开发人员为了能快速实现业务系统，通常都是将全部层级（MVC）的业务代码都写在同一个项目中，全部的业务数据都存放在同一个数据库中。此时，项目的总体架构图以下所示：前端
从上图能够看到，咱们在一个项目中集中了注册、登录、购物三个模块的业务代码，而且这三个业务模块都读取同一个业务数据库。程序员
但随着项目的不断推动，用户量不断增加，单台应用服务器已经没法承受如此巨大的流量了。此时常见的作法是把项目进行分布式部署，分散单台服务器的流量，从而能够暂时缓解用户增加带来的应用服务器压力。此时的项目架构图以下所示：数据库
但随着咱们部署的应用服务器愈来愈多，后端的单台数据库服务器已经没法承受如此巨大的流量了。为了尽快缓解用户访问压力，咱们通常是在应用服务器与数据库服务器中间加多一个缓存层，经过缓存能够抵消掉一部分的数据库查询操做。此时的项目架构图以下所示：后端
可是增长数据库缓存层只能缓解数据库访问压力，拦截部分数据库访问请求。随着用户访问量的进一步增加，数据库访问的瓶颈仍是会进一步凸显。这个时候，咱们不得不对数据层的架构进行改造。缓存
主从数据库架构
这个时候经常使用的解决方案就是将本来单台数据库服务器变成主从模式的数据库服务器，即一台数据库做为主库支持写入数据，一台数据库做为读库支持查询数据。此时项目的架构图以下所示：服务器
咱们经过数据库主从同步实现了读写分离，将全部读操做都引导到从库进行，将全部写操做都引导到主库进行。markdown
由于咱们对数据库层进行了改造，规定全部读数据库操做要访问从库，全部写数据库操做要访问主库，那么咱们就必须对原来的代码进行改造。网络
上面是改造前的代码，不管是读操做仍是写操做，咱们都使用同一个数据源进行操做。但为了适应新的数据库架构，咱们必须在代码中手动判断应该请求哪一个数据源。架构
通过修改后的代码，开发根据自身经验判断应该选择哪一个数据源进行操做。当是读操做的时候，咱们选择 readTemplate。当是写操做的时候，咱们选择 writeTemplate。less
但做为一个程序员，咱们隐隐约约以为识别应该用哪一个数据源这个判断不该该人工判断，而应该自动让代码去判断。毕竟这个判断的模式很简单 —— 若是是 select 那么就用读的数据源，若是是其余那么就用写的数据源。
其实这个就是 MyCat 的用途之一，即做为一个数据库中间件去解决数据源判断问题。若是咱们使用 MyCat 做为数据库中间件，那么咱们不须要关心我应该使用哪一个数据源。MyCat 帮咱们屏蔽了不一样数据源的差别，对于咱们来讲就只有一个数据源，这个数据源能处理写操做，也能处理读操做。上面查询和插入的代码就能够变成下面这样：
实现了主从数据库架构，再使用 MyCat，你发现咱们并不须要去修改太多的代码，只须要将数据源改成 MyCat 地址便可。MyCat 自动把咱们全部的语句发送给后端的 MySQL 服务器。
当咱们使用了主从数据库架构以后，咱们会发现咱们能支撑更多的用户访问和请求了。但随着业务的进一步发展，其实能够发现会存在一些问题：
- 当咱们修改了注册模块的时候，咱们须要整个项目都发布一次，这样会影响到登陆、购物模块的正常使用。
- 即便每次改动的代码即便很小，咱们仍是须要发布整个项目包，这使得每次发布的代码包很是巨大。
- 随着业务量的不断增加，咱们会发现即便实现了主从的读写分离，数据库的压力也是很是大，彷佛快要承受不了了。
上面说的这些问题只是实战中遇到的一部分问题，事实上遇到的问题只会更多不会更少，并且随着业务的不断发展会越发凸显。
垂直切分数据库架构
此时为了各个业务模块不互相影响，咱们把应用层进行垂直拆分，即把注册模块、登录模块、购物模块都单独做为一个应用系统，分别读写独立的数据库服务器。此时，咱们的系统架构图以下图所示：
实现了垂直拆分以后，咱们能够成功解决上面说到的三个问题：业务模块相互影响问题、单数据库压力问题。
可是随着业务的进一步扩大，咱们又增长了许多业务模块：客服模块、钱包模块、我的中心模块、收藏夹模块、订单模块等。按照咱们以前所设计的数据库架构，咱们会存在许多个数据源，这些数据源分散在各个项目中：
- 用户数据库 192.168.0.1
- 商品数据库 192.168.0.2
- 短信数据库 192.168.0.3
- 客服数据库 192.168.0.4
- 钱包数据库 192.168.0.5
- ……
对于一个项目管理者来讲，这么多的数据源分散在不一样项目中，怎么统一管理是一个问题。不少时候咱们都很难记住这个项目链接的是哪一个数据库，那个项目链接的是哪一个数据库。
但若是你使用了 MyCat 做为数据库中间件的话，MyCat 就能够帮你解决这个问题。对于全部项目来讲，它们只须要统一链接 MyCat 对外提供的一个地址，而 MyCat 则帮这些项目联系全部后端的 MySQL 数据库。对于前端的项目俩说，它们只知道 MyCat 这个数据库中间件，而不须要去理会我到底链接哪一个数据库，MyCat 经过自身配置能够完成这个任务。
水平切分数据库架构
当数据库架构经历了主从架构、垂直拆分架构以后，应对通常的业务读写是没有什么问题了。但对于一些核心的业务数据，可能仍是会有瓶颈问题，例如用户模块。
对于一些用户量高达一个亿的用户系统来讲，即便通过主从架构、垂直拆分架构的优化，但其用户数据库的单个表里须要存储的数据仍是高达一个亿的大小。若是咱们把全部的数据都存放在一个表里，不管是注册时的插入数据，或者是登录时的查询数据，势必会变得很慢。
这时候，咱们就不得不对这些高数据量的核心业务表进行水平拆分，即将海量的数据记录拆分到多张表中保存。例如咱们一开始可能只有一张 User 表，咱们将 User 表按照用户 ID 对 1000 取余进行拆分，那么咱们就会有 1000 张表，分别是 User_000 至 User_999。此时，项目的架构图以下所示：
当咱们在代码中查询用户数据时，咱们先根据用户 ID 取余判断其应该操做的表，以后再查询对应的表。例如 UserId 为 90749738 的用户就应该查询 User_38 表，UserId 为 74847383 的用户就应该查询 User_83 表。
经过水平拆分，咱们成功解决了海量数据核心业务表的读写瓶颈问题。但此时在代码层面上有一个问题出现了，那就是咱们须要在查询数据库以前，根据 UserId 去判断应该查询哪一个表，这个操做对于全部业务模块来讲都是高度一致的，应该抽离成一个公用的项目。
与判断应该使用读数据源仍是写数据源一致，咱们都以为这样机械的任务不该该丢给程序员作，应该让机器去作。这其实就是 MyCat 能够帮咱们作的事情：MyCat 经过配置一系列的分库分表规则，让 MyCat 帮咱们自动判断应该查询哪个分表。经过使用 MyCat 数据库中间件，咱们能够省去在代码层判断查询哪一个表的冗余代码，从而让开发人员更专一于业务逻辑的开发。
总结
从单一的数据库架构，到主从读写分离的数据库架构，再到垂直拆分、水平拆分的数据库架构。咱们能够看到 MyCat 帮咱们解决了读写数据源判断、繁杂数据源地址、分表判断这三个机械的重复性的问题。
上面说到的三个功能就是 MyCat 诞生初期的最基本功能。但 MyCat 发展至今，其功能已经远远超过上面说的这三个。例如 MyCat 支持主从切换功能，当数据库主库发生网络问题或其余故障时，MyCat 能够自动切换到从库，从而保证正常读写功能的进行。
总的来讲，MyCat 的定位是一个数据库中间件。但凡全部处于应用层和数据层之间的事情，MyCat 均可以作。