mysql演化历程

1、单节点数据库

2、一主一从数据库

（1）Master/slave复制原理以及方式

a、Master所有的数据更新会记录到日志binlog中，Master A把binlog日志传给slaveB

b、B先把A的binlog日志放到称为relaylog中继日志的地方

c、最后B通过relaylog日志中的内容对自己的binlog进行更新，复制数据

这种机制可以保证A和B的数据一致，但是同步或许会有延时，

3、一主多从架构

4、双主多从架构

5、数据库进行切分，会面临路由问题，互联网常见数据路由有三种：

（1）按照数据范围路由，比如有两个分片，一个是0-10亿，一个是1亿-2亿，这样来路由。这个优点是非常简单，并且扩展性好，假如两个分片不够了，增加一个2亿-3亿的分片即可，这个方式缺点：虽然数据的分布是均衡的，每一个库的数据量差不多，但请求的负载会不均衡，例如有一些业务场景，新注册的用户活跃度更高，大范围的分片请求负载会更高。

（2）按照hash路由，如果有两个分片，数据模2寻库即可。这个优点是路由方式简单，数据分布也是均衡的，请求负载也是均衡的，缺点是如果两个分片数据量过大，要变成三片，数据迁移比价麻烦，即扩展性会受限。

（3）路由服务，前面两个数据路由方法均有一个缺点，业务线需要耦合路由规则，如果路由规则发生变化，业务线是需要配合升级的，路由服务可以实现业务线与路由规则的解耦，业务线每次访问数据库之前先调用路由服务，来知道数据究竟存放在哪个分库上。

分组与复制，这是解决扩展读性能，保证读高可用的问题。

根据经验，大部分互联网的业务都是读多写少，淘宝、京东查询商品，搜索商品的请求可能占了99%，只有下单的支付的时候有写请求。一般来说，读性会成为瓶颈，那么如何快速解决这个问题呢？

我们通常使用读写分离，扩充读库的方式来提升系统的性能，同时多个读库也保证了读的可用性，一台读库挂了，另一台读库可以持续的提供服务。

上图是“读”高可用的常见玩法，那么怎么保证读库的高可用呢？解决可用这个问题的思路是冗余。

解决站点的可用性问题冗余多个站点，解决服务的可用性问题冗余多个服务，解决数据的可用性问题冗余多份数据。如果用一个读库，保证不了读高可用，就复制读库，一个读库挂了另一个仍然可以提供服务，这么用复制的方式来保证读的可用性。

数据冗余会引发一个副作用，就是一致性的问题。

主从不一致怎么解决呢？读写会有时延，有可能读到从库上的旧数据，常见方法就是引入中间件，业务层不直接访问数据库，而是通过中间件访问数据库，这个中间件会记录哪一些key上发生了写请求，在数据主从同步时间窗口之内，如果key上又出了读请求，就将这个请求也路由到主库上去（因为此时从库可能还没有同步完成，是旧数据），使用这个方法保证数据的一致性。

中间件很理想，但大部分公司并没有采用，因为数据库中间件技术门槛比较高。