主从复制

一、引子：单机Redis的三大困境 假设你正在运行一个电商网站，使用单机Redis作为缓存。随着业务增长，你会遇到三个核心问题： 1.1 问题1：单点故障（可用性） 场景：双11大促，凌晨0点 00:00:00 - Redis单机宕机（内存不足OOM） 00:00:01 - 所有请求打到数据库 00:00:02 - 数据库连接池耗尽（1000个请求/秒） 00:00:03 - 数据库CPU 100% 00:00:05 - 网站503错误，用户无法下单 00:00:10 - 运维手动重启Redis 00:00:15 - Redis启动成功，但缓存为空 00:00:20 - 缓存预热中（需要10分钟） 00:10:00 - 系统恢复正常 损失： - 10分钟宕机时间 - 订单损失：10分钟 × 1000单/分钟 = 1万单 - GMV损失：1万单 × 200元/单 = 200万元 核心问题：单点故障导致系统不可用，无容灾能力。 可用性计算： 假设：Redis每月宕机1次，每次10分钟 可用性 = (30天 × 24小时 × 60分钟 - 10分钟) / (30天 × 24小时 × 60分钟) = (43200 - 10) / 43200 = 99.977% 看起来还不错？但实际上： - 1年12次宕机，累计120分钟 = 2小时 - 如果恰好在大促期间宕机，损失巨大 - 高可用系统要求：99.99%（年宕机时间 < 52分钟） 1.2 问题2：容量瓶颈（可扩展性） 场景：业务增长，数据量暴增 第1个月： - 商品数量：10万 - 缓存数据量：2GB - 单机Redis：4GB内存（够用） 第6个月： - 商品数量：100万 - 缓存数据量：20GB - 单机Redis：4GB内存（不够用！） 解决方案1：垂直扩展（加内存） - 4GB → 16GB（成本翻倍，但有上限） - 最大：512GB（成本极高，且有物理上限） 解决方案2：水平扩展（加机器） - 需要Redis集群（数据分片） 核心问题：单机内存有限，垂直扩展有上限，需要水平扩展。 ...

引言 单机MySQL的三大瓶颈： 1. 存储瓶颈：单机磁盘容量有限（TB级） 2. 并发瓶颈：单机QPS上限1-2万 3. 可用性瓶颈：单点故障，服务不可用 高可用架构的演进路径： 单机 → 主从复制 → 读写分离 → 分库分表 → 分布式数据库 ↓ ↓ ↓ ↓ ↓ 1台 1主N从 读扩展 存储扩展 NewSQL 一、主从复制：高可用的基石 1.1 主从复制原理 核心组件： 主库（Master） ↓ binlog（二进制日志） 从库（Slave） ↓ relay log（中继日志） ↓ 重放SQL 数据一致 复制流程： -- 主库操作 INSERT INTO users (name, age) VALUES ('Zhang San', 25); -- 主库写binlog -- binlog内容： -- Event_type: Query -- Query: INSERT INTO users (name, age) VALUES ('Zhang San', 25) -- 从库IO线程： -- 1. 连接主库，请求binlog -- 2. 主库binlog dump线程发送binlog -- 3. 从库IO线程写入relay log -- 从库SQL线程： -- 1. 读取relay log -- 2. 解析SQL语句 -- 3. 执行SQL：INSERT INTO users... -- 4. 完成数据同步 三个关键线程： ...

引言 单机MySQL的三大瓶颈： 1. 存储瓶颈：单机磁盘容量有限（TB级） 2. 并发瓶颈：单机QPS上限1-2万 3. 可用性瓶颈：单点故障，服务不可用 高可用架构的演进路径： 单机 → 主从复制 → 读写分离 → 分库分表 → 分布式数据库 ↓ ↓ ↓ ↓ ↓ 1台 1主N从 读扩展 存储扩展 NewSQL 一、主从复制：高可用的基石 1.1 主从复制原理 核心组件： 主库（Master） ↓ binlog（二进制日志） 从库（Slave） ↓ relay log（中继日志） ↓ 重放SQL 数据一致 复制流程： -- 主库操作 INSERT INTO users (name, age) VALUES ('Zhang San', 25); -- 主库写binlog -- binlog内容： -- Event_type: Query -- Query: INSERT INTO users (name, age) VALUES ('Zhang San', 25) -- 从库IO线程： -- 1. 连接主库，请求binlog -- 2. 主库binlog dump线程发送binlog -- 3. 从库IO线程写入relay log -- 从库SQL线程： -- 1. 读取relay log -- 2. 解析SQL语句 -- 3. 执行SQL：INSERT INTO users... -- 4. 完成数据同步 三个关键线程： ...

一、引子：单机Redis的三大困境 假设你正在运行一个电商网站，使用单机Redis作为缓存。随着业务增长，你会遇到三个核心问题： 1.1 问题1：单点故障（可用性） 场景：双11大促，凌晨0点 00:00:00 - Redis单机宕机（内存不足OOM） 00:00:01 - 所有请求打到数据库 00:00:02 - 数据库连接池耗尽（1000个请求/秒） 00:00:03 - 数据库CPU 100% 00:00:05 - 网站503错误，用户无法下单 00:00:10 - 运维手动重启Redis 00:00:15 - Redis启动成功，但缓存为空 00:00:20 - 缓存预热中（需要10分钟） 00:10:00 - 系统恢复正常 损失： - 10分钟宕机时间 - 订单损失：10分钟 × 1000单/分钟 = 1万单 - GMV损失：1万单 × 200元/单 = 200万元 核心问题：单点故障导致系统不可用，无容灾能力。 可用性计算： 假设：Redis每月宕机1次，每次10分钟 可用性 = (30天 × 24小时 × 60分钟 - 10分钟) / (30天 × 24小时 × 60分钟) = (43200 - 10) / 43200 = 99.977% 看起来还不错？但实际上： - 1年12次宕机，累计120分钟 = 2小时 - 如果恰好在大促期间宕机，损失巨大 - 高可用系统要求：99.99%（年宕机时间 < 52分钟） 1.2 问题2：容量瓶颈（可扩展性） 场景：业务增长，数据量暴增 第1个月： - 商品数量：10万 - 缓存数据量：2GB - 单机Redis：4GB内存（够用） 第6个月： - 商品数量：100万 - 缓存数据量：20GB - 单机Redis：4GB内存（不够用！） 解决方案1：垂直扩展（加内存） - 4GB → 16GB（成本翻倍，但有上限） - 最大：512GB（成本极高，且有物理上限） 解决方案2：水平扩展（加机器） - 需要Redis集群（数据分片） 核心问题：单机内存有限，垂直扩展有上限，需要水平扩展。 ...

引言 单个Redis实例存在风险：硬件故障、数据丢失、无法扩展读能力。**主从复制（Master-Slave Replication）**是Redis高可用的基础。 今天我们深入剖析Redis主从复制的实现原理。 一、主从复制概述 1.1 什么是主从复制？ 主节点（Master） 从节点（Slave1、Slave2） ↓ ↓ [写操作] SET key value [只读] GET key ↓ ↑ 自动同步数据 ───────────────────────┘ 特点： - 主节点：可读可写 - 从节点：只读（默认） - 数据自动同步：主 → 从 1.2 应用场景 读写分离：主写从读，提升读性能 数据备份：从节点作为数据备份 高可用：主节点宕机，从节点可提升为主 异地容灾：从节点部署在不同机房 二、配置主从复制 2.1 基本配置 # 从节点配置 redis-server --port 6380 --replicaof 127.0.0.1 6379 # 或修改redis.conf replicaof 127.0.0.1 6379 # 指定主节点 2.2 运行时配置 # 从节点执行 127.0.0.1:6380> REPLICAOF 127.0.0.1 6379 OK # 取消复制 127.0.0.1:6380> REPLICAOF NO ONE OK # 变为独立节点 2.3 查看复制状态 # 主节点 127.0.0.1:6379> INFO replication role:master connected_slaves:2 slave0:ip=127.0.0.1,port=6380,state=online,offset=1234 slave1:ip=127.0.0.1,port=6381,state=online,offset=1234 # 从节点 127.0.0.1:6380> INFO replication role:slave master_host:127.0.0.1 master_port:6379 master_link_status:up 三、复制流程 3.1 全量复制（Full Resynchronization） 触发时机： ...