关系型数据库的架构演变

大道至简，知行合一。

一、关系型数据库常见瓶颈

1、大量并发读/写操作，导致单库出现难以承受的负载压力；

2、单表存储数据量过大，导致检索效率低下；

二、架构演变

演变1、数据库读写分离

由Master负责写操作，而Slave作为备库，不开放写权限，但允许读权限，主从之前保持数据同步。

如果Master存在TPS（每秒处理事务数，区别于QPS）较高的情况，主从之间同步数据会存在延迟，因此写入Master之前最好将同一份数据落到缓存中，以免高并发情况下备份库取不到数据的情况。

演变2、数据库垂直分库

所谓垂直分库就是根据企业的实际业务的垂直划分，将原本冗余在单库中的数据表拆分到不同的业务库中，实现分而治之的数据管理和读/写操作。

以实际生产经验来看，以mysql为例，单表数据超过500万行时，读操作就会逐渐成为瓶颈，哪怕是索引重建也无法解决因为数据膨胀而带来的检索效率低下的问题，由于写是顺序写，基本上写入操作不会成为瓶颈，读操作会存在上限。

演变3、数据库的水平分库与水平分表

水平分表就是将原本冗余在单库中的单个业务表拆分为n个“逻辑相关”的业务子表（如：tab_011 tab_013...），不同的业务子表存储到不同的区间数据，对外形成一个整体，这就是大家所说的分片（Sharding）操作。如果Master的TPS过高，也可以进行水平分库，这个实施比较复杂，需要借助专门的分片中间件负责数据的路由工作。

后续存储达到一定阀值时，只需对现有业务库和业务表横向扩容，并迁移数据即可。

三、MySQL Sharding 与MySQL Cluster 区别

MySQL Cluster 是集群模式，扩展了数据库的并行处理能力，但是使用成本、维护成本巨大

MySQL Sharding 是分布式模式，不仅可以提升数据库并行能力，还能够解决单表数据量过大产生的检索瓶颈。

四、Sharding中间件

1、 明确定义SQL语句中的Shard Key（路由条件），因为路由维度决定数据的落盘的位置，需要定义一套特定的路由算法和规则。

2、常见Sharding中间件：

Cobar：开源，Proxy架构，支持MySQL数据库

Mycat：开源，Proxy架构，支持任意数据库

TDDL：部分开源，应用集成架构，支持MySQL和Oracle

Shark（推荐）：开源，应用集成架构，支持MySQL

3、多机SequenceID解决方案

要兼顾生成的ID的唯一性和连续性，依赖一个独立的外围单点系统来负责完成则不失为一个可取的方案，如果每生成一次就去数据库中申请必然降低性能，建议从数据库中取出一段ID，然后缓存在本地。

4、分布式事务

通过使用消息中间件的方式保证数据最终一致性。

五、数据库的HA方案

1、基于配置中心实现主从切换，将数据源信息统一配置在ZooKeeper中，主从切换之前我们必须确保Slave已经打开了读写权限。

2、基于Keepalived实现主从切换，在主从机器上装上Keepalived程序，需要修改/etc/keepalive/keepalive.conf配置文件，配置好VIP（Virtual IP Address，虚拟IP地址）。

3、保障主从数据库切换过程中的数据一致性

半同步复制可以理解为主从之间的强制数据同步，保证主从数据的实时性，只有从节点响应，主节点才会响应请求方已经完成的事务，在流量较大的场景下不建议开启此功能。

通过冗余表实现数据一致性，冗余数据核对。

消息队列或者日志比对。