数据库系列：数据库高可用及无损扩容

我不是女神ヾ 2024-03-16 13:22 25阅读 0赞

## 1 背景 ##

在大型互联网场景中，数据库的高可用性显得尤为重要，为了保证稳定性，一般需要采用强化的架构模式，以保证数据层能够提供持续有效的稳定支撑。

## 2 高可用架构的基本演进过程 ##

### 2.1 基本的数据库架构 ###

每个服务对应一个存储服务实例（基本是数据库单实例模式），使用 IP+Port 进行连接和调用，这就是大家常见的数据库直连。

![d584d75db2ff3436e99cac37b42d62ea.png][]

用户计算服务（svc） 配置IP+端口指向数据库实例地址，进行访问和操作。

### 2.1 Scale Up + Scale Out 模式 ###

互联网场景下，理论上访问量和数据量都是不断膨胀的过程。随着数据量的增大，数据库一般要进行纵向（Scale Up）和 横向（Scale Out） 的拆分，  
分库分表之后可能会将数据拆分到不同的数据库实例，甚至不同的IDC上，这样可以 降低数据量，提高执行性能的目的。详细参考笔者这篇《[MySQL全面瓦解28：分库分表][MySQL_28]》。

![333e8fdf3b9c3bb028214a5c81deb8ff.png][]

如上图，库表拆分之后，使用不同的条件可以路由到不同的IP，这样来实现业务上的数据隔离，这种条件可以是用户的角色，业务的类别，  
甚至直接对数据取模或者hash，只要确保链接到对应的数据库上即可。这边举个例子：（value % 2 == 0） = condition1，（value % 2 == 1） = condition2  
。

### 2.3 主从或主主 + Keepalived 架构 ###

以上只是解决了数据库大容量的问题，将数据库的风险降低，性能提升。并没有实质的解决可用性问题，如果其中一个数据库实例出现故障，  
依然会造成大面积的不可用。  
在互联网架构中，比较常见的一种方式就是，使用 双主或者主从同步 + keepalived + vip的模式来保证存储层的好可用性：

![76f3bcf258b8916212497e357f4910e9.png][]

如上图，两个库（主主或者主从）使用相同的虚拟IP，当主库挂掉的时候，虚ip自动转移到另一个主库（或者转移到从库上，并将从库切为主库），这个切换过程对业务应该是透明无感的，也不会造成使用上的异常，以此保证数据库的高可用性。

### 2.4 分片分库模式下的高可用性 ###

可以继续从2.3演化出分片分库模式下的高可用架构，如下：

![953550330af362f24d1ba67f9c78468d.png][]

如果数据库继续膨胀，流量继续扩展，还可以继续扩容，找到最恰当的分片模式。

### 2.5 其他常见的高可用模式 ###

#### 2.5.1 MHA ####

MHA（Master High Avaliable） 是一款 MySQL 开源高可用程序，MHA 在监测到主实例无响应后，会自动将同步最靠前（即数据偏移量最少）的 Slave 提升为 Master，然后其他所有的 Slave 重新指向新 Master。架构模式如下：

![bd073aebe3fe65a0e398df2102b28fb8.png][]

#### 2.5.2 PXC ####

PXC（Percona XtraDB Cluster）是一种开源的 MySQL 高可用解决方案。它将 Percona Server、Percona XtraBackup 与 Galera 库集成在一起，以实现多主复制的 MySQL 集群。  
缺点是只支持InnoDB引擎模式，且多主数据同步必然会有性能损耗、同步延迟和数据差异风险。  
另外，这种多主同步模式具有典型的木桶效应，系统的吞吐被最差的节点左右。  
架构如下：

![8d7f6a3a7d172da78a2aeac4b0c9e4b1.png][]

#### 2.5.3 MGR/InnoDB Cluster ####

MySQL 5.7 退出了高可用的的模式 MGR（MySQL Group Replication），他具备了多节点数据写入和强一致性的特点，这一点跟与 PXC 相似。同时采用Group Communication System（GCS协议）进行数据同步来保证消息的原子性。  
MGC需要使用到InnoDB Cluster模式，才能实现真正的高可用，高可用架构图参考下面：

![e2395b88f59538db2c235ca4fc7599c2.png][]

备注：图片来自官网，就不再画了。

### 2.6 高可用模式下的平滑扩容 ###

互联网大流量场景下我们经常会发现存储层容易出现瓶颈，这个时候就需要扩容。  
相对于停服扩容来说，无损、透明、平滑的数据库扩容才是我们实际追求的目标。

![6b18ccb1b3cb138044b4a093236e29b1.png][]

步骤如下：

*  增加数据库分片3，进行数据架构初始化和数据同步
 *  增加数据库主从配置，将2个库的数据库配置，改为3个库的数据库配置，并注意旧库与新库的映射关系。
 *  服务层 reload（重新加载）配置，完成扩容工作。
 *  删除分片之后的冗余数据，必要的话进行数据库缩容。
 *  服务层根据条件映射到不同的数据库实例中。

## 3 总结 ##

数据库存储层实现可用性有很多种办法。除了最基本的 主从/主主 + Keepalived 架构 之外，还有 MHA 、 PXC 、MGR/InnoDB Cluster 等，后面我们一一拆解。  
实现高可用，意味着后续的迁移、扩容、业务调整，都应该是可以平滑的，对业务无感的。

[d584d75db2ff3436e99cac37b42d62ea.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/26e2b7358bd64334a182403237792b92.png
[MySQL_28]: https://www.cnblogs.com/wzh2010/p/15049878.html
[333e8fdf3b9c3bb028214a5c81deb8ff.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/4bfdfbf490764f79b97f78401b7ca239.png
[76f3bcf258b8916212497e357f4910e9.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/0fe18f04d6cb4fa1836f4167f8756e42.png
[953550330af362f24d1ba67f9c78468d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/b51d1cf286374b888ba415c62bb4e6fa.png
[bd073aebe3fe65a0e398df2102b28fb8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/6c424de15fc94d5bbbe7e907101a122a.png
[8d7f6a3a7d172da78a2aeac4b0c9e4b1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/26a4958e771b42fb8b82b3c67894c824.png
[e2395b88f59538db2c235ca4fc7599c2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/845650a9fe3c4ef290b15d6bb6db6ab6.png
[6b18ccb1b3cb138044b4a093236e29b1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/16/d02e43377cd24488bcc7fba8ecfa57b6.png