38.1.4 搜索引擎架构Elasticsearch/Solr：搜索引擎高可用与容灾设计

可视化演示

模拟Elasticsearch分片副本架构、节点故障检测与Quorum投票、跨机房主备容灾切换过程，展示搜索引擎高可用机制。

可用性度量——水厂立下的“军令状”

水务局每年年初都会公布一项承诺：“本年度供水保障率不低于 99.97%”。翻译成大白话，就是一年 8760 小时里，允许停水的时间不超过约 2.6 小时。立下军令状不是为了好看，而是为了让市民、医院、工厂对供水可靠性有明确预期——承诺越硬，背后的基础设施建设就越得跟上。

搜索引擎面对用户，也要立同样的军令状，叫作 SLA（服务等级协议）。运维团队用“可用率”这个数字来度量集群的健康程度，而互联网公司常用“几个九”来分层宣传可靠性：99.9% 允许一年宕机约 8.8 小时，99.99% 约 52 分钟，99.999% 约 5 分钟。多一个九，架构成本往往要翻好几倍。

计算可用率的方法很朴素：用统计周期减去停机时间，再除以统计周期。这里的“停机时间”只统计对用户请求真正不可用的时长——节点抖动但请求仍由副本正常服务时，并不算停机。

水厂靠军令状倒逼自己修建冗余管道和备用水源；搜索团队同样靠可用率目标倒逼架构设计。指标定下来，后面讲到的副本、故障转移、灾备手段，本质上都是在为这个数字买单。

数据副本——每个街区都修两座蓄水池

一个城市哪怕只有一座水厂，就算承诺 99.97%，水泵故障的那两小时依然全城断水。解决方案很朴素：在每个街区都修蓄水池。主蓄水池检修时，备用水池立刻放水顶上；关键街区甚至会修三座池子，保证任何一座坏掉都不影响供水。

搜索引擎把这份思路搬了过来：同一份数据在多台机器上各存一份，这就是副本（replica）。在 Elasticsearch 中，原始数据叫“主分片”，它的拷贝叫“副本分片”。写请求先落到主分片，再同步给每个副本；读请求可以由主分片和副本共同分担，相当于多个蓄水池同时向用户供水。

有了副本，数据丢失的风险就像买了“多重保险”。每台机器都是独立故障的，只要任何一台上的那一份还活着，数据就还在。这里的数学关系非常漂亮。

蓄水池也不是越多越好——每多一座池子，维护成本和漏水风险都在增加。副本同理：每加一个副本，写性能要打折扣、磁盘要翻倍。生产环境中常见的是 1 主 2 副本，而不是无脑堆 10 个副本。

故障检测——巡厂工人与自动压力表

水厂怎么知道哪根管道漏了？靠两样东西：巡厂工人定时巡查，以及管网上密密麻麻的压力传感器。前者是周期性检查，后者是实时监测。两者配合，才能在水管爆裂的几分钟内发现异常。

分布式集群用的是一套类似的“巡检制度”：心跳（heartbeat）机制——每个节点周期性向其他节点发送“我还活着”的信号，就像工人定时到各巡视点打卡。如果超过超时阈值仍没收到某个节点的心跳，大家就判定它失联了。心跳间隔和超时阈值就像“巡检频率”，调得太宽松发现故障慢，调得太严格又容易误伤网络抖动的节点。

但判定是会出错的，真正危险的是脑裂（split-brain）：集群被网络分区切成两半，两边都以为对方死了，都试图继续服务。这就像两座水厂互相不知道对方存在，各自向同一片区域供水，水压混乱、数据冲突。解决脑裂靠一条铁律。

半数仲裁就是水厂调度中心的铁律：只有超过半数的水厂能互相通信时，供水系统才允许对外供水。看似保守，却保证了任何时刻集群里最多只有一方“说了算”。

故障转移——主水厂瘫了，备用水厂顶上

如果主水厂真的瘫了，市民通常不会察觉——因为调度中心早已通过阀门，在几秒钟内把供水切到了备用水厂。用户感知到的只是水压轻微波动了一下。这背后是一整套预设好的切换流程。

搜索集群的故障转移（failover）也是同一套动作。主节点失联后，集群自动执行四步：心跳超时确认故障 → 触发新主节点选举 → 将某个副本分片晋升为主分片 → 更新路由表，让新请求打到新主节点。整个过程的目标是“用户无感”，或者至少在几秒内完成。

故障转移的速度直接决定可用率。经典指标有两个：MTBF（平均无故障时间）衡量“多久坏一次”，MTTR（平均恢复时间）衡量“坏了多久能修好”。可用率可以写成两者之比。

想提高可用率有两条路：提高 MTBF（用更稳定的硬件、更严格的变更管理），或者降低 MTTR（自动化故障转移、完善的监控告警）。水厂不会追求永不爆管，而是追求爆管后 5 分钟内切换完毕——降低 MTTR 往往见效更快。

灾备架构设计——河对岸再建一座水厂

蓄水池再多，如果都建在同一座水厂的院子里，厂区停电照样全城没水。真正的城市供水会考虑极端情况：跨江、跨山，把备用水源修到物理隔离的地方。这就是“故障域”的直观含义——灾难发生的地方，不能同时覆盖主备两套系统。

搜索集群的灾备（disaster recovery）同样强调故障域隔离。同机房的不同机柜，仍共享电力、网络和建筑风险；只有跨机房、甚至跨地域部署，才能扛住“机房断电”“光缆被挖断”这类区域性灾难。常见的模式有冷备（灾备端平时不服务）、热备（灾备端实时同步、随时可切）和双活（两端同时对外服务）。

跨机房同步有同步和异步两种方式。同步复制几乎不丢数据，但写性能被跨机房网络延迟拖累；异步复制速度快，但灾难发生时可能丢一小段时间的数据。这引出一对关键指标：RTO（恢复时间目标）和RPO（恢复点目标）。

水厂在河对岸修备用水厂时，会决策“投资多少管道、多粗的管道”——这对应灾备的同步模式选择；也会对外承诺“灾害后多久恢复供水”（RTO）和“最多丢多少水”（RPO）。RPO 越小，管道就要越粗越实时，成本也越高。

数据备份恢复——应急水库与“后悔药”

即使有了副本和异地灾备，水厂还会做两件事：把历年水质数据存档建册，并在城市边缘修一座应急水库。副本是“实时备用”，应急水库则是“能回到过去”的保险——当灾难是“误操作”而非“硬件故障”时，只有历史存档能把局面拉回来。

搜索集群的应急水库叫快照（snapshot）——在某个一致的时间点，把整个集群的数据“拍照”，存到远端对象存储。它和副本最大的区别是时效性：副本实时存在，快照周期产生。如果发生“误删索引”或“全集群数据损坏”，副本也会跟着遭殃，快照是唯一的后悔药。

快照支持全量和增量两种方式：第一次做全量快照，之后每天只保存变化部分，像档案室只把新增的卷宗归档。快照还需要定期做数据校验和恢复演练，否则真到灾难时刻才发现备份是坏的，比没有备份更可怕。

应急水库也有代价：恢复要时间，而且从备份恢复的数据一定比“灾难发生那一刻”旧——这中间的差距就是 RPO 窗口。所以水厂既要修实时管道（副本），也要建应急水库（快照），两者各司其职、缺一不可。

集群扩容运维——水厂日常巡检与扩建规划

水厂不可能等爆管了才去修。它每天做水质检测，每周做管道压力测试，提前预测城市人口增长并规划新水厂。高可用不是“出事那一刻”的临场发挥，而是长期运维积累出来的系统能力。

搜索集群同样需要这种“日常功夫”。首先是监控告警：盯 CPU、内存、磁盘、查询延迟和任务队列堆积，就像盯水压表，任何指标异常都要提前预警。其次是滚动升级：版本升级时逐台摘流量、升级、回填，而不是整个集群重启，保证任意时刻至少有一个副本在正常服务。然后是容量规划：数据量只增不减，要根据增长速度推算未来需要多少节点、多少磁盘。

容量规划有一条经验公式：先算出数据总量（当前数据加未来增长预测），乘上副本份数，再除以单节点可稳定承载的量，最后预留 30% 到 50% 的冗余缓冲，防止“磁盘瞬间打满”引发分片无法分配、集群进入只读状态的雪崩。

最重要也最容易被忽视的是容灾演练——就像消防演习：故意杀掉一个节点、切断一条网络线路，观察集群能否自动恢复。演习时手忙脚乱发现问题，总比灾难发生时手忙脚乱要好。

AI 应用场景

Python 演示

import random  class Node:    """一台集群节点, 只关心自己是否存活"""    def __init__(self, name):        self.name = name        self.alive = True  class ClusterSim:    """带半数仲裁与故障转移的模拟搜索集群"""    def __init__(self, names):        self.primary = 0        self.half = len(names) // 2        self.down_rounds = 0        self.switch_count = 0        self.nodes = [Node(n) for n in names]     def quorum(self):        """半数仲裁: 存活节点必须严格超过半数"""        alive_num = sum(1 for nd in self.nodes if nd.alive)        return alive_num > self.half     def heartbeat_round(self):        """模拟一轮心跳检查, 返回本轮服务是否可用"""        if not self.quorum():            self.down_rounds += 1            return False        if not self.nodes[self.primary].alive:            self.failover()        return True     def failover(self):        """主节点失联, 从存活副本中晋升新主"""        lost = self.nodes[self.primary].name        for i, nd in enumerate(self.nodes):            if nd.alive:                self.primary = i                self.switch_count += 1                print("主节点 %s 失联, 晋升副本 %s 为新主" % (lost, nd.name))                return     def random_flip(self, rate):        """按概率随机触发节点故障或恢复"""        for nd in self.nodes:            if random.random() < rate:                nd.alive = not nd.alive  def simulate():    random.seed(7)    cluster = ClusterSim(["A", "B", "C"])    rounds = 2000    for _ in range(rounds):        cluster.random_flip(0.08)        cluster.heartbeat_round()    avail = 1 - cluster.down_rounds / rounds    print("检测轮次:", rounds)    print("不可用轮次:", cluster.down_rounds)    print("故障转移次数:", cluster.switch_count)    print("模拟可用率: %.2f%%" % (avail * 100))  if __name__ == "__main__":    simulate()

1. alive_num = sum(1 for nd in self.nodes if nd.alive)统计当前存活的节点数量，这是仲裁判断的基础。
2. return alive_num > self.half严格超过半数才允许服务，这就是正文里对抗脑裂的铁律。
3. self.down_rounds += 1记录不可用轮次，用于最后计算模拟可用率。
4. if not self.nodes[self.primary].alive: self.failover()主节点失联立即触发故障转移。
5. for i, nd in enumerate(self.nodes): if nd.alive:从存活副本中选出新主节点并晋升。
6. random.seed(7)固定随机种子，保证每次运行结果可复现，方便验证。
7. avail = 1 - cluster.down_rounds / rounds与正文完全一致的可用率公式：1 减去不可用占比。

常见误区

面试题