2024年java面试--mysql(4)

小灰灰 2024-03-08 09:07 41阅读 0赞

## 系列文章目录 ##

1.  [2024年java面试（一）–spring篇][2024_java_spring]
2.  [2024年java面试（二）–spring篇][2024_java_spring 1]
3.  [2024年java面试（三）–spring篇][2024_java_spring 2]
4.  [2024年java面试（四）–spring篇][2024_java_spring 3]
5.  [2024年java面试–集合篇][2024_java]
6.  [2024年java面试–redis(1)][2024_java_redis_1]
7.  [2024年java面试–redis(2)][2024_java_redis_2]

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

#### 文章目录 ####

*  系列文章目录
 *  集群
 *   *  1、主从复制过程
     *  2、数据一致性问题
     *  3、集群架构
     *  4、故障转移和恢复
 *  锁
 *   *  分类
     *  全局锁
     *  表级锁
     *  行级锁

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

## 集群 ##

### 1、主从复制过程 ###

**MySQl主从复制：**

**原理**：将主服务器的binlog日志复制到从服务器上执行一遍，达到主从数据的一致状态。

**过程**：从库开启一个I/O线程，向主库请求Binlog日志。主节点开启一个binlog dump线程，检查自己的二进制日志，并发送给从节点；从库将接收到的数据保存到中继日志（Relay log）中，另外开启一个SQL线程，把Relay中的操作在自身机器上执行一遍

**优点：**

作为备用数据库，并且不影响业务  
可做读写分离，一个写库，一个或多个读库，在不同的服务器上，充分发挥服务器和数据库的性能，但要保证数据的一致性

**binlog记录格式**： statement、row、mixed

基于语句statement的复制、基于行row的复制、基于语句和行（mix）的复制。其中基于row的复制方式更能保证主从库数据的一致性，但日志量较大，在设置时考虑磁盘的空间问题

### 2、数据一致性问题 ###

“主从复制有延时”，这个延时期间读取从库，可能读到不一致的数据。

**缓存记录写key法：**

在cache里记录哪些记录发生过的写请求，来路由读主库还是读从库

**异步复制：**

在异步复制中，主库执行完操作后，写入binlog日志后，就返回客户端，这一动作就结束了，并不会验证从库有没有收到，完不完整，所以这样可能会造成数据的不一致。

**半同步复制：**

当主库每提交一个事务后，不会立即返回，而是等待其中一个从库接收到Binlog并成功写入Relay-log中才返回客户端，通过一份在主库的Binlog，另一份在其中一个从库的Relay-log，可以保证了数据的安全性和一致性。

**全同步复制：**

指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。

### 3、集群架构 ###

**Keepalived + VIP + MySQL 主从/双主**

当写节点 Master db1 出现故障时，由 MMM Monitor 或 Keepalived 触发切换脚本，将 VIP 漂移到可用的 Master db2 上。当出现网络抖动或网络分区时，MMM Monitor 会误判，严重时来回切换写 VIP 导致集群双写，当数据复制延迟时，应用程序会出现数据错乱或数据冲突的故障。有效避免单点失效的架构就是采用共享存储，单点故障切换可以通过分布式哨兵系统监控。

![在这里插入图片描述][72904df52c7946faae32beca2bec8285.png]  
**架构选型**： MMM 集群 -> MHA集群 -> MHA+Arksentinel。  
![在这里插入图片描述][21882011962440f59b21906a7e462634.png]

### 4、故障转移和恢复 ###

**转移方式及恢复方法**

1. 虚拟IP或DNS服务 （Keepalived +VIP/DNS  和 MMM 架构）

问题：在虚拟 IP 运维过程中，刷新ARP过程中有时会出现一个 VIP 绑定在多台服务器同时提供连接的问题。这也是为什么要避免使用 Keepalived+VIP 和 MMM 架构的原因之一，因为它处理不了这类问题而导致集群多点写入。

2. 提升备库为主库（MHA、QMHA）

尝试将原 Master 设置 read\_only 为 on，避免集群多点写入。借助 binlog server 保留 Master 的 Binlog；当出现数据延迟时，再提升 Slave 为新 Master 之前需要进行数据补齐，否则会丢失数据。

## 锁 ##

### 分类 ###

MySQL中的锁，按照锁的粒度分，分为以下三类:

1.  全局锁:锁定数据库中的所有表。
2.  表级锁:每次操作锁住整张表。
3.  行级锁:每次操作锁住对应的行数据。

### 全局锁 ###

全局锁就是对整个数据库实例加锁，加锁后整个实例就处于只读状态，后续的DML的写语句，DDL语句，已经更新操作的事务提交语句都将被阻塞。

其典型的使用场景是做全库的逻辑备份，对所有的表进行锁定，从而获取一致性视图，保证数据的完整性。

### 表级锁 ###

表级锁，每次操作锁住整张表。锁定粒度大，发生锁冲突的概率最高，并发度最低。应用在MyISAM、InnoDB、BDB等存储引擎中。

对于表级锁，主要分为以下三类:

**1.表锁**  
对于表锁，分为两类:

1.  表共享读锁( read lock)：读锁不会阻塞其他客户端的读，但是会阻塞写
2.  表独占写锁（write lock )：写锁既会阻塞其他客户端的读，又会阻塞其他客户端的写

语法:

1.  加锁:lock tables表名… read/write。
2.  释放锁: unlock tables /客户端断开连接。

**2.元数据锁( meta data lock,MDL)**

MDL加锁过程是系统自动控制，无需显式使用，在访问一张表的时候会自动加上。MDL锁主要作用是维护表元数据的数据一致性，在表上有活动事务的时候，不可以对元数据进行写入操作。为了避免DML与DDL冲突，保证读写的正确性。

在MySQL5.5中引入了MDL，当对一张表进行增删改查的时候，加MDL读锁(共享);当对表结构进行变更操作的时候，加MDL写锁(排他)。

![在这里插入图片描述][ab46a37061e54d9891532720a9a65e5b.png]

**3.意向锁**  
1．意向共享锁（lS）:与表锁共享锁(read）兼容，与表锁排它锁（write)互斥。

2．意向排他锁（IX)∶与表锁共享锁( read)及排它锁(write)都互斥。意向锁之间不会互斥。

### 行级锁 ###

行级锁，每次操作锁住对应的行数据。锁定粒度最小，发生锁冲突的概率最低，并发度最高。应用在lnnoDB存储引擎中。  
InnoDB的数据是基于索引组织的，行锁是通过对索引上的索引项加锁来实现的，而不是对记录加的锁。对于行级锁，主要分为以下三类:

\*\*1.行锁(Record Lock)\*\*∶锁定单个行记录的锁，防止其他事务对此行进行update和delete。在RC、RR隔离级别下都支持。

lnnoDB实现了以下两种类型的行锁:

1．共享锁(S）∶允许一个事务去读一行，阻止其他事务获得相同数据集的排它锁。

2．排他锁（X)∶允许获取排他锁的事务更新数据，阻止其他事务获得相同数据集的共享锁和排他锁。  
默认情况下，InnoDB在REPEATABLE READ事务隔离级别运行，InnoDB使用next-key锁进行搜索和索引扫描，以防止幻读。

1.  针对唯一索引进行检索时，对已存在的记录进行等值匹配时，将会自动优化为行锁。
2.  InnoDB的行锁是针对于索引加的锁，不通过g引条件检索数据，那么InnoDB将对表中的所有记录加锁，此时就会升级为表锁。

![在这里插入图片描述][1ec0cb3edeab4d30a395099210689577.png]  
![在这里插入图片描述][1dd7552c4b1c4bd6ab15c8ff552631ae.png]

**2.间隙锁(Gap Lock)**:锁定索引记录间隙（(不含该记录），确保索引记录间隙不变，防止其他事务在这个间隙进行insert，产生幻读。在RR隔离级别下都支持。

\*\*3.临键锁(Next-Key Lock)\*\*∶行锁和间隙锁组合，同时锁住数据，并锁住数据前面的间隙Gap。在RR隔离级别下支持。  
默认情况下，InnoDB在REPEATABLE READ事务隔离级别运行，InnoDB使用next-key锁进行搜索和索引扫描，以防止幻读。

1.  索引上的等值查询(唯一索引)，给不存在的记录加锁时,优化为间隙锁。
2.  索引上的等值查询(普通索引)，向右遍历时最后一个值不满足查询需求时，next-key lock退化为间隙锁。
3.  索引上的范围查询(唯一索引)–会访问到不满足条件的第一个值为止。

[2024_java_spring]: https://blog.csdn.net/weixin_43228814/article/details/132514449?spm=1001.2014.3001.5502
[2024_java_spring 1]: https://blog.csdn.net/weixin_43228814/article/details/132521303?spm=1001.2014.3001.5502
[2024_java_spring 2]: https://blog.csdn.net/weixin_43228814/article/details/132524089?spm=1001.2014.3001.5502
[2024_java_spring 3]: https://blog.csdn.net/weixin_43228814/article/details/132525745?spm=1001.2014.3001.5502
[2024_java]: https://blog.csdn.net/weixin_43228814/article/details/132548267?spm=1001.2014.3001.5502
[2024_java_redis_1]: https://blog.csdn.net/weixin_43228814/article/details/132575813?spm=1001.2014.3001.5502
[2024_java_redis_2]: https://blog.csdn.net/weixin_43228814/article/details/132590649?spm=1001.2014.3001.5502
[72904df52c7946faae32beca2bec8285.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/fe06abe3a6014472a1d3f4f97f26259b.png
[21882011962440f59b21906a7e462634.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/f675a93c7760422cbb42859ccdc4ffd3.png
[ab46a37061e54d9891532720a9a65e5b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/287512c97ebb4dac955f81203b169d65.png
[1ec0cb3edeab4d30a395099210689577.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/b05ea66e0f564e1f818776df9230d540.png
[1dd7552c4b1c4bd6ab15c8ff552631ae.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/08/6271775ddad54a3ead500e0e9bf66f7b.png