MYSQL 数据库企业级架构演变史

从初级架构到中级架构原来有这么多次的升级，并且每一次的进阶都有其优缺点，文末还有对高级结构的理解，欢迎大家在评论区各抒己见～

MySQL简介

MySQL 是一个关系型数据库管理系统，由瑞典 MySQL AB公 司开发，目前属于 Oracle 公司。
MySQL 是一种关联数据库管理系统，关联数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。MySQL 所使用的 SQL 语言是用于访问数据库的最常用标准化语言。MySQL 软件采用了双授权政策，它分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，使其成为了当前最受欢迎的关系型数据库之一。

MYSQL 架构演变

随着公司业务由初期访问量低、数据量低，稳步提升到后期高并发、数据量多，mysql 数据库的架构也在逐渐改变，由简到复杂。

备注：

主库读写，从库只读；

初级阶段

描述：

初期由于并发量以及数据量都比较低，不会太注重数据库方面的潜在问题，所以只提供单主。也类似直接申请 RDS 单节点服务。

优点：

• 架构简单

• • 对运维人员易部署维护；- 对开发人员易使用；

缺点：

• 无 HA；

• 备份需要考虑情况

• • 逻辑备份在非高峰期间无影响；- 物理备份在极短时间下会锁住全库（数据量小，数据文件不多）；

• 无伸缩性：若突然请求量/数据量激增，极容易产生性能故障导致生产故障；

初中级阶段

描述：

当业务达到一定量级，开始考虑数据安全性，同时读写请求开始增多，请求也开始增多，主从架构就随之适合（写请求过多导致单实例扛不住，或写请求过多导致主从延迟，可采用分片的方案，每个分片也均是主从架构。分片问题不在本文中深度讲解）。

优点：

• 可根据读请求压力对从库进行扩容；
• 异地容灾；
• 可单独选取一个从库做备库
• a. 不影响线上业务；
• b.该备库是否对外提供服务视该备库的压力以及库表多少等情况而定；
• c. 可提供内部的离线查询（即不对外的业务）；
• 可读写分离；

缺点：

• 无 HA

• • 主库故障时，需要人工介入寻找接收 binlog 最新的从库，并将其他从库应用差异并指到新主库，操作繁琐且容易出错（5.6 以后开启 GTID 可以自动校验并修补当前差异）；- 主库发生切换后，业务得修改 IP 重新发布；

• 无法灵活的随着业务配置来进行扩缩容；

中级阶段 1

描述：

随着业务的发展，对数据库可用性开始有一定要求，也就出现双主的架构。该架构下，优缺点也很明显。

优点：

• 具备一定的可用性，如 A 主库不可用后，B 主库还可以承担写能力，能保证一定可用性，同时业务可更改主库 IP 进行切换；
• 分担了读写压力；
• 当故障节点恢复后，故障节点能通过复制进行数据恢复(应用其他节点数据)和数据同步(将未同步数据发生给其他节点)。

缺点：

• 主主模式下，很容易因数据访问控制不当导致数据冲突。
• 为提高系统高可用性，双主架构会被扩展成双主多从结构，同样存在主节点发生故障后多个从库选主和恢复复制的问题。
• 成本较高；
• 主库 A 宕机后，可能会存在部分数据(Binlog)未同步到另外的主节点，导致数据丢失(直到故障节点恢复)。

中级阶段 1 改进（1）

描述：

在中级阶段 1 的改进，VIP 类似 keepalive 这类软件，本身不分发流量，只浮动 IP。这样牺牲了一定特性，将数据库高可用提升了一些（探活以及VIP切换时间）；

优点：

• 高可用得到一定提升，主节点 A 发生故障后，能快速切换到另一个主库；
• 不会因为写两个主库的数据导致主键/唯一键冲突；
• 当故障节点恢复后，故障节点能通过复制进行数据恢复(应用其他节点数据)和数据同步(将未同步数据发生给其他节点)。

缺点：

• 较改进前方案，未能分担读写压力，这样成本就比较高；
• 为提高系统高可用性，双主架构会被扩展成双主多从结构，同样存在主节点发生故障后多个从库选主和恢复复制的问题。
• 主库 A 宕机后，可能会存在部分数据(Binlog)未同步到另外的主节点，导致数据丢失(直到故障节点恢复)。

中级阶段 1 改进（2）

描述：

在中级阶段 1 的改进，LB/LVS 可以根据权重来分发各节点（主库）流量，以及删减节点，具备一定的高可用和负载均衡，但配置完成后都有一定的滞后性。

优点：

• 具备一定的可用性，如 A 主库不可用后，B 主库还可以承担写能力，能保证一定可用性，同时 LB/LVS 本身也可根据探活或者人工介入来调整权重以及节点（具有一定滞后性），达到一定高可用；
• 分担了读写压力；
• 当故障节点恢复后，故障节点能通过复制进行数据恢复(应用其他节点数据)和数据同步(将未同步数据发生给其他节点)。

缺点：

• 该模式下，很容易因数据访问控制不当导致数据冲突。
• 为提高系统高可用性，双主架构会被扩展成双主多从结构，同样存在主节点发生故障后多个从库选主和恢复复制的问题。
• 成本较高；
• 主库 A 宕机后，可能会存在部分数据(Binlog)未同步到另外的主节点，导致数据丢失(直到故障节点恢复)。

中级阶段 2

描述：

MHA（Master High Availability Manager and tools for MySQL）目前在MySQL高可用方面是一个相对成熟的解决方案，它是由日本人youshimaton采用Perl语言编写的一个脚本管理工具。目前MHA主要支持一主多从的架构，要搭建MHA，要求一个复制集群必须最少有3台数据库服务器，一主二从，即一台充当Master，一台充当备用Master，另一台充当从库。

MHA由两部分组成：MHA Manager（管理节点）和MHA Node（数据库节点），MHA Manager 可以单独部署在一台独立的机器上管理多个 master-slave 集群，也可以部署在一台 slave 节点上。MHA Node 运行在每台 MySQL 服务器上，MHA Manager 会定时探测集群中的 master 节点，当 master 出现故障时，它可以自动将最新数据的 slave 提升为新的 master，然后将所有其他的 slave 重新指向新的 master。整个故障转移过程对应用程序完全透明。

MHA工作原理

1. 从宕机崩溃的Master保存二进制日志事件（binlog event）；
2. 识别含有最新更新的Slave；
3. 应用差异的中继日志（relay log）到其他Slave；
4. 应用从Master保存的二进制日志事件；
5. 提升一个Slave为新的Master；
6. 使其他的Slave连接新的Master进行复制；

类似组件

类似的数据库高可用组件还有 orchestrator、replication-manager，各自有各自的特点，感兴趣的小伙伴可以了解。

orchestrator：orchestrator/docs at master · openark/orchestrator · GitHub

replication-manager：Introduction | Signal 18 - Documentation

优点：

• MHA能做到0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能最大程度上保证数据库的一致性，以达到真正意义上的高可用；
• 可以选取从库晋升主库优先级，某些时候并不希望某台从库成为新主库；
• 可跨机房部署，异地容灾；
• 可实现一定程度的读写分离，如主库配置 VIP，从库配置 LVS/LB；

缺点：

• 主库服务器宕机，还是存在丢失数据的风险（可通过半同步复制解决，但开启半同步复制，会降低写入性能）；
• MHA manager 单节点问题；
• 主库发生切换后，读写分离中从库的 LVS/LB（配置了的情况下） 需要调整；
• 基于 VIP 的配置，需要配置双机信任机制，需要较高的权限，这点在有的环境中是不被允许的；

中高级阶段 1

描述：

PXC是Percona XtraDB Cluster的缩写，是 Percona 公司出品的免费MySQL集群产品。PXC的作用是通过mysql自带的Galera集群技术，将不同的mysql实例连接起来，实现多主集群。在PXC集群中每个mysql节点都是可读可写的，也就是主从概念中的主节点，不存在只读的节点。

PXC 是一套 MySQL 高可用集群解决方案，与传统的基于主从复制模式的集群架构相比 PXC 最突出特点就是解决了诟病已久的数据复制延迟问题，基本上可以达到实时同步。而且节点与节点之间，他们相互的关系是对等的。PXC 最关注的是数据的一致性，对待事物的行为时，要么在所有节点上执行，要么都不执行，它的实现机制决定了它对待一致性的行为非常严格，这也能非常完美的保证 MySQL 集群的数据一致性。

优点：

• 多主复制，可以在任意节点进行写操作；
• 故障切换：因为支持多点写入，所以在出现数据库故障时可以很容易的进行故障切换；
• 自动节点克隆：在新增节点或停机维护时，增量数据或基础数据不需要人工手动备份提供，galera cluster会自动拉取在线节点数据，集群最终会变为一致；
• 强一致性、无同步延迟；

缺点：

• 复制只支持InnoDB 引擎，其他存储引擎的更改不复制；
• 写入效率取决于节点中最慢的一台；
• 在多主模式中不支持UNLOCK TABLES 以及 LOCK TABLES 锁定功能，如GET_LOCK()，RELEASE_LOCK()等也不被支持；
• 不支持XA事务：
• TPS 相比于传统主从，会低一些；

中高级阶段 2

描述：

MGR(MySQL Group Replication)是MySQL官方在MySQL 5.7.17版本中以插件形式推出的主从复制高可用技术，它基于原生的主从复制，将各节点归入到一个组中，通过组内节点的通信协商(组通信协议基于Paxos算法)，实现数据的强一致性、故障探测、冲突检测、节点加组、节点离组等等功能。

优点：

• 高一致性，基于原生复制及paxos协议的组复制技术，并以插件的方式提供，提供一致数据安全保证；
• 高容错性，只要不是大多数节点坏掉就可以继续工作，有自动检测机制，当不同节点产生资源争用冲突时，不会出现错误，按照先到者优先原则进行处理，并且内置了自动化脑裂防护机制；
• 高扩展性，节点的新增和移除都是自动的，新节点加入后，会自动从其他节点上同步状态，直到新节点和其他节点保持一致，如果某节点被移除了，其他节点自动更新组信息，自动维护新的组信息；
• 高灵活性，有单主模式和多主模式，单主模式下，会自动选主，所有更新操作都在主上进行；多主模式下，所有server都可以同时处理更新操作。

缺点：

• 存储引擎必须为Innodb，即仅支持InnoDB表，并且每张表一定要有一个主键，用于做write set的冲突检测；
• 必须打开GTID特性，二进制日志格式必须设置为ROW，用于选主与write set；
• COMMIT可能会导致失败，类似于快照事务隔离级别的失败场景；
• 节点扩展性具有局限性（目前一个MGR集群组最多支持9个节点）；
• 多主模式不能完全支持级联外键约束；
• 只支持ipv4；

中高级阶段 3

描述：

区别于上述多节点都可以写的节点同步，该架构下最底层还是标准的 mysql 主从复制，通过高可用组件进行监控以及主从切换，上层通过 proxy 进行主从读写分离以及路由，高可用组件通过 hook 函数或其他方案和 proxy 层通信修改主从信息。该方案下，LVS/LB 下层的所有对业务而言均透明。如发生主从切换或者从库/proxy 扩缩容，业务无需知道底层的变动，仅 DBA 在 LB 层或 proxy 层进行操作即可，业务也基本上无感知。

该架构是众多互联网公司数据库架构的基础，各厂会根据自有特性在上面增加一些组件以实现不同的需求。如美团还有一层独立的配置中心，业务根据配置中心拉取分库分表信息，再连接 LVS/LB 拉取对应的数据。如之前 ofo 小黄车公司，也有一层独立的配置中心，业务通过配置中心拉取数据库连接串信息，而数据库连接串信息都保存在 zookeeper 中，业务无法看到真实的数据库连接信息，同时 proxy 层存储的数据库主从信息，也都存储在 zookeeper 中。

该架构下，一篇各组件选取以及高可用测试已经完成，大家有兴趣的话，后续可以将测试文档发出。

优点：

• LB 下层对业务透明，不需要做额外配置和修改；
• 高可用以及时效性，一般在 0S-30S 之间可完成切换；
• 不存在因多 mysql 节点写入造成锁等待或死锁的问题（业务自身原因除外）；
• 计划内调整主库方便，只需要在 proxy 层改动配置即可，业务无需做任何修改；
• 从库读能力以及 QPS 能力可以灵活扩缩容，从库数量取决于 proxy 能力以及主库服务器配置；
• 可配置备份库作为离线查询的地址，供内部平时查询数据，不影响线上；

缺点：

• 架构越复杂，程序和下层 proxy、mysql 的适配就越复杂，配置不合适的时候会出现连接突然丢失、连接不上等情况；
• 从库出现的延迟，如果 proxy 层不能干预的话，会导致数据不一致性；
• 架构的复杂程度，和排查问题的复杂程度成正比；
• 主库服务器宕机，还是存在丢失数据的风险（可通过半同步复制解决，但开启半同步复制，会降低写入性能）；

结语：

可能大家发现了，为什么没有高级架构。

其实每种架构都不存在绝对的好坏，适合当前业务的架构才是好架构，才是高级架构。