为了高效地管理大型向量索引并分散查询负载,通常会采用分片等技术。然而,分片也带来一个重要难题:托管分片的单个节点出现故障可能导致部分数据集无法访问,甚至使整个查询路径崩溃,如果处理不当。生产系统要求能够抵御硬件故障、网络问题和维护事件。因此,复制和高可用性(HA)策略变得不可或缺。复制是指在不同的物理或虚拟机上创建并维护数据的多个副本(此处为索引分片),这些机器通常位于独立故障域,如可用区(AZ)或服务器机架中。主要目标是:容错能力: 如果托管分片副本的节点发生故障,其他副本可以继续处理请求,从而避免数据丢失并尽量减少服务中断。读取可扩展性: 读取查询(如向量搜索)通常可以分散到分片的多个副本上,提高整体读取吞吐量,超越单个节点的能力。分布式向量搜索中的复制模型分布式数据库(包括许多向量数据库)中最常见的复制策略是**主从(或主-副本)**模型。工作方式: 对于每个分片,一个副本被指定为主节点。该分片的所有写入操作(插入、更新或删除向量)都必须通过主节点进行。主节点负责应用变更,然后将其传播给其从节点副本。读取操作(搜索)通常可以由主节点或任何从节点提供服务,具体取决于系统的配置和一致性要求。优点: 该模型简化了一致性管理,因为主节点为操作顺序提供了单一的事实来源。这是一种被广泛理解的模式,具有管理数据传播和故障转移的既定协议。缺点: 对于写入密集型工作负载,主节点可能成为瓶颈。检测主节点故障并提升从节点(故障转移)的过程会增加系统复杂性,并可能导致写入操作短暂不可用。digraph G { rankdir=TB; node [shape=record, style=filled, fillcolor="#dee2e6", fontname="Helvetica"]; edge [fontname="Helvetica"]; subgraph cluster_shard1 { label="分片 1"; bgcolor="#e9ecef"; fontname="Helvetica"; node [shape=record]; n1_leader [label="{<f0>主节点 (节点 A)|索引数据|写入队列}", fillcolor="#a5d8ff"]; n1_f1 [label="{<f0>从节点 (节点 B)|索引数据}", fillcolor="#ced4da"]; n1_f2 [label="{<f0>从节点 (节点 C)|索引数据}", fillcolor="#ced4da"]; } subgraph cluster_clients { label = "客户端 / 负载均衡器"; node [shape=plaintext]; client [label="搜索查询\n(读取)"]; indexer [label="索引更新\n(写入)"]; } edge [arrowhead=vee]; indexer -> n1_leader [label=" 写入"]; n1_leader -> n1_f1 [label=" 异步/同步复制"]; n1_leader -> n1_f2 [label=" 异步/同步复制"]; client -> n1_leader [label=" 读取"]; client -> n1_f1 [label=" 读取"]; client -> n1_f2 [label=" 读取"]; }一个分片在三个节点间分布的主从复制设置。写入操作发送到主节点,主节点将变更复制给从节点。读取操作可以指向任何副本。一致性权衡:数据时效性与性能复制系统中的一个重要考量是数据一致性。主节点上的更改多快能呈现在从节点上?同步复制: 主节点在向客户端确认写入操作之前,会等待法定数量(通常是全部或大多数)的从节点确认。优点: 提供强一致性。在成功写入后,读取请求保证能看到更新后的数据,无论哪个副本提供读取服务。缺点: 增加写入延迟,因为操作受限于法定数量中最慢的副本和网络往返时间。影响从节点的故障或网络分区可能导致主节点上的写入停滞,从而降低可用性。异步复制: 主节点在本地处理完写入操作后立即向客户端确认,并在后台将更改传播给从节点。优点: 提供更低的写入延迟和更高的写入可用性,因为主节点不受从节点确认的阻塞。缺点: 导致最终一致性。存在一个时间窗口(复制延迟),在此期间,从节点可能为读取请求返回旧数据。此延迟持续时间取决于网络条件和从节点负载。同步和异步复制的选择,在很大程度上取决于应用程序对潜在的旧搜索结果的容忍度,以及对低写入延迟的要求。对于需要绝对最新信息的检索增强生成(RAG)系统,同步复制可能看起来很吸引人,但性能成本可能很高。通常,对于许多LLM应用程序而言,具有低复制延迟(毫秒到秒)的最终一致性是一个可以接受的权衡。一些系统提供可调一致性,允许您指定,例如,写入必须由 $N$ 个副本中的 $k$ 个确认。实现高可用性 (HA)复制是根基,但高可用性需要机制来优雅地处理故障:故障检测: 系统需要一种可靠的方式来判断托管副本的节点是否宕机或无响应。这通常通过以下方式实现:心跳: 节点定期向彼此或中央协调器发送“我还活着”的消息。错过心跳则触发故障判定。Gossip协议: 节点与部分随机其他节点交换健康信息,使得故障信息能够在集群中迅速传播。故障转移: 当主节点发生故障时,系统必须自动:检测故障: 使用上述机制。选举新主节点: 从节点发起主节点选举协议(例如,基于Raft或Paxos共识算法,有时通过ZooKeeper或etcd等外部系统协调),以选择一个从节点成为新的主节点。被选中的从节点通常必须拥有该分片数据的最新版本。重新配置: 客户端和其他副本需要被告知新的主节点。负载均衡器必须更新其路由表。在故障转移事件期间,受影响分片的写入操作可能会短暂不可用,读取操作可能会遇到延迟增加或错误,直到新主节点完全运行并被识别。客户端逻辑(例如,带退避的重试)很重要。副本放置策略: 为最大化系统韧性,副本应策略性地放置:跨可用区 (AZ): 将副本放置在不同的物理数据中心(可用区)中,可以防止影响整个数据中心(电源、冷却、网络)的故障。跨机架: 在单个可用区内,将副本放置在不同的服务器机架中,可以防止机架级别故障(例如,机架顶部交换机故障)。反亲和性: 配置系统调度器,避免将同一分片的多个副本放置在同一物理主机上。与系统架构的整合复制和高可用性并非孤立存在。它们与以下其他组件结合:分片: 复制在每个分片内部运行。一个系统通常有多个分片,每个分片都有自己的主节点和一组从节点。负载均衡器: 负载均衡器在高可用性中扮演重要角色。它们根据健康检查将读取查询分发到健康的副本(主节点和从节点)。在故障转移期间,负载均衡器必须检测旧主节点的不健康状态并停止向其发送流量,在新主节点准备就绪后,适当地引导流量。监控: 持续监控所有副本的复制延迟、副本健康状态、故障转移事件和资源使用情况(CPU、内存、网络I/O),对于维护健康的生产系统非常重要。应为显著延迟或副本故障配置告警。实施复制会增加复杂性,但对于构建能够抵御故障并有效扩展读取流量的向量搜索系统而言必不可少。理解一致性模型之间的权衡并设计故障转移机制,是部署可靠的大规模LLM应用的重要一步。