在工程项目中，系统应用的高可用性越来越重要，业主越来越重视。其实高可用可以分为应用层高可用和数据层高可用，数据层高可用中常见的有关系型数据库Mysql的高可用、非关系型NoSQL数据库Redis的高可用等，下面聊聊典型的关系型数据库mysql的高可用方案。

1、单中心双机

单中心双机的常见方案如下：

• 一主一备架构（主备）
• 一主一从架构（主从）
• 互为主从架构（双主）

1.1、一主一备

一主一备架构是双机部署中最简单的一种架构了，mysql数据库系统自带这个数据同步（主备）功能。
思路：将mysql数据库部署到两台机器，其中一台机器作为日常线上提供数据读写服务的机器，称为主机；另一台机器不提供线上服务，但会实时将主机的数据同步过来，称为备机。一旦主机出现了故障，通过人工的方式，手动将主机下线，将备机改为主机来继续提供服务。
优点：不需要做什么开发改造。
缺点：当主机出现故障的时候，需要人工去干预；还有就是需要一台备机长期备着，单又不提供线上服务，浪费资源。

1.2、一主一从

为了解决资源浪费的问题，出现了一主一从架构。
思路：一主一从架构与一主一备架构一样。区别就是一主一备的备机不提供线上服务，主要起到备份作用；而一主一从的备机改为了从机，也提供线上服务，但是只提供读服务，不提供写服务。
优点：相对一主一备架构，节约了资源，从机也在线提供读服务。当主机出现故障的时候，在人工介入之前，从机依旧可以提供读服务，可用性又提高了一个层次。
缺点：架构稍微复杂了一点，业务系统需要用一定的策略去判断该路由到那一台去读取数据，且数据同步会有延迟，去从机读取数据也可能会有延迟；还有就是并没有解决人工干预的问题，当主机出现了故障后还需要人工去处理。
若想让架构更智能一旦，需要引入一主一从自动切换功能，当主机出现故障后，从机能够自己检测发现，并自己将自己切换为主机，将原来的主机下线或转换为从机，即数据同步方向变了，但复杂度和成本加剧，不好实现。

1.3、互为主从

互为主从架构是指两台机器自己都是主机，并且也都是对方的从机，两台机器都提高完整的读写服务，无需切换。当应用系统在调用的时候随机挑选一台即可，当其中一台宕机了，另一台还可以继续服务。
思路：两台机器互为主从，都接受写数据，并将数据实时同步给对方，需要将数据进行两台机器的双向复制。通过VIP对外提供唯一一个服务地址，如通过keepalived组件实现ip漂移，当绑定的机器宕机了，漂移到另一台机器继续提供服务。
优点：解决了人工干预的问题，可用性得到进一步提高。
缺点：架构复杂度加剧，不可避免会有一定程度的数据延迟，极端情况下甚至会有数据丢失问题。

2、多机

常见的多机方案如下：

• 单中心数据集群
• 多中心数据分区

2.1、单中心数据集群

单数据中心多机器集群又分为：

• 数据集中模式（一主多从）；
• 数据分散模式；

这两种的主要区别在于集群中的完整业务数据是全部集中在一台机器上，但是分散在多台机器上。

数据集中模式

这种模式与一主一从架构类似，完整的业务数据还是存储在一台主机上，主机承担读服务和写服务，从机只承担读服务。但是从机有多台机器，从机实时的从主机同步数据，称为一主多从模式。
因为有多个从机，带来了一些额外需要处理问题，比如：

• 主机需要实时的将数据同步到多台从机上，涉及到主机的处理压力问题。
• 需要保障多台从机之间的数据一致性的问题，如果出现数据不一致，如何处理。
• 多台从机是如何检测主机状态的，因为从机在关键时刻是要替换主机的，那么如果多台从机监测到的主机状态不一致，那又可能会带来其它问题。
• 从机切换为主机的时候，选择哪一台从机来切换呢，这涉及到多台从机之间如何进行选举的问题。

由于数据集中模式的所有写操作都只到一台主机上，而读操作可以到N台从机上。因此这种模式比较适用于业务数据量不大、读操作远远大于写操作、集群规模较小的业务场景。

数据分散模式

数据分散模式是指，完整的业务数据并非是全部存储在一台主机上的，而是由多台主机共同分担，分散存储。
使用这种模式，也有几点需要特别注意的：

• 尽量将数据均衡的分散的各个机上，这样才能保证资源的均衡使用和性能的最佳。
• 多台机器上的数据虽然不同，但是也需要互相进行数据的备份。
• 要能动态的增加和删除节点，这样可以便于随时扩展，通常采用一致性HASH的方法。

这种模式适用于大数据量、集群规模较大的场景。

2.2、多中心数据分区

出于容灾的考虑，通常会在多个不同地区部署多套的数据集群。毕竟在国内运营商网络故障、光纤被铲断等事件还是不少的。轻则一个机房出问题，重则一个城市一个省份都可能故障。
多中心的数据分区架构，将数据按照一定的规则进行分区，部署在不同机房/城市里，且每一个分区都存储一部分数据，通过这种方式来保障数据和服务的可用性。
这种架构中需要考虑分区规则和备份规则，复杂度加剧，详细方案请参考大佬博客。

3、mysql双主+keepalived实现双机热备高可用

双主+keepalived是非常典型的mysql高可用方案，架构示意如下：

在主实例的keepalived中，增加检测本机mysql是否存活的脚本，如果检测mysql宕了，就会重启keepalived，从而使VIP漂移到从实例。

优点：部署简单，只有两个节点，没有主实例宕机后选主的问题；业务应用不需要开发改造。
缺点：云环境使用不了。
具体可以参考《浅入浅出keepalived+mysql实现高可用双机热备》博客。
该高可用方案也可以扩展到一主多从的场景，保证多从机器从主机器实时同步数据，利用keepalived等第三方软件同时使用，即可以用来监控数据库的健康，又可以执行一系列管理命令，如果主库发生故障，切换到备库后仍然可以继续使用数据库。

4、小结

mysql的高可用还有其他解决方案，如下：

• MHA（Master High Avaliable） 是一款 MySQL 开源高可用程序，MHA 在监测到主实例无响应后，可以自动将同步最靠前的 Slave 提升为 Master，然后将其他所有的 Slave 重新指向新的 Master。MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。
• PXC（Percona XtraDB Cluster）是一个完全开源的 MySQL 高可用解决方案。它将 Percona Server、Percona XtraBackup 与 Galera 库集成在一起，以实现多主复制的 MySQL 集群。任何节点宕机，集群都可以继续运行而不会丢失任何数据。

具体那种方案还需要考虑具体的应用场景，如当工程应用采用云平台时，平台也会提供mysql的高可用能力，如mysql容器化部署，且具有副本机制、节点宕了后快速拉起机制，也提供了mysql的高可用性。

来源地址：https://blog.csdn.net/leijie0322/article/details/130905260