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
  
• 同时，对于订单读取也不会受影响，由于数据都在一个实例上
  
•        
  
  
  

高可用总结

• 高可用是体系所能提供无端障服务的一种本领，度量单元是几个 9；
  
• 线上体系高可用目的应不低于 99.995%，否则体系频仍宕机，用户体验欠好；
  
• 高可用实现根本是：冗余 + 故障转移；
  
• 无状态服务的高可用计划较为简单，直接故障转移或剔除就行；
  
• 数据库作为有状态的服务，计划比力复杂（冗余通过复制技能实现，故障转移必要对应的高可用套件）；
  
• 数据库高可用有三大架构计划，请务必牢记这几种计划。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

继续阅读请点击广告