Redis主从复制与哨兵高可用

可视化演示

通过主从复制数据同步流程、哨兵集群监控与故障检测、以及自动故障转移Leader选举三个维度，展示Redis高可用架构的完整机制。

主从架构：总店与分店的分工

老王开了家烘焙店，生意好到顾客排队到街角。他决定开两家分店，但有个规矩：配方只有总店能改，分店只负责照着配方做面包。顾客想买新口味的面包，走几步路去分店就行，不用再挤总店。这就是主从复制的朴素版本：一个主节点（Master）负责接收写请求，多个从节点（Slave）负责复制数据并提供读服务。

在 Redis 里，主从复制就是让一个节点当“主”，其余节点当“从”。主节点接收客户端的所有写命令，从节点通过复制主节点的命令流让自己的数据和主节点保持一致。于是数据有了多份副本，一台机器坏了数据还在——这就是“数据冗余”；写走主、读走从——这就是“读写分离”。配置从节点很简单，执行 REPLICAOF 主节点IP 端口 或启动时加 --replicaof 即可。拓扑上最常见的是“一主多从”，还可以做“链式复制”——从节点下面再挂从节点，减轻主节点的分发压力。

从业务视角看，读写分离的收益可以量化：写请求只走主，读请求可以分流到所有从节点，系统的读吞吐量随从节点数量线性增长：

回到烘焙店：配方本只有一本，但每个分店都能按配方烤面包，分店越多，能同时招待的客人就越多。唯一要注意的是，面包口味始终由总店决定，分店绝不能自己研发新配方——在 Redis 中，从节点默认只读，写入会被拒绝。

全量同步：第一次大搬家

第一家分店开张时，总店已有三年积累的配方。老王把整套配方装订成一本厚厚的《配方全集》，派店员整本送过去。但问题来了：装订这本书花了两小时，这两小时里总店又卖出了十几个新品种，这些没写进书里怎么办？老王让助手拿一本“备忘本”，把新配方一条条记下来，等分店收到《配方全集》，再把备忘本里的内容补传过去。

这就是 Redis 全量同步（Full Resynchronization）的完整过程。从节点第一次连接主节点，或者断线太久已经无法增量续传时，主节点会 fork 出一个子进程生成 RDB 快照；与此同时主节点照常处理写命令，并把新命令写入复制缓冲区（repl_backlog）。快照传完后，从节点把 RDB 加载进内存；紧接着主节点把缓冲区里积压的命令继续发给从节点，从节点再执行一遍，最终追上主节点的进度。

全量同步的总耗时可以拆成三段：

全量同步就像分店开张的第一课：把压箱底的配方整本搬过去。虽然搬运重，但只此一遭，之后配方同步就不再这么大动干戈了。

增量同步：对账补页

分店运营进入正轨后，老王发现每天要同步的新配方其实就几页。如果每天都重新搬一整本配方全集，太浪费了。于是老王规定：总店和分店各自记一个“配方版本号”——在 Redis 中叫复制偏移量（offset）。每次同步前先对账，缺哪几页就补哪几页，这就是增量同步（Partial Resynchronization）。

Redis 的实现是：主节点维护一个环形的复制积压缓冲区（repl_backlog），最近执行的写命令都留在这里；主从节点各自维护自己的复制偏移量。从节点断线重连后，把自己的偏移量告诉主节点，主节点一算：你想追的位置还落在我的积压缓冲区里，好办，直接从缓冲区把后续命令发给你。可如果从节点落后太多，缓冲区早被新命令覆盖了，那就只能退回全量同步。

判断能否增量同步的条件可以写成：

增量同步像分店日常对账：总店把改动的那几页配方传真过去，分店誊抄一遍，两边版本号对齐，皆大欢喜。

哨兵监控：督导的巡查

老王事业越来越大，不可能天天盯着每家分店。于是他雇了几名督导——也就是哨兵（Sentinel）。每名督导每隔几秒给总店和分店发一条“在吗？”（PING），收到“在的”（PONG）就放心了。如果连发几条都没回应，督导会在值班日志上记一笔“疑似失联”——这就是主观下线（sdown，subjectively down）。注意，单个督导的判断不一定准，可能只是网络抖动。

所以老王定下规矩：一名督导说失联不算数，必须有多名督导同时说“这家店失联了”，才算“确认失联”——这就是客观下线（odown，objectively down）。这个“多名”的阈值叫 quorum。Redis 哨兵监控的核心就是这套“先怀疑、再确认”的多数派判定逻辑：先由单个哨兵判定 sdown，再由多个哨兵共同确认 odown，最终触发故障转移。

客观下线的判定公式是：

督导的巡查不是一次定生死，而是“一个人怀疑，一群人确认”——这套机制就是为了避免网络抖动造成的误判误切。

故障转移：紧急升格新总店

总店被确认失联后，督导们要开会选一家分店来当新总店。选谁呢？老王给每家分店定了个“优先级”，数字小的优先升格；如果优先级相同，就看谁手里的配方最全，也就是复制偏移量最大；如果还相同，就比谁的编号靠前，即 RUNID 字典序小者优先。选定新总店后，督导团做三件事：通知其他分店改向新总店申请复制、把“新总店是谁”广播给所有客户端、更新自己的本地配置。这套动作就是自动故障转移（Failover）。

Redis 哨兵的选主规则可以概括为一条排序链：

故障转移让客户几乎无感：总店虽然倒了，督导团已经挂好新总店的门牌，食客们继续买面包，只有店员们知道刚刚经历了一场紧急交接。

哨兵集群：督导团协作

如果一个连锁集团只雇一名督导，这名督导自己休假或生病时，再赶上总店失联，就没人处理了。所以老王组建了督导团。督导团成员之间通过 Redis 的发布订阅（Pub/Sub）通道互相认识、交换信息。遇到重大决定——比如执行故障转移——不能由单个督导拍板，必须由督导团推选一位“团长”（Leader）来负责执行，其他人监督。

哨兵集群天然要求“多数派原则”：假如有 3 个哨兵，其中一个在分区里联系不上另外两个，它不能自作主张去切换主节点。只有在获得足够票数后，候选哨兵才能拿到故障转移的执行权。这个票数门槛既不能低于配置的 quorum，也不能低于哨兵总数的一半加一：

督导团的存在，让“监控者”自己也成为被监控对象。大家互相盯着、彼此制衡，整个系统就不会因为“某个人走神”而崩溃。

脑裂与优化：失联总店的乌龙

最让人哭笑不得的事故是：总店并没有真着火，只是门前的电话线被施工队挖断了。督导团联系不上总店，按流程选了新总店。可老总店并不知道这一切，还在正常接单、正常烤面包——顾客下订单它照收，配方改动它照记。等电话线修好，老总店发现自己已经被“革职”，这段时间独自记下的改动全部作废。这个局面就是“脑裂”（Split-Brain）：网络分区把原本的一个系统撕成了两个各自主张的部分。

Redis 用两个参数来扎紧篱笆：min-replicas-to-write 和 min-replicas-max-lag。前者要求主节点只有在至少还有 N 个从节点在线的情况下才允许写入；后者要求这些从节点的最大同步延迟不超过 M 秒。一旦网络分区导致老主节点和所有从节点断开，它就会触发“停止写入”的保护，从而大幅减少脑裂期间产生的孤儿数据：

回到烘焙店：总店一旦发现自己和所有分店失联，就要主动挂出“暂停接单”的牌子，而不是闷头烤面包。虽然会损失一点生意，但至少不会在恢复通信后面对一屋子卖不出去的面包。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""用 Python 模拟 Redis 主从复制同步与哨兵故障转移的核心流程"""import hashlib  class RedisNode:    """模拟 Redis 节点：维护数据、复制偏移量和写命令日志"""     def __init__(self, name, priority=1):        self.name = name        self.priority = priority        self.runid = hashlib.md5(name.encode()).hexdigest()[:6]        self.data = {}        self.backlog = []        self.offset = 0        self.alive = True     def write(self, key, value):        if not self.alive:            raise RuntimeError(self.name + " is down")        self.data[key] = value        self.backlog.append((key, value))        self.offset += 1     def ping(self):        return self.alive  def full_sync(master, slave):    """全量同步：把主节点数据整体拷贝给从节点"""    slave.data = dict(master.data)    slave.offset = master.offset    print("全量同步完成: %s -> %s, 数据 %d 条"          % (master.name, slave.name, len(slave.data)))  def incremental_sync(master, slave):    """增量同步：从 backlog 中补发从节点落后部分的写命令"""    missed = master.backlog[slave.offset:]    for key, value in missed:        slave.data[key] = value    slave.offset = master.offset    print("增量同步: %s 补发 %d 条命令, offset -> %d"          % (slave.name, len(missed), slave.offset))  def elect_new_master(candidates):    """哨兵选主：priority 小优先, offset 大优先, runid 小优先"""    return min(candidates, key=lambda n: (n.priority, -n.offset, n.runid))  def demo():    master = RedisNode("master", priority=1)    slave_a = RedisNode("slave-a", priority=1)    slave_b = RedisNode("slave-b", priority=2)     master.write("user:1", "alice")    master.write("user:2", "bob")     full_sync(master, slave_a)    full_sync(master, slave_b)     master.write("order:100", "item-42")    master.write("order:101", "item-99")     incremental_sync(master, slave_a)    incremental_sync(master, slave_b)    print("主从数据一致:", master.data == slave_a.data == slave_b.data)     master.alive = False    sentinel_names = ["sentinel-1", "sentinel-2", "sentinel-3"]    sdown = sum(1 for _ in sentinel_names if not master.ping())    quorum = 2    print("哨兵判定: sdown=%d, quorum=%d -> 客观下线=%s"          % (sdown, quorum, sdown >= quorum))     new_master = elect_new_master([slave_a, slave_b])    print("选出新主节点:", new_master.name)  if __name__ == "__main__":    demo()

1. slave.data = dict(master.data)模拟主节点把 RDB 快照整体拷贝给从节点，是“全量同步”的抽象表达。
2. self.backlog.append((key, value))每写一条命令都追加到日志中，等价于 Redis 的复制积压缓冲区 repl_backlog。
3. missed = master.backlog[slave.offset:]根据从节点偏移量切出缺失命令，模拟增量同步只补发落后部分。
4. key=lambda n: (n.priority, -n.offset, n.runid)用元组排序实现哨兵选主三规则：优先级小、偏移量大、RUNID 小。
5. sdown = sum(1 for _ in sentinel_names if not master.ping())模拟多个哨兵分别探测主节点，统计主观下线的人数。

常见误区

面试题