2024了还有人不知道MySQL的高可用三大架构？？？

高可用定义

什么是高可用？

高可用：

• 高可用是系统所能提供无故障服务的一种能力。

可用能力的判断标准：

一般来说，系统至少要达到 4 个 9999，否则用户体验会非常差。

4 个 9 对于生产环境影响还比较大，5 个 9 的要求又太高，于是一些云服务厂商提出来 99.995%

高可用的架构设计

怎么实现高可用？

冗余 + 故障转移

系统要达到高可用，一定要做好软硬件的冗余，消除单点故障（SPOF）。

冗余 是高可用的基础，一般，系统投入的硬件资源越多，冗余也就越多，系统可用

性也就越高。

故障转移处理就是 在最短的时间内发现故障，然后把业务切换到冗余的资源上。

高可用架构设计的类型：

• 无状态服务高可用设计
• 数据库高可用架构设计

无状态服务高可用设计

无状态的服务高可用设计非常简单，返现问题直接转移就行，甚至可以通过负载均衡服务，当发现有问题，直接提出故障服务器。

如：NGINX

• 上图中，当第一台 NGINX 服务器出现问题，导致服务不可用，Load Balance 负载均衡服务发现后，就直接把他剔除了。
• 二对上层用户来说，他只会在几秒内的访问出现问题，之后就 立刻恢复了。几乎没什么感觉。

数据库高可用的三大架构

所以，系统高可用设计，难点在于数据库的高可用设计：

• 数据持久化在数据库中，是有状态的服务
• 数据库的容量比较大，Failover 的时间比无状态服务的时间多；
• 一些系统，如金融，银行的数据库，会要求数据完全不能丢失，这有增加了高可用实现的难度。

从架构的角度来看，数据库的高可用也是业务的高可用，我们需要从全流程出发。

以下三种数据库的高可用不但适用于 MySQL 数据库，也适用其他的数据库。

基于数据层的数据库高可用架构

基于数据层的数据库高可用架构，就是基于数据同步技术。

当主服务器 Master 发生宕机，则故障转移到从服务器 Slave。

常见读写分离架构

如果发生宕机

• 可以发现，原先的 Slave3 从服务器提升到新主机，然后建立了新的复制拓扑架构，Slave2、Slave3 都连到新的 Master 进行同步。

• • 为了故障转移后对 Service 服务无感知，需要引入 VIP（Virtual IP）虚拟 IP 技术，当发生宕机时，VIP 也需要漂移到新的主服务器。

这个架构的难点：

• 如何保障数据的一致性；
  • MySQL 提供 无损复制技术

• 如何发现主服务器宕机；
  • 数据库高可用套件
• 故障转移逻辑的处理；

基于业务层的数据库高可用架构设计

第二种“基于业务层的数据库高可用架构设计”则完全基于业务实现，数据库只是用于存储数据。

当一台数据库主服务器不可用，业务直接写另一台数据库主服务器就可以了。

从上图看，Service 服务写入 Master1 主服务失败后，不用等待故障转移程序主从切换，而是直接把数据库写入 Master 2 主服务器。

这样看似简单高可用架构，但是符合设计的业务不多，

需要满足的条件：

• 状态可修改
• 服务写入主键可以进行跳单设计
• 查询全部依赖主键进行搜索

举例：

在电商中的订单服务，其基本逻辑就是存储电商业务中每笔订单信息，核心逻辑就是往表 Order 中插入数据：

insert into Order (o_orderkey,...) values (...);

这里的 o_orderkey 是主键。为了实现基于业务层的数据库高可用，可以在主键生成过程中加入额外的信息，比如服务器编号，这样订单的主键设计变成了：

pk = 有序 UUID -服务器编号

这样的话 ，当写入服务器编号 1 失败了，业务层就会把订单的主键修改为服务器编号 2 ，这样就实现了业务层的高可用，电商中的这种订单生成方式也称 为 跳单。

对于查询订单业务时，由于主键中包含服务器编号，那么业务知道该笔订单存储在那台服务器，就可以非常快速的陆游到指定的服务器。

融合的高可用架构设计

• “基于业务层的数据库高可用架构设计”，虽然通过跳单设计，可以实现写入业务的高可用设计。
• 但是当发生宕机时，服务器编号为 1 的订单无法查询。

融合的高可用架构设计

• 上图中，将不同编号的订单根据不同的数据库进行存放，比如服务器编号为 1 的订单存放在数据库 DB1 中，服务器编号为 2 的订单存放在数据库 DB2 中。
• 此外，这里也用到了 MySQL 复制中的部分复制技术，即左上角的主服务器仅将 DB1 中的数据同步到右上角的服务器。同理，右上角的主服务器仅将 DB2 中的数据同步到左上角的服务器。下面的两台从服务器不变，依然从原来的 MySQL 实例中同步数据。

这样做的好处：

• 在常态情况下，上面两台 MySQL 数据库是双活的，都可以有数据写入，业务性能得到极大的提升。
• 订单数据是完整的，服务器编号为 1 和为 2 的数据都在一个实例上。
• 重要的是：这样发生宕机，Service 服务的写入不受影响，写入服务器编号为 1 的订单通过跳单设计写入 DB2
• 同时，对于订单读取也不会受影响，因为数据都在一个实例上

• 

高可用总结

1. 高可用是系统所能提供无故障服务的一种能力，度量单位是几个 9；
2. 线上系统高可用目标应不低于 99.995%，否则系统频繁宕机，用户体验不好；
3. 高可用实现基础是：冗余 + 故障转移；
4. 无状态服务的高可用设计较为简单，直接故障转移或剔除就行；
5. 数据库作为有状态的服务，设计比较复杂（冗余通过复制技术实现，故障转移需要对应的高可用套件）；
6. 数据库高可用有三大架构设计，请务必牢记这几种设计。