1 背景

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

2 高可用架构的基本演进过程2.1 基本的数据库架构

每个服务对应一个存储服务实例（基本是数据库单实例模式），使用 IP+Port 进行连接和调用，这就是大家常见的数据库直连。用户计算服务（svc） 配置IP+端口指向数据库实例地址，进行访问和操作。

2.1 Scale Up + Scale Out 模式

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

(资料图)

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

2.3 主从或主主 + Keepalived 架构

以上只是解决了数据库大容量的问题，将数据库的风险降低，性能提升。并没有实质的解决可用性问题，如果其中一个数据库实例出现故障，依然会造成大面积的不可用。在互联网架构中，比较常见的一种方式就是，使用 双主或者主从同步 + keepalived + vip的模式来保证存储层的好可用性：如上图，两个库（主主或者主从）使用相同的虚拟IP，当主库挂掉的时候，虚ip自动转移到另一个主库（或者转移到从库上，并将从库切为主库），这个切换过程对业务应该是透明无感的，也不会造成使用上的异常，以此保证数据库的高可用性。

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

可以继续从2.3演化出分片分库模式下的高可用架构，如下：如果数据库继续膨胀，流量继续扩展，还可以继续扩容，找到最恰当的分片模式。

2.5 其他常见的高可用模式2.5.1 MHA

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

2.5.2 PXC

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

2.5.3 MGR/InnoDB Cluster

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

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

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

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

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

关键词：