关系型数据库的架构演变

单机mysql

在低数据量的访问时，我们使用单个的MySQL就可以满足我们的数据访问要求。

比如个人博客系统，后台管理系统等，我们同时在线使用的人数不多并且并发访问数量极低。

而且我们存储的数据量少，一个简单的MySQL服务已经足够满足我们的需求。

缓存+业务垂直分离

随着访问量的增加，高并发下的数据访问量使得我们单一的应用无法支撑高流量下的并发访问，同时，对数据库的频繁访问导致数据库性能满足不了业务需求。

为了解决应用程序上的瓶颈，将业务进行模块化开发，分别部署在不同的服务器上对业务需求进行支撑。

对于数据库的性能瓶颈，采用在数据库层之上加上一层缓存(Memcached)，这样的方式来减少对数据库的访问次数。从而实现数据访问性能的提高。

主从数据库，读写分离

但是缓存的方式下数据库的性能瓶颈并没有本质上解决，它充其量只是减少对数据库的直接访问量。

为了真正的解决这一问题，我们利用主从复制的方法，设置一个主数据库(master)和一个从数据库(slave)，其中主数据库只负责写操作，从数据库只负责读操作，主从数据库之间的同步使用主从复制方法来进行实现，它会有一定时间的延迟，对于实时响应要求高的业务不是很友好。

同时，为了进一步的增强数据库层次的性能，还可以配置一主多从数据库，这个时候需要利用负载均衡对读操作进行转发。也可以配置多主多从数据库，因为有多个地方可以执行写操作，需要配置我们的分布式锁来保证我们数据的一致性。

而对于主从数据库的实现，我们可以采用配置多数据源的方法来进行实现，但同时，也有第三方MyCat等为我们提供了方便的操作，我们只需要配置MyCat并且应用中的数据库配置为Mycat的地址，就可以忽略主从数据库之间的差异，这个时候（对于我们来说和传统一个数据库无区别）。

分库分表，MySQL集群

在读写分离之后，数据库的性能确实大大提高。但是，我们的读写分离之后，我们本质上操作的还是同一份数据库，我们所有的业务数据都在一份数据库上。

当数据库的数据量极大时，不管如何对数据库进行读写分离，我们要从一份上千万甚至上亿的数据量的数据库进行一个操作都会变的效率极低。这个时候，我们应该考虑的是对数据库进行分库分表，有基于水平拆分和垂直拆分的多种方法，这里只对水平拆分和垂直拆分进行一个简单的概述。

• 垂直拆分

  • 对于数据库的垂直拆分，我们可以将不同的业务模块需要用到的数据存放在不同的数据库中，比如用户模块，商品模块分别用不同的数据库来进行存储。
  • 对于数据表的垂直拆分，是基于列的拆分，可以将数据进行进一步细分和解耦合。如不同数据对象的关系专门使用一个数据表来进行存储，或者将频繁访问的数据字段专门建立一个表。

• 水平拆分

  • 对于数据库的水平拆分，将同一张数据表的数据拆分在不同数据库的数据表中并且部署在不同的服务器，极大的解决性能问题。

  • 对于数据表的水平拆分，是基于行的拆分，当一张表的数据量实在是太大时，我们可以将数据表进行水平拆分，即同样类型的数据表拆成多份存储在不同的表中，多表字段相同且数据不重复。

  • 拆分规则有（排序，时间，地域，hash取模）。

• 分库分表下数据操纵的解决方案：

  当数据进行分库分表后，操作数据库的难度大大增加。我们需要解决很多层次的问题

  • 事务支持

    分库分表后，就成了分布式事务了。如果使用数据库本身的分布式事务管理功能去实现分布式事务，将对数据库性能造成极大影响，如果在应用程序层次进行软层次实现，那将对我们程序性能造成影响。

  • 多库结果集合并（group by，order by）

    不同库的结果分别查询出来后进行合并将需要更加严谨和复杂的业务逻辑。

  • 跨库join

    分库分表后表之间的关联操作将受到限制，粗略的解决方法有：

    全局表：基础数据，所有库都拷贝一份。

    字段冗余：这样有些字段就不用join去查询了。

    系统层组装：分别查询出所有，然后组装起来，较复杂。

那么多数据库的数据库不可能放在同一个服务器中，而且对于高访问的数据库，我们需要使用多主多从的配置方式，这个时候多种错综复杂的MySQL服务集群急需要我们进行统一的治理和实现MySQL服务的高可用。

程序员更应该专注于业务逻辑的解决，而不是为了解决这些错综复杂的数据库表关系。但是数据库的性能也确实和业务开发同等重要，而各大厂商开发了中间件来实现MySQL集群的治理。其中较为主流的是中MySQL官方提供的MySQL Cluster和第三方的MyCat。两者的优缺点不同，可以根据自己的需要来进行选择。