MySQL 架构深度解析
一、主从复制
1.1 几种常见的主从复制模型
主要有三种：
1. 同步复制
性能差，可用性也差，一旦一个从库出现问题都会影响到业务
2. 异步复制（默认模型）
MySQL 主库提交事务的线程不会等待 binlog 同步完成就会返回客户端结果，一旦主机宕机，数据就会发生丢失
3. 半同步复制
MySQL 5.7 版本之后增加的一种复制方式，介于两者之间，事务线程不用等待所有的从库都完成复制，只要有一部分复制成功响应回来就行，即使主库宕机，至少还有一个从库有最新的数据，不存在数据丢失的风险。
二、分库分表
2.1 垂直分库分表
核心概念
根据不同的业务功能/模块，将数据按表结构或库结构进行拆分。
垂直分库
将不同业务模块的表拆到不同数据库中
垂直分表
将一张表中的列划分为多个子表，按字段分类存储
2.2 水平分库分表
核心概念
把相同结构的数据，按一定规则划分到多个库或表中。
水平分表
将一张表的数据行按规则拆分到多个表中
水平分库
不仅拆表，还把多个分表分布到不同数据库中
文章作者: zoloy
版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 zoloy's blog！
相关推荐
2026-01-19
Redis 高可用方案深度解析
Redis 高可用一、主从复制1.1 主从复制概述主从复制是 Redis 高可用服务最基础的保证，实现方案就选择一个服务器作为 master，其他的服务器作为 slaver，一主多从，读写分离。这里注意一下，主从服务器之间的命令复制是异步进行的，不会等到从服务器都同步完才向客户端返回结果。所以，无法实现强一致性（数据时时刻刻都是一致的），只能达到最终一致性。 实际上，Redis 提供了主从库模式，以保证数据副本的一致，主从库之间采用的是读写分离的方式： 读操作：主库、从库都可以接收 写操作：首先到主库执行，然后，主库将写操作同步给从库 1.2 主从库第一次同步先来看看主从库间的第一次同步是如何进行的，这也是 Redis 实例建立主从库模式后的规定动作。当我们启动多个 Redis 实例的时候，它们相互之间就可以通过 replicaof（Redis 5.0 之前使用 slaveof）命令形成主库和从库的关系，之后会按照三个阶段完成数据的第一次同步。 例如，现在有实例 1（ip：172.16.19.3）和实例 2（ip：172.16.19.5），我们在实例 2 上执行以下这个命令：...
2026-01-20
RocketMQ 集群高可用方案深度解析
RocketMQ 集群高可用一、故障型高可用多节点部署以便故障转移如果Broker以一个集群的方式部署，会有一个master节点和多个slave节点，消息需要从Master复制到Slave上。而消息复制的方式分为同步复制和异步复制。 同步复制： 同步复制是等Master和Slave都写入消息成功后才反馈给客户端写入成功的状态，同步复制会增大数据写入的延迟，降低系统的吞吐量。 异步复制： 异步复制是只要master写入消息成功，就反馈给客户端写入成功的状态。然后再异步的将消息复制给Slave节点在异步复制下，系统拥有较低的延迟和较高的吞吐量。但是如果master节点故障，而有些数据没有完成复制，就会造成数据丢失。 RocketMQ 的主从架构中，Master 是消息的写入和读取主节点，而 Slave 主要是复制 Master 消息，用于容灾和故障转移。 二、容量型高可用消息积压处理RocketMQ 消息积压是指 Broker 中待消费消息堆积过多，消费者消费速度跟不上生产者发送速度。 处理方法主要包括： 1️⃣ 监控队列堆积指标，及时发现问题 2️⃣ 对生产者进行流控或延迟发送，缓...
2026-01-18
MySQL 索引深度解析
MySQL 索引深度解析一、常见模型1.1 索引实现地点在 MySQL 中，索引是在存储引擎层实现的，所以并没有统一的索引标准，即不同存储引擎的索引的工作方式并不一样。（还记得前面存储引擎层实现了 undo log 的存储吗？）而即使多个存储引擎支持同一种类型的索引，其底层的实现也可能不同。 实现方式在 InnoDB 中，表都是根据主键顺序以索引的形式存放的，这种存储方式的表称为索引组织表。又因为前面我们提到的，InnoDB 使用了 B+树索引模型，所以数据都是存储在 B+树中的。 每一个索引在 InnoDB 里面对应一棵 B+树（想想 everything 先建立索引，然后再便于我们查找文件就知道了，又或者是 ES 的倒排索引，索引的目的就是加快查找速度）。 索引类型 主键索引 - 的叶子节点存的是整行数据。在 InnoDB 里，主键索引也被称为聚簇索引（clustered index） 非主键索引 - 的叶子节点内容是主键的值。在 InnoDB 里，非主键索引也被称为二级索引（secondary index） 主键索引和普通索引的查询区别根据上面的索引结构说明，我们来讨论...
2026-01-17
MySQL 存储引擎深度解析
MySQL 存储引擎深度解析一、InnoDB 架构1.1 MySQL 的数据是存放在哪的⭐ibdata1 共享表空间需要注意的是表的数据可以存储在共享表空间里面 也可以存储在独占表空间里面，这个参数由 innodb_file_per_table 控制 默认是开启的。不过实际上这个 ibdata1 文件还是存在的。 原理说明 如果启用了 innodb_file_per_table 参数，需要注意的是每张表的表空间内存放的只是数据、索引和插入缓冲 Bitmap 页，其他数据如: 回滚信息、插入缓冲索引页、系统事物信息、二次写缓冲（Double write buffer）等还是放在原来的共享表空间内。同时说明了一个问题: 即使启用了 innodb_file_per_table 参数共享表空间 ibdata1 还是会不断的增加其大小的 数据库空间占用来源数据库主要的空间占用来源于哪两部分。这里，我们还是针对 MySQL 中应用最广泛的 InnoDB 引擎展开讨论。 一个 InnoDB 表包含两部分，即：表结构定义和数据。 在 MySQL 8.0 版本以前，表结构是存在以.frm 为后缀...
2026-01-17
MySQL 各种日志深度解析
MySQL 各种日志深度解析一、Double Write（二次写）1.1 脏页刷盘的风险是什么首先介绍一下 IO 的最小单位： 数据库 IO 的最小单位是 16K（MySQL 默认，Oracle 是 8K） 文件系统 IO 的最小单位是 4K（也有 1K 的） 磁盘 IO 的最小单位是 512 字节 因此，存在 IO 写入导致 page 损坏的风险。 1.2 ⭐二次写解决了什么问题提高了 InnoDB 的可靠性，用来解决部分写失败（partial page write 页断裂）。 一个数据页的大小是 16K，假设在把内存中的脏页写到数据库的时候，写了 2K 突然掉电，也就是说前 2K 数据是新的，后 14K 是旧的，那么磁盘数据库这个数据页就是不完整的，是一个坏掉的数据页。 redo 只能加上旧、校检完整的数据页恢复一个脏块，不能修复坏掉的数据页，所以这个数据就丢失了，可能会造成数据不一致，所以需要 Double Write。 当数据库正在从内存向磁盘写一个数据页时，数据库宕机，从而导致这个页只写了部分数据，这就是部分写失效，它会导致数据丢失。这时是无法通过重做日志恢复的，因...
2026-01-18
MySQL 事务深度解析
MySQL 事务深度解析一、事务 ACID1.1 简单介绍原子性（Atomicity） 也就是说这一串指令要么全部成功 要么全部失败 这点通过 begin 事务 commit 提交 rollback 回滚实现 其实就是 undo log 实现的 一致性（Consistency） 事务操作前后，数据满足一致性的约束，不会出现中间数据的情况 通过锁来实现，是在其他三个性质之上保证的 隔离性（Isolation） 多个事务执行时不会互相干扰 通过 MVCC 机制实现的 持久性（Durability） 事务处理之后，是要落盘的，而且即使系统故障数据也不会丢失 这点通过 log 日志实现 而且还是 redo log 1.2 总结 原子性通过 Undo Log 实现，保证事务要么全部成功要么全部回滚 隔离性通过 MVCC 和锁机制实现，保证并发事务互不干扰 持久性通过 Redo Log 和 WAL 机制保证，确保事务提交后即使宕机也不会丢失 一致性是事务执行前后数据库满足业务和约束规则的最终状态，它依赖于原子性、隔离性、持久性以及应用层的正确逻辑共同保证 二、SQL 的隔...
评论
公告
欢迎来到我的博客！希望我的文章可以帮得到你
目录