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-02-06
MySQL 分库分表扩容方案：固定槽位 + 双写迁移
MySQL 分库分表扩容方案：固定槽位 + 双写迁移讲述链条逻辑分片与物理节点解耦 → 槽位计算与路由 → 双写迁移四阶段 → 与 Redis Cluster 对比 核心表述MySQL 分库分表扩容采用固定逻辑分片 + 映射表方案，设计思路与 Redis Cluster 类似。预先定义 1024 或 4096 个逻辑槽位（2 的幂次），通过 userId % 1024 计算槽位，然后查询配置中心的映射表找到物理数据库。逻辑分片号永远不变，扩容时只改变槽位到物理库的映射关系。 假设从 4 库扩容到 8 库，初始映射 [0-255]→DB_0、[256-511]→DB_1、[512-767]→DB_2、[768-1023]→DB_3。扩容后调整为 [0-127]→DB_0、[128-255]→DB_4、[256-383]→DB_1、[384-511]→DB_5，以此类推。旧库继续保留，只是槽位重新分配。 双写迁移四阶段： 阶段 1 - 双写期：新增数据同时写旧库（主）和新库（异步），新库写入失败则加入重试队列，后续补偿。读请求优先读新库，新库没有则降级读旧库（兜底），旧库有数据则异步...
2026-01-17
MySQL 锁机制深度解析
MySQL 锁机制深度解析一、锁的种类1.1 按加锁粒度分类1.1.1 全局锁概念 顾名思义，全局锁就是对整个数据库实例加锁。MySQL 提供了一个加全局读锁的方法，命令是 Flush tables with read lock (FTWRL)。 当你需要让整个库处于只读状态的时候，可以使用这个命令，之后其他线程的以下语句会被阻塞： 数据更新语句（数据的增删改） 数据定义语句（包括建表、修改表结构等） 更新类事务的提交语句 典型使用场景 全局锁的典型使用场景是，做全库逻辑备份。也就是把整库每个表都 select 出来存成文本。 以前有一种做法，是通过 FTWRL 确保不会有其他线程对数据库做更新，然后对整个库做备份。注意，在备份过程中整个库完全处于只读状态。 问题分析 但是让整库都只读，听上去就很危险： 如果你在主库上备份，那么在备份期间都不能执行更新，业务基本上就得停摆 如果你在从库上备份，那么备份期间从库不能执行主库同步过来的 binlog，会导致主从延迟 不加锁的话，备份系统备份的得到的库不是一个逻辑时间点，这个视图是逻辑不一致的（所以在全库逻辑备份的时候要 STW...
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-02-06
MySQL 与 Redis 数据一致性保证方案
MySQL 与 Redis 数据一致性保证方案讲述链条延迟双删问题 → 缓存击穿场景 → 热点数据三级防护 → Canal + Binlog 方案 → 最终一致性实现 核心表述MySQL 与 Redis 保证一致性的传统方案是延迟双删：先删除缓存，更新数据库，延迟 500ms 后再删除缓存。但这个方案在热点数据场景下存在缓存击穿问题：延迟期间缓存为空，大量请求同时发现缓存 MISS，全部打到数据库造成压力。 针对热点数据，我们采用三级防护体系。Level 1 使用本地缓存 Caffeine 防止 Redis 过载；Level 2 是 Redis 分布式缓存；Level 3 是数据库查询，加分布式锁 Redisson RLock 防止击穿，使用 tryLock 尝试加锁最多等待 100ms，抢到锁的线程负责查询数据库并重建缓存，其他线程等待后重试。重建缓存时设置随机过期时间防止缓存雪崩，并缓存空对象防止缓存穿透。 更优雅的方案是 Canal + Binlog。Canal Server 伪装成 MySQL Slave 订阅 Binlog，解析 INSERT/UPDATE&#...
评论
公告
欢迎来到我的博客！希望我的文章可以帮得到你
目录