高可用数据库是由一系列数据库构成的总体系统，在任何时刻，至少有一个节点可以接受用户的请求并提供数据库服务。
高可用数据库的优点：
第一，方便读写分离。
高可用数据库可以通过将写操作放在主数据库节点上进行，将读操作分担到若干从库上，来提升读操作吞吐量，进而提升读写效率。
1.读写分离其实就是将数据库分为了主从库，一个主库用于写数据，多个从库完成读数据的操作，主从库之间通过某种机制进行数据的同步，是一种常见的数据库架构。
2数据库分组架构解决什么问题？
大多数互联网业务，往往读多写少，这时候，数据库的读会首先称为数据库的瓶颈，这时，如果我们希望能够线性的提升数据库的读性能，消除读写锁冲突从而提升数据库的写性能，那么就可以使用“分组架构”（读写分离架构）。
用一句话概括，读写分离是用来解决数据库的读性能瓶颈的。
3.为什么不使用缓存呢？
缓存的使用成本要比从库少非常多；缓存的开发比较容易，大部分的读操作都可以先去缓存，找不到的再渗透到数据库。当然，如果我们已经运用了缓存，但是读依旧还是瓶颈时，就可以选择“读写分离”架构了。简单来说，我们可以将读写分离看做是缓存都解决不了时的一种解决方案。
当然，缓存也不是没有缺点的
对于缓存，我们必须要考虑的就是高可用，不然，如果缓存一旦挂了，所有的流量都同时聚集到了数据库上，那么数据库是肯定会挂掉的。
4.读写分离不使用的瓶颈
对于常见的数据库瓶颈是什么呢？
其实是数据容量的瓶颈。例如订单表，数据量只增不减，历史数据又必须要留存，非常容易成为性能的瓶颈，而要解决这样的数据库瓶颈问题，“读写分离”和缓存往往都不合适。
大部分的互联网业务，数据量都非常大，单库容量最容易成为瓶颈，当单库的容量成为了瓶颈，我们希望提高数据库的写性能，降低单库容量的话，就可以采用水平切分了。
而有少部分程序员，会没有分析数据库的性能瓶颈是什么，就贸贸然的使用“读写分离”，殊不知“水平切分”才是正道。
第二，变更不停服。
当整个高可用数据库架构或主节点升级时，可以让高可用数据库先进行主库切换，备用节点替换原主节点提供数据库服务，当主节点升级完毕后，再将主从库服务切换回来，这样能有效避免系统升级或变更时对用户服务质量产生影响。
第三，备份不影响服务性能。
高可用数据库架构包含多个从库，在不影响主节点服务性能的情况下，能非常方便地实现数据的容灾备份。
典型高可用数据库架构
按照数据同步方式，可以将业界主流高可用架构分为四种：共享存储方案、操作系统实时数据块复制、数据库级别的主从复制、高可用数据库集群。每一种数据同步方式可以衍生出不同架构。
方案一：共享存储
共享存储指若干DB服务使用同一份存储，一个为主DB，其它为备用DB。若主服务崩溃，则系统启动备用DB，成为新的主DB，继续提供服务。一般共享存储采用比较多的是SAN/NAS方案。
（图：共享存储）
虽然该方案的优点是没有数据同步的问题，但也有一些限制，如对于共享存储的实时性和网络性能有较高要求。而随着硬件性能的不断提升，将计算存储分离、和DB深度结合的共享存储亦是高可用数据库未来发展趋势之一。
方案二：操作系统实时数据块复制
这一方案的典型场景是DRBD，可以理解为远程的RAID1。如下图所示，左侧数据库写入数据以后，立即同步到右侧的存储设备当中。如果左边数据库崩溃，系统可以直接**右边的数据库存储设备，启动新的数据库服务，实现容灾切换。
（图：操作系统实时数据块复制）
这个方案的缺点也比较明显，如系统只能有一个数据副本提供服务，无法实现读写分离；另外，如果系统崩溃，主库进程中断，容灾切换后需要在挂掉的数据库上做数据库崩溃恢复，系统需要的容灾恢复时间较长。
方案三：数据库主从复制
这种方案是最经典的数据同步模式，系统采用一个主库和多个从库方式，实现原理主要是基于日志的主从复制，主库操作以日志的形式发送给各个从库，从库接收到日志后进行数据备份。
优点是一个主库可以连接多个从库，能很方便地实现读写分离，同时因为每个备库都在运行中，所以备库里的数据基本都是热数据，容灾切换也非常快。
不过，这个方案也并非完美无缺，如容灾切换时，从库一定要同步完最新数据以后才能升级为主库，否则极有可能导致数据丢失。针对这些问题，业界也正在研发对应的改进技术。
方案四：数据库高可用集群
前三种方案主要通过日志的复制模式实现高可用，第四种方案则基于一致性算法来做数据同步，数据库提供多节点一致性同步机制，利用该机制构建多节点同步集群。这种方式比较经典的案例包括MGR（MySQL Group Replication）和Galera等，近期业内也有一些类似尝试，如使用一致性协议算法，自研高可用数据库架构等。
（图：数据库高可用集群）
如上图所示，五个节点构建成了一个一致性的同步集群，客户端可以读写其中的任一节点，其它节点都能进行数据同步，因此理论上每个节点都可以进行读写操作。这种方式的容灾实现也比较简单，假设第二个节点出现故障，系统只需要断开客户端对第二个节点的访问路径，其它节点照常访问即可，这也是业界近年来比较流行的高可用集群方案。
参考：https://baijiahao.baidu.com/s?id=1610050327068432075&wfr=spider&for=pc