殷龙飞的博客

MySQL 硬核解析专题 - 第四篇：高可用与分布式

 数据库/MySQL  1864  4 分钟

好的，以下是“MySQL 硬核解析专题”的第四篇完整内容，主题是 高可用与分布式。这一篇将带你探索 MySQL 如何在高并发、大数据量场景下保持稳定和高效，从主从复制到读写分离，再到分库分表，给你一套硬核的高可用方案。内容会深入技术细节，同时提供实战思路。让我们开始吧！

MySQL 硬核解析专题 - 第四篇：高可用与分布式

前几章我们聊了 MySQL 的架构、SQL 执行和性能优化，但单机 MySQL 总有极限：流量一上来就宕机，数据量一大就慢如龟爬。要解决这些问题，就得引入高可用（HA）和分布式方案。这一篇，我会带你拆解 MySQL 的高可用架构和分布式策略，让你的数据库扛得住“洪水猛兽”。

一、主从复制：高可用的第一步

主从复制是 MySQL 高可用的基础，通过把数据从主库同步到从库，实现读写分离和故障切换。

  1. 工作原理

    • 主库：每次写操作（INSERT、UPDATE、DELETE）生成 binlog（二进制日志），记录数据变更。
    • 从库：通过两个线程同步：
      • IO 线程：从主库拉取 binlog，存到本地 relay log（中继日志）。
      • SQL 线程：读取 relay log，执行 SQL 重放数据。
    • 异步特性：默认是异步复制，主库写完就返回，从库慢慢跟上，可能有延迟。

  2. 配置实战

    • 主库配置（my.cnf）：
      1
2
3
4

      [mysqld]
server-id=1
log_bin=mysql-bin
binlog_format=row  # 推荐 row 模式，兼容性好
    • 从库配置（my.cnf）：
      1
2
3
4

      [mysqld]
server-id=2
relay_log=relay-log
read_only=1  # 从库只读
    • 同步设置：
      1
2
3
4
5
6
7

      CHANGE MASTER TO
    MASTER_HOST='主库IP',
    MASTER_USER='repl_user',
    MASTER_PASSWORD='repl_pass',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=154;  # 从 binlog 起点开始
START SLAVE;
    • 检查状态：SHOW SLAVE STATUS\G，看 Slave_IO_Running 和 Slave_SQL_Running 是否都是 Yes，Seconds_Behind_Master 表示延迟。

  3. 硬核点

    • 延迟优化：启用并行复制（MySQL 5.7+），设置 slave_parallel_workers=4;。
    • 一致性：用半同步复制（rpl_semi_sync_master_enabled=1），主库等从库确认后再返回。

二、读写分离：分担压力的利器

主库写、从库读，把读流量分散到多个从库，是提升性能的常见手段。

  1. 实现方式

    • 应用程序层：代码里判断 SQL 类型，读走从库，写走主库。简单但改动大。
    • 中间件：用 MySQL Proxy、ProxySQL 或 MyCat，自动路由读写请求。
      • ProxySQL 配置示例：
        1
2
3
4

        INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup)
VALUES (1, 1, '^SELECT.*', 2);  # 读走从库组
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup)
VALUES (2, 1, '^(INSERT|UPDATE|DELETE).*', 1);  # 写走主库组
    • 硬核点：中间件还能做负载均衡，比如按从库延迟分配读请求。

  2. 注意事项

    • 延迟问题：异步复制可能导致从库数据滞后，读到旧数据。可以用 MASTER_POS_WAIT() 强制等待同步。
    • 从库压力：读流量太大时，加多几个从库，用 SHOW SLAVE STATUS 监控延迟。

三、分库分表：大数据量的终极解法

当单表数据量超千万、单库扛不住时，分库分表就该上场了。

  1. 垂直拆分

    • 思路：按业务模块拆表，比如 users 表拆成 user_info（基本信息）和 user_logs（行为日志）。
    • 优点：逻辑清晰，单表变小。
    • 硬核点：拆分后用视图或应用层 JOIN 整合数据。

  2. 水平拆分

    • 思路：按数据范围或哈希拆分。
      • 范围分片：按时间（如 order_2024、order_2025）或 ID 段。
      • 哈希分片：按 user_id % 4 分成 4 个表。
    • 实现：
      • 手动建表：CREATE TABLE orders_0 (...)、CREATE TABLE orders_1 (...)。
      • 中间件：MyCat、ShardingSphere 自动路由。
    • 硬核点：分片后主键用分布式 ID（如 Snowflake），避免冲突。

  3. 挑战与解法

    • 跨库 JOIN：尽量避免，若必须，用应用层拆分查询后合并。
    • 事务：分布式事务用 XA 或 TCC，但性能差，建议业务补偿。

四、高可用架构：不宕机的保障

  1. MHA（Master High Availability）

    • 作用：主库宕机时，自动切换到从库。
    • 原理：监控主库状态，宕机后选一个从库提升为主，调整其他从库同步。
    • 硬核点：部署简单，但切换有短暂中断。

  2. MySQL Cluster（NDB）

    • 作用：多主架构，所有节点可读写。
    • 细节：用 NDB 存储引擎，数据分片存储，自动同步。
    • 硬核点：适合高写场景，但配置复杂，不支持 InnoDB。

  3. 云服务：AWS RDS、阿里云 PolarDB，提供主从、自动故障转移，开箱即用。

五、实战案例

  1. 场景：电商订单表 1 亿行，查询慢，写压力大。

    • 方案：
      1. 主从复制：1 主 3 从，读走从库。
      2. 水平分表：按 order_id % 8 分 8 张表。
      3. 加索引：CREATE INDEX idx_time ON orders_n(order_time);。
    • 结果：查询从 15 秒降到 0.5 秒，写吞吐量提升 3 倍。

  2. 场景：主库宕机，业务中断。

    • 方案：部署 MHA，设置 VIP（虚拟 IP），宕机后 10 秒内切换。
    • 结果：可用性从 99% 提升到 99.9%。

结语

这一篇我们从主从复制到分库分表，再到高可用架构，拆解了 MySQL 如何应对高并发和大流量。掌握这些，你的数据库就能从“单打独斗”升级到“集群作战”。下一章我们会聊 实战案例，用真实场景串起前四篇的内容。

updatedupdated2025-03-312025-03-31

相关文章：