13. 线程调度

分手后的思念是犯贱 2022-08-05 07:27 132阅读 0赞

### 集群 高可用 高并发常见架构方案 ###

*  1-数据库高可用架构
 *  2-主从/主主半同步复制
 *   *  2.1-架构图
     *  2.2-优点
     *  2.3-缺点
 *  3-半同步复制优化
 *   *  3.1-双通道复制
     *  3.2-binlog 文件服务器
     *  3.3-优点
     *  3.4-缺点
 *  4-高可用架构优化
 *   *  4.1-MHA + 多节点集群
     *   *  4.1.1-优点
         *  4.1.3-缺点
     *  4.2-zookeeper + proxy
     *   *  4.2.1-优点
         *  4.2.2-缺点
 *  5-共享存储
 *   *  5.1-SAN 共享储存
     *   *  5.1.1架构图
         *  5.1.2-优点
         *  5.1.3-缺点
     *  5.2-DRBD 磁盘复制
     *   *  5.2.1-架构图
         *  5.2.2-优点
         *  5.2.3-缺点
 *  6-分布式协议
 *   *  6.1-MySQL cluster
     *   *  6.1.1-优点
         *  6.1.2-缺点
     *  6.2-Galera
     *   *  6.2.1-架构图
         *  6.2.2-优点
         *  6.2.3-缺点
     *  6.3-POAXS
     *   *  6.3.1-架构图
         *  6.3.2-优点
         *  6.3.3-缺点
 *  7-总结

--------------------

# 1-数据库高可用架构 #

在`MySQL`**数据库高可用架构**时，主要考虑以下几个方面：

*  如果数据库发生了宕机或者意外中断等故障，能尽快恢复数据库的可用性，尽可能的减少停机时间，**保证业务不会因为数据库的故障而中断**。
 *  用作备份、只读副本等功能的非主节点的数据应该和主节点的**数据实时或者最终保持一致**。
 *  因业务发生数据库切换时，切换前后的数据库内容应当一致，**不会因为数据缺失或者数据不一致而影响业务**。

关于**高可用的分级**不做详细的讨论，这里只讨论常用**高可用方案的优缺点以及高可用方案的选型**。

--------------------

# 2-主从/主主半同步复制 #

*  使用双节点数据库，搭建单向或双向的半同步复制。在`MySQL 5.7`以后的版本中，由于`lossless`、`replication`、`logical`多线程复制等一些列新特性的引入，使得`MySQL`原生半同步复制更加可靠。
 *  通常和`proxy`、`keepalived`等第三方软件同时使用，即可以用来监控数据库的健康，又可以执行一系列管理命令。如果主库发生故障，切换到备库后仍然可以继续使用数据库。

## 2.1-架构图 ##

![在这里插入图片描述][20190722171111604.jpg]

## 2.2-优点 ##

*  架构比较简单，使用原生半同步复制作为数据同步的依据。
 *  双节点：没有主机宕机后的选主问题，直接切换即可。
 *  双节点：需求资源少、部署简单。

## 2.3-缺点 ##

*  完全依赖于半同步复制，如果半同步复制退化为异步复制，数据一致性无法得到保证。
 *  需要额外考虑`proxy`、`keepalived`的高可用机制。

--------------------

# 3-半同步复制优化 #

*  半同步复制机制是可靠的，如果半同步复制一直是生效的，那么便可以认为数据是一致的。但是由于网络波动等一些客观原因，导致半同步复制发生超时而切换为异步复制，那么这时便不能保证数据的一致性。所以尽可能的保证半同步复制，便可提高数据的一致性。
 *  该方案同样使用双节点架构，但是在原有半同复制的基础上做了功能上的优化，使半同步复制的机制变得更加可靠。

## 3.1-双通道复制 ##

半同步复制由于发生超时后，复制断开，当再次建立起复制时，同时建立两条通道：

*  其中一条半同步复制通道从当前位置开始复制，保证从机知道当前主机执行的进度。
 *  另外一条异步复制通道开始追补从机落后的数据。
 *  当异步复制通道追赶到半同步复制的起始位置时，恢复半同步复制。

**架构图：**  
![在这里插入图片描述][20190722171145475.jpg]

## 3.2-binlog 文件服务器 ##

*  **搭建两条半同步复制通道**：其中连接文件服务器的半同步通道正常情况下不启用，当主从的半同步复制发生网络问题退化后，启动与文件服务器的半同步复制通道。当主从半同步复制恢复后，关闭与文件服务器的半同步复制通道。

**架构图：**  
![在这里插入图片描述][20190722171149989.jpg]

## 3.3-优点 ##

*  双节点、需求资源少、部署简单。
 *  架构简单、没有选主的问题、直接切换即可。
 *  相比于原生复制，优化后的半同步复制更能保证数据的一致性。

## 3.4-缺点 ##

*  需要修改内核源码或者使用`MySQL`通信协议，需对源码有一定的了解，并能做一定程度的二次开发。
 *  依旧依赖于半同步复制，没有从根本上解决数据一致性问题。

--------------------

# 4-高可用架构优化 #

*  将双节点数据库扩展到多节点数据库，或者多节点数据库集群。可以根据自己的需要选择一主两从、一主多从或者多主多从的集群。
 *  由于半同步复制，存在接收到一个从机的成功应答即认为半同步复制成功的特性，所以多从半同步复制的可靠性要优于单从半同步复制的可靠性。并且多节点同时宕机的几率也要小于单节点宕机的几率，所以多节点架构在一定程度上可以认为高可用性是好于双节点架构。
 *  但是由于数据库数量较多，所以需要数据库管理软件来保证数据库的可维护性。可以选择`MMM`、`MHA`或者各个版本的`proxy`等等。

## 4.1-MHA + 多节点集群 ##

*  `MHA Manager`会定时探测集群中的`master`节点，当`master`出现故障时，它可以自动将最新数据的`slave`提升为新的`master`，然后将所有其他的`slave`重新指向新的`master`，整个故障转移过程对应用程序完全透明。
 *  `MHA Node`运行在每台`MySQL`服务器上，主要作用是切换时处理二进制日志，确保切换尽量少丢数据。  
    ![在这里插入图片描述][20190722171203753.jpg]  
    **`MHA`也可以扩展到如下的多节点集群：**  
    ![在这里插入图片描述][2019072217121547.jpg]

### 4.1.1-优点 ###

*  可以进行故障的自动检测和转移。
 *  可扩展性较好，可以根据需要扩展MySQL的节点数量和结构。
 *  相比于双节点的MySQL复制，三节点/多节点的MySQL发生不可用的概率更低。

### 4.1.3-缺点 ###

*  至少需要三节点，相对于双节点需要更多的资源。
 *  逻辑较为复杂，发生故障后排查问题，定位问题更加困难。
 *  数据一致性仍然靠原生半同步复制保证，仍然存在数据不一致的风险。
 *  可能因为网络分区发生脑裂现象。

## 4.2-zookeeper + proxy ##

`zookeeper`使用分布式算法保证集群数据的一致性，使用`zookeeper`可以有效的保证`proxy`的高可用性，可以较好的避免网络分区现象的产生。  
![在这里插入图片描述][20190722171228365.jpg]

### 4.2.1-优点 ###

*  较好的保证了整个系统的高可用性，包括`proxy`、`MySQL`。
 *  扩展性较好，可以扩展为大规模集群。

### 4.2.2-缺点 ###

*  数据一致性仍然依赖于原生的`MySQL`半同步复制。
 *  引入`zookeeper`，整个系统的逻辑变得更加复杂。

--------------------

# 5-共享存储 #

共享存储实现了数据库服务器和存储设备的解耦，不同数据库之间的数据同步不再依赖于MySQL的原生复制功能，而是通过磁盘数据同步的手段，来保证数据的一致性。

## 5.1-SAN 共享储存 ##

*  `SAN`的概念是允许存储设备和处理器（服务器）之间建立直接的高速网络（与`LAN`相比）连接，通过这种连接实现数据的集中式存储。
 *  使用共享存储时，`MySQL`服务器能够正常挂载文件系统并操作。如果主库发生宕机，备库可以挂载相同的文件系统，保证主库和备库使用相同的数据。

### 5.1.1架构图 ###

![在这里插入图片描述][20190722171243984.jpg]

### 5.1.2-优点 ###

*  两节点即可、部署简单、切换逻辑简单。
 *  很好的保证数据的强一致性。
 *  不会因为`MySQL`的逻辑错误发生数据不一致的情况。

### 5.1.3-缺点 ###

*  需要考虑共享存储的高可用。
 *  价格昂贵。

## 5.2-DRBD 磁盘复制 ##

*  `DRBD`是一种基于软件、基于网络的块复制存储解决方案，主要用于对服务器之间的磁盘、分区、逻辑卷等进行数据镜像。当用户将数据写入本地磁盘时，还会将数据发送到网络中另一台主机的磁盘上，这样的本地主机（主节点）与远程主机（备节点）的数据就可以保证实时同步。
 *  当本地主机出现问题，远程主机上还保留着一份相同的数据，可以继续使用，保证了数据的安全。
 *  `DRBD`是`linux`内核模块实现的快级别的同步复制技术，可以与`SAN`达到相同的共享存储效果。

### 5.2.1-架构图 ###

![在这里插入图片描述][2019072217124923.jpg]

### 5.2.2-优点 ###

*  两节点即可、部署简单、切换逻辑简单。
 *  相比于`SAN`储存网络，价格低廉。
 *  保证数据的强一致性。

### 5.2.3-缺点 ###

*  对`IO`性能影响较大。
 *  从库不提供读操作。

--------------------

# 6-分布式协议 #

分布式协议可以很好解决数据一致性问题。

## 6.1-MySQL cluster ##

`MySQL cluster`是官方集群的部署方案，通过使用`NDB`存储引擎实时备份冗余数据，实现数据库的高可用性和数据一致性。  
![在这里插入图片描述][20190722171255347.jpg]

### 6.1.1-优点 ###

*  全部使用官方组件，不依赖于第三方软件。
 *  可以实现数据的强一致性。

### 6.1.2-缺点 ###

*  国内使用的较少。
 *  配置较复杂，需要使用`NDB`储存引擎，与`MySQL`常规引擎存在一定差异。
 *  至少三节点。

## 6.2-Galera ##

基于`Galera`的`MySQL`高可用集群，是多主数据同步的`MySQL`集群解决方案。使用简单，没有单点故障，可用性高。

### 6.2.1-架构图 ###

![在这里插入图片描述][20190722171307575.jpg]

### 6.2.2-优点 ###

*  多主写入、无延迟复制、能保证数据强一致性。
 *  有成熟的社区、有互联网公司在大规模的使用。
 *  自动故障转移、自动添加、剔除节点。

### 6.2.3-缺点 ###

*  需要为原生`MySQL`节点打`wsrep`补丁。
 *  只支持`innodb`储存引擎。
 *  至少三节点。

## 6.3-POAXS ##

`Paxos`算法解决的问题是一个分布式系统如何就某个值（决议）达成一致。这个算法被认为是同类算法中最有效的。`Paxos`与`MySQ`L相结合可以实现在分布式的`MySQL`数据的强一致性。

### 6.3.1-架构图 ###

![在这里插入图片描述][20190722171312937.jpg]

### 6.3.2-优点 ###

*  多主写入、无延迟复制、能保证数据强一致性。
 *  有成熟理论基础。
 *  自动故障转移、自动添加、剔除节点。

### 6.3.3-缺点 ###

*  只支持`innodb`储存引擎。
 *  至少三节点。

--------------------

# 7-总结 #

*  随着人们对数据一致性的要求不断的提高，越来越多的方法被尝试用来解决分布式数据一致性的问题，如`MySQL`自身的优化、`MySQL`集群架构的优化、`Paxos`、`Raft`、`2PC`算法的引入等等。
 *  而使用分布式算法用来解决`MySQL`数据库数据一致性的问题的方法，也越来越被人们所接受，一系列成熟的产品如`PhxSQL`、`MariaDB`、`Galera Cluster`、`Percona XtraDB Cluster`等越来越多的被大规模使用。
 *  随着官方`MySQL Group Replication`的`GA`，使用分布式协议来解决数据一致性问题已经成为了主流的方向。期望越来越多优秀的解决方案被提出，`MySQL`高可用问题可以被更好的解决。

[20190722171111604.jpg]: /images/20220805/77c2111dc9634ae6b814c3a76d7eeea7.png
[20190722171145475.jpg]: /images/20220805/58ce2a2aa3f24867b7de552d941496a9.png
[20190722171149989.jpg]: /images/20220805/50a6ba4aa1594a55896aef3d4ff962e4.png
[20190722171203753.jpg]: /images/20220805/0775cbea9a424dc4872709c5e189fd64.png
[2019072217121547.jpg]: /images/20220805/08b00f4d483c40989ccc2f7d8cd9b92d.png
[20190722171228365.jpg]: /images/20220805/f05975a5cf4e4d8fae8fa5e20be377d7.png
[20190722171243984.jpg]: /images/20220805/70bdcc58b53e4fe5bd2f023686d576f0.png
[2019072217124923.jpg]: /images/20220805/c6d540bc84384e91a01de57dedf9d265.png
[20190722171255347.jpg]: /images/20220805/5ccf04a10b994d35a3772514207dbc4b.png
[20190722171307575.jpg]: /images/20220805/92b7b35d528d441bb711abb7261f3d82.png
[20190722171312937.jpg]: /images/20220805/908d7b0784234c33a3c45dcd8eac3803.png