高可用

一、引子：单机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集群（数据分片） 核心问题：单机内存有限，垂直扩展有上限，需要水平扩展。 ...

引言 主从复制虽然实现了数据备份，但主节点宕机后需要手动切换。哨兵（Sentinel）提供了自动故障检测和故障转移能力，实现真正的高可用。 一、哨兵概述 1.1 什么是哨兵？ 监控 ↓ [哨兵1] ←→ [哨兵2] ←→ [哨兵3] (多个哨兵相互通信) ↓ ↓ ↓ 监控 监控 监控 ↓ ↓ ↓ [主节点] ← [从节点1] ← [从节点2] 功能： 1. 监控：检查主从节点是否正常 2. 通知：故障通知管理员 3. 故障转移：自动提升从节点为主节点 4. 配置中心：客户端通过哨兵发现主节点 1.2 核心功能 监控（Monitoring） 检查主从节点健康状态 周期性发送PING命令 故障检测（Failure Detection） 主观下线（SDOWN）：单个哨兵判断 客观下线（ODOWN）：多数哨兵同意 自动故障转移（Failover） 选举领导者哨兵 选择新主节点 通知从节点切换 通知客户端 配置中心（Configuration Provider） 客户端从哨兵获取主节点地址 主节点变更自动通知客户端 二、哨兵部署 2.1 最小配置 # sentinel.conf port 26379 sentinel monitor mymaster 127.0.0.1 6379 2 # 2个哨兵同意才判定下线 sentinel down-after-milliseconds mymaster 5000 # 5秒无响应判断下线 sentinel failover-timeout mymaster 180000 # 故障转移超时时间 sentinel parallel-syncs mymaster 1 # 同时同步的从节点数量 2.2 启动哨兵 # 方式1： redis-sentinel sentinel.conf # 方式2： redis-server sentinel.conf --sentinel # 查看哨兵状态 127.0.0.1:26379> SENTINEL masters 127.0.0.1:26379> SENTINEL slaves mymaster 127.0.0.1:26379> SENTINEL sentinels mymaster 2.3 推荐部署架构 机器1：Redis Master + Sentinel1 机器2：Redis Slave1 + Sentinel2 机器3：Redis Slave2 + Sentinel3 好处： - 3个哨兵互相监控，防止误判 - 分布式部署，避免单点故障 三、故障检测机制 3.1 主观下线（SDOWN） 哨兵1每秒向主节点发送PING： PING → 主节点 PING → 主节点 PING → (超时5秒无响应) 判断：主节点主观下线（SDOWN） 配置： ...

引言 单个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） 触发时机： ...