架构设计之「数据库从主备到主主的高可用方案」

在互联网项目中，当业务规模越来越大，数据越来越多，随之而来的就是数据库压力会越来越大。慢慢就会发现，数据库层可能已经成为了整个系统的关键点和性能瓶颈了，因而实现数据层的高可用就成为了我们项目中经常要处理的问题。

本文我们就来聊一聊如何实现数据存储层的高可用方案。在保障数据层的高性能与高稳固方面，最容易想到的方式就是对数据进行分片、多份、冗余等，很多架构的本质其实也是基于这几点来实现的。

这里先不看细节，即先不论底层数据源是什么数据库，我们先只聊架构方案，由于无论底层是关系型数据库，还是NoSQL数据库，无论是 Mysql 还是 Redis、MongoDB，我们在架构设计上都是相通的。

大体上，单中心双机的常见方案有以下这些：

一主一备的架构（主备式）

一主一从的架构（主从式）

互为主从的架构（主主式）

以上方案从上至下，依次是从简单到复杂，从基础到丰富。下面我们来具体看看：

一、一主一备的架构（主备式）

主备式架构是双机部署中最简单的一种架构了，几乎市面上所有的数据库系统都会自带这个主备功能。

如图，

其思路也特别的简单：将数据库部署到两台机器，其中一台机器（代号A）作为日常提供数据读写服务的机器，称为「主机」。另外一台机器（代号B）并不提供线上服务，但会实时的将「主机」的数据同步过来，称为「备机」。一旦「主机」出了故障，通过人工的方式，手动的将「主机」踢下线，将「备机」改为「主机」来继续提供服务。

这个架构的优缺点都很显著，优点就是几乎不需要做什么开发改造，各类数据库就支持这种模式，部署维护起来也简单，并没有引入额外的系统复杂度和瓶颈。

但是缺点呢，就是当「主机」出现故障的时候，需要人工去干预啊，运维同学很辛苦的，而且解决还不肯定及时。再还有一个缺点就是，主备架构会造成严重白费资源，毕竟需要一台与「主机」同等配置的「备机」长期备着，但又不作为线上服务来使用，你说白费不白费。

为理解决这个资源白费问题，我们就得想一个把「备机」也用起来的方案：主从式架构。

二、一主一从的架构（主从式）

主从式架构大体上与上述的主备式架构差不多。区别就是主备式的「备机」平常是不干活的的，主要起到备份的作用。而主从式的「备机」改为了「从机」，平常也要提供服务，跟「主机」一样随时随刻的在干活的。

如图，

主从式架构中的「从机」尽管也在随时随刻提供服务，但是它只提供「读」服务，并不提供「写」服务。「主机」会实时的将线上数据同步到「从机」，以保证「从机」能够正常的提供读操作。

这种架构相比较主备式，对资源是一种节约，毕竟「从机」也在提供服务，没有白白的白费。并且在「主机」出现故障时，在人工介入之前，好歹「从机」也是能够提供数据的「读」操作的，毕竟大多数业务都是「读」多「写」少，因而对稳固性又提高了一个层次。

缺点就是架构略微复杂了一点，毕竟「主机」和「从机」都有「读」服务，那么前台业务系统就需要用肯定策略去判断该路由到哪一台去读取数据。还有就是，推迟问题，「主机」的数据同步到「从机」难免会有肯定程度的推迟，这个推迟可能会对数据实时性要求较高的业务有肯定影响。

通过上面内容可以看到，尽管这个架构肯定程度处理了资源白费，但是并没有处理人工干预的问题，当出现了故障后还是需要人工去解决。

假如想让架构更智能一点，那么我们就需要引入「主从双机自动切换」的功能。

主从双机自动切换：是指当主机出现故障后，从机能够自动检测发现。同时从机将自己迅速切换为主机，将原来的主机立即下线服务，或者转换为从机状态。

要实现「主从双机自动切换」，有几个关键点需要考虑：

主机与从机之间的状态如何判断？?

必需有一个机制能监测两台机器的运行状态，以此来决定能否应该切换。

我们比较常用的状态传递方式有两种：

「双机互连模式」

「第三方中介模式」

「双机互连模式」：是指在主机和从机之间建立一条用于状态通讯的通道。通过这个通道，主机和从机之间可以共享服务状态，一旦发现对方宕机或者者中止服务了，即可以立即将自己切换为主服务。不过这种方式需要关注通道的健壮性，一旦通道自身不稳固了，可能会导致假消息出现，比方主机并没有宕机，但是通道坏了，导致从机以为出现了异常，就将自己切换为了主机，那就出现了2个主机了，因而通道本身也是一个可能的故障点。

「第三方中介模式」：是指在主机和从机之外，再建立一个中介机器，这个中介机器专门用来维护各节点（主机/从机）状态的，主机/从机实时的将自身状态上报给中介机器，中介机器来决定能否应该切换、何时切换。MongoDB的Replica Set就是采用的这种模式。

除了状态判断，还需要考虑切换的策略是什么？ 也就是说发生异常几次/多久后开始切换，能否有一个缓冲机制等。另外切换完成后，当原主机又恢复正常之后能否需要自动再切换回来等策略。

另外就是需要注意在切换过程中双机数据假如发生冲突时，以哪个为准？解决机制是什么。

这些细节都是在设计主从自动切换架构时候，要提前规划的。

三、互为主从的架构（主主式）

互为主从的架构是指两台机器自己都是主机，并且也都是作为对方的从机。两台机器都提供完整的读写服务，因而无需切换，用户机在调用的时候随机筛选一台就可，当其中一台宕机了，另外一台还可以继续服务。

如图，

采用 互为主从架构 有个复杂点就是，由于两台主机都接受写数据，那就需要将写的最新数据实时的同步给对方，需要将数据进行两台主机的双向复制。而双向复制不可避免的会在肯定程度上带来数据推迟、极端情况下甚至有数据丢失等问题。在实际业务中，有些业务数据对一致性要求是非常高的，并不能接受数据的推迟、丢失，因而这类业务也不适合互为主从的模式，比方金融业务。但是我们互联网业务中大多数场景还是没有这么高要求的，所以这种模式对于一般场景还是用的蛮多。

以上，就是对数据库从主备架构、到主从架构、再到主主架构的高可用方案基本讲解了

欢迎工作一到五年的Java工程师朋友们加入Java架构开发：744677563

群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）正当利用自己每一分每一秒的时间来学习提升自己，不要再用”没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！