蘑菇街交易平台 数据库架构演进历程
从数据库最终用户角度看，数据库系统的结构分为单用户结构、主从式结构、分布式结构、客户/服务器、浏览器/应用服务器/数据库服务器多层结构。这是数据库外部体系结构。物理存储结构、逻辑存储结构、内存结构和实例进程结构。这是内部体系结构。
单数据库架构：一个项目在初期的时候，为了尽可能快地验证市场，其对业务系统的最大要求是快速实现。在这个阶段，代码开发人员为了能快速实现业务系统，一般都是将所有层级（MVC）的业务代码都写在同一个项目中，所有的业务数据都存放在同一个数据库中。但随着项目的不断推进，用户量不断增长，单台应用服务器已经无法承受如此巨大的流量了。此时常见的做法是把项目进行分布式部署，分散单台服务器的流量，从而可以暂时缓解用户增长带来的应用服务器压力。
主从数据库架构：这个时候常用的解决方案就是将原本单台数据库服务器变成主从模式的数据库服务器，即一台数据库作为主库支持写入数据，一台数据库作为读库支持查询数据。
我们通过数据库主从同步实现了读写分离，将所有读操作都引导到从库进行，将所有写操作都引导到主库进行。因为我们对数据库层进行了改造，规定所有读数据库操作要访问从库，所有写数据库操作要访问主库，那么我们就必须对原来的代码进行改造。当我们使用了主从数据库架构之后，我们会发现我们能支撑更多的用户访问和请求了。但随着业务的进一步发展，其实可以发现会存在一些问题：当我们修改了注册模块的时候，我们需要整个项目都发布一次，这样会影响到登录、购物模块的正常使用。即使每次改动的代码即使很小，我们还是需要发布整个项目包，这使得每次发布的代码包非常巨大。随着业务量的不断增长，我们会发现即使实现了主从的读写分离，数据库的压力也是非常大，似乎快要承受不了了。上面说的这些问题只是实战中遇到的一部分问题，事实上遇到的问题只会更多不会更少，而且随着业务的不断发展会愈加凸显。
垂直切分数据库架构
此时为了各个业务模块不互相影响，我们把应用层进行垂直拆分，即把注册模块、登陆模块、购物模块都单独作为一个应用系统，分别读写独立的数据库服务器。实现了垂直拆分之后，我们可以成功解决上面说到的三个问题：业务模块相互影响问题、单数据库压力问题。但是随着业务的进一步扩大，我们又增加了许多业务模块：客服模块、钱包模块、个人中心模块、收藏夹模块、订单模块等。按照我们之前所设计的数据库架构，我们会存在许多个数据源，这些数据源分散在各个项目中。
总结：从单一的数据库架构，到主从读写分离的数据库架构，再到垂直拆分、水平拆分的数据库架构。我们可以看到 MyCat 帮我们解决了读写数据源判断、繁杂数据源地址、分表判断这三个机械的重复性的问题。但 MyCat 发展至今，其功能已经远远超过上面说的这三个。例如 MyCat 支持主从切换功能，当数据库主库发生网络问题或其他故障时，MyCat 可以自动切换到从库，从而保证正常读写功能的进行。MyCat 的定位是一个数据库中间件，但凡所有处于应用层和数据层之间的事情，MyCat 都可以做。
文章来源：https://www.cnblogs.com/adeng/p/9012301.html