当前位置：首页 > news >正文

「腾讯云NoSQL」技术之向量数据库篇：自研分布式向量数据库，实现毫秒级时序一致备份的挑战和实践

news 2025/11/11 9:42:20

随着AIGC和大模型的浪潮席卷全球，向量数据库作为处理和检索海量非结构化数据的核心引擎，其重要性日益凸显。为了确保数据的多副本容灾和一致性，数据库普遍采用成熟的Raft协议来构建多副本架构，通过Raft协议和高可靠的云盘，数据被复制成三份甚至更多，似乎已经构筑了一套完备的数据的读写和基本的容灾能力，然而，这样的高可用架构真的就万无一失了吗？

当人为的误删除、程序Bug的致命一击发生时，这些“错误”操作也会被忠实地同步到所有副本，导致数据瞬间灰飞烟灭——此时我们才意识到，仅靠多副本远不足够，那么，我们应该如何在海量分片间保证数据的一致性快照？

基于以上痛点，腾讯云NoSQL团队自研了完整的备份恢复功能，解决了分布式架构下数据与元数据的动态一致性难题，构建了一套对业务影响极低的精确时间点备份恢复系统。从功能设计到发布后，整体未发生过一起数据故障和间接引发的宕机故障。腾讯云NoSQL团队是如何做到这一点的？本文将带你一探究竟。

1 自研数据库中备份各类问题与挑战

1.1 Raft+云盘多副本，难道还不够？

TencentVDB源自PCG的OLAMA平台，并持续共建开发，该平台的构建的基础架构与众多数据库类似，基于Raft协议来确保数据的多副本容灾和一致性，如下图所示：

如上所示，VDB从数据面将1个collection划分为1-N个shard（分片）放在Worker0-N中对客户直接进行访问服务，每个shard是一个raft组，或者说每个shard是1个leader多个Follower。VDB管理面（Master）是对元数据的管理，采用1Leader+4Follower的方式来确保元数据的可靠性。

按照raft协议的基本逻辑，数据的读写和基本的容灾能力是具备的：

多数派写入成功则会认为成功，如果是1主2从，2个节点写入成功则认为成功，那么在其中任意一个节点出现意外宕机或主动运维重启过程中不会引发读写异常。
任何一份数据损坏都可以恢复，因为最少2份数据是完整的，所以即使是Leader数据盘损坏也依然可以确保数据不丢失。
3份数据最终是一致的，虽然写入是多数派成功认为成功，但依旧会通过Raft日志确保最终3个副本的数据是一致的。
云盘本身的高可靠性，在云上部署的VDB是基于云盘来完成，云盘本身也是多可用区多副本确保9个9以的可靠性。

为什么这样的数据可靠性还不够？

上述数据的可靠更多还是偏于机机正常访问为前提下，出现宕机、运维重启、磁盘损坏、文件损坏等可能发生的数据丢失的容灾方法，但在实际运行过程中，还存在以下两类情况：

人为误（或恶意）删除，人为误删除数据、表、库的时候（甚至于将回收站清空），即使数据多个副本会被同时删除。

程序Bug，由于程序发布bug、被恶意植入执行代码等方式，导致数据和结构被删除，此时多副本依然会被同时删除。
需要克隆实例，用户因为需要对比数据、性能、版本差异，需要克隆一份某时刻的数据是一种不错的选择。

“备份恢复”成为保障客户数据的最后一道防线。向量数据库早期更聚焦于向量算法检索和工程优化。随着业务需求的快速发展，越来越多的客户将业务标量数据、原始文本内容、图片和视频地址等具备业务含义的数据放入到向量数据库中，以便于通过向量数据库获得更多更直接的非结构化数据处理。

由此客户对于向量数据库的数据可靠性要求更高，对备份恢复的客观诉求变得越发强烈，VDB内核团队基于分布式向量数据库自研了完整的向量数据库备份恢复，在这个过程中相对于传统数据库会有诸多区别和不同的技术挑战，本文将详细展开这些细节分享给大家。

1.2 相对传数据库的困难和挑战

在自研分布式向量数据库中，备份恢复机制面临以下几个关键难点：

备份恢复系统需完全自研，缺乏现成方案

与传统数据库不同，自研向量数据库无法直接沿用成熟的开源或商业备份工具，几乎从0设计和构建整套备份恢复流程，并针对向量数据的高维、相似性检索等特性做专门优化。

分布式多分片与多副本间的一致性保障

数据表会被拆分为多个分片（Shard），分散在不同节点上，每个分片又存在多个副本。在备份瞬间，需要确保所有分片及其副本在时序上保持一致，否则可能因数据状态不一致导致数据错乱。

Braft框架log中缺乏时间戳带来的恢复效果

基于默认 BRaft框架的日志中未记录时间戳，导致无法直接基于指定时间点进行恢复。VDB团队通过改写日志格式，引入时间戳来增强能力，但这又会带来新旧版本兼容性升级的挑战，这都将在本文后面逐步展开。

元数据与节点状态在备份过程中的动态一致性问题

Shard（分片）的分布、副本位置、节点 IP、角色等关键信息均由元数据库统一管理。备份过程中若元数据发生变更（如频繁新建和删除表），需确保元数据与各节点实际数据状态的一致性。而在恢复阶段，需要对元数据中的异常进行处理，由于恢复的机器IP已发生改变，也需处理对节点 IP 元信息进行依赖解耦处理，会进一步增加了实现复杂度。

2 核心技术点的落地

2.1 备份核心点：一致性与完整性

多节点数据毫秒级一致

当外部发起T0备份时，其核心目标是为恢复T0时刻的数据。然而在分布式环境中，该备份的实际执行会因网络与预处理延迟，导致以下情况：

备份时间点分散：各节点实际备份时刻并不统一，而是分布在T0之后的多个时间点。
恢复数据不一致：恢复所得的数据并非一个统一的T0时间点快照，不同节点的数据存在时间差。
中间操作状态混杂：在T0到各节点完成备份的时间窗口内，若发生CRUD操作，会导致部分节点包含了此变更，而其他节点未包含，从而引发数据状态不一致。

VDB面对上述客观问题，我们考虑的是通过上次本地快照+Raft日志的方式，确保备份时刻比发起备份的T0时刻更晚，那么就能确保恢复阶段的数据就可以通过回放到T0时刻的日志来确保时序的一致性（这里理解的基础是时钟同步的差距低于ms级）。VDB备份前和备份中会有以下行为：

VDB周期性判断，如果数据发生变化较多，对原始数据进行本地硬链接（放在RocksDB中，包含标量和向量），这个是相对T0更早的时刻，标记为：Tx1
VDB周期性判断，如果数据发生变化较多，对索引数据的进行本地快照（索引数据存放在磁盘上的文件），也是相对T0更早的时刻，标记为Tx2

Tx1是本地磁盘硬链接速度非常快速，然后再对索引数据备份开始时会先fork一份内存，在此期间会短暂阻塞写入，确保Tx1和Tx2之间数据未发生变化。

备份过程中，并对Raft日志进行硬链接处理后再进行远程备份
备份过程中，由Master记录备份的时间点是T0，以便于恢复时统一用该时刻

VDB在恢复到新实例阶段处理手段：

恢复过程禁写：设置特定状态，该阶段禁止外部写入，恢复完成后才开放

先恢复原始（RocksDB）数据：此时恢复出来的原始数据是Tx1，早于T0。

再回复索引数据（Index）数据：此时恢复出来的索引数据是Tx2，前文中提到Tx1-Tx2数据保持一致，所以索引也可以认为是Tx1时刻的索引。

通过Raft日志恢复到T0时刻：根据Master记录的T0时刻，回放Tx1-T0这个时段日志，确保各个节点的即使快照和备份时间不一致，也能最终在毫秒级达成一致。

补充：关于braft框架默认的raft log的改写：

VDB是基于braft框架来完成的，其框架本身提供的raft log并没有标志timestamp信息，而是通过类似序列号的方式来表达的。

所以VDB在完成上述备份过程中之前需要先更改整体的日志格式，而在这个过程中，会引发旧版本日志和新版本日志不兼容的情况，例如在升级过程中节点间传递raft日志，旧版本日志和新版本日志相互不兼容。为了解决这个问题，VDB做了以下处理：

新版本的代码兼容旧版本的日志，升级过程中作为Follower可以接收以前的日志。
提供升级模式状态，不影响读写，在此状态下，新版本也依然按照旧版本的日志写入，升级过程中作为Leader时可以让旧版本节点识别到日志。
在所有节点升级完成后，将状态更改为正常服务，确保全部使用新日志格式进行写入，并立即完成一份快照，以确保从此时刻起，就可以使用备份恢复。

分布式元数据状态一致

除上述数据一致外，我们还会遇到的问题是，当T0时刻发起备份后，T1时刻才真正开始备份，此时T0到T1之间用户发起了新增表、删除表、添加索引字段、删除库等行为，则会导致元数据不一致，例如：

● 恢复时元数据多了一些新增的表，但数据节点上备份的数据中没有该表

● 恢复时元数据少了一些表，导致无法恢复出来这些数据

分布式元数据状态一致

● 恢复时元数据多了一些新增的表，但数据节点上备份的数据中没有该表

● 恢复时元数据少了一些表，导致无法恢复出来这些数据

元数据是否类似数据面一样，通过快照+Raft log回放来实现？

元数据的日志是对表和库的增删改，而该行为是不可发生REDO的，例如建表再发生REDO就会报错，所以还需要采用其它的方式来完成。

为此VDB先引入了状态机，来控制管理节点（Master）来控制任务处理过程中的信息：

IDLE，日常空闲状态，不做任何控制行为
IN-PROGRESS，发起备份Maser立即修改的状态，并向所有的数据节点下发备份任务
WAITING，管理节点（Master）开始等待所有Worker节点是否收到备份，如果收到则认为下发结束，否则认为本次备份失败。

引入上述状态机后，发起备份会第一时间修改状态，此时如果外部发起对表的新增、删除、修改操作会被短期阻塞或拒绝（根据策略来决定），然后将T0时刻的元数据快照并保存，并通知各个数据节点（Worker）开始备份指定的表，进一步将进行如下处理：

快速释放锁：元数据本地快照成功后不再加锁，允许外部对表和库进行增删改操作
新增表：如果期间发生新增表操作，新增的表不会被备份（各数据节点需要备份的表已在加锁阶段确定）
新增和删除索引：该行为在VDB中不会真正去删除数据，元数据加锁阶段已被保存。
发生删除表操作：元数据会被删除，但元数据已在加锁阶段被保存快照，而数据节点的索引、原始数据、日志会暂时标记删除，外部访问不到该表。然后通过缓清理的方式（询问Master是否可以清理），使得数据在备份期间不会因为删除行为而被实际清理。

数据和日志的完整性

在数据备份的过程时，数据和日志正在写入，从内核程序角度会认为写入成功，但操作系统可能尚未刷盘（部分数据还在缓冲区中），此时进行磁盘备份的时候，会导致数据和日志的不完整，例如最后一条日志可能只有一半被刷盘。操作系统的机制无法避免，只能充分利用OS的机制，针对数据和日志做一些特殊处理，使得最终的数据是一致的：

● 数据快照阶段处理：确保数据本身在快照时是被强制刷盘的（fsync），以确保备份的快照文件在那个时刻是完整的。

● 日志实时写入处理：确保日志在备份时刻前的日志都已经被强制刷盘一次，备份时刻T0发起后，可能还会有外部请求写入数据到缓冲区未落盘，导致半条日志的情况，但那些日志是在T0时刻过后的，所以只需要对日志校验部分进行特殊处理，就可以。

2.2 丝滑体验：降低备份对业务的影响

VectorDB的备份过程中，主要有3个核心步骤：

● 本地硬链接（含上面提到的数据、索引、日志、元数据），实现本地备份

● 通过云巢团队DBS系统，间接使用CBS盘快照，实现远程备份

因此在备份过程中会几个明显的特点：

业务影响趋近0：无论是本地硬链接，还是CBS盘快照，对业务的IO影响几乎趋近0，同时几乎不占用系统的CPU和内存资源。
急速备份：
- 本地硬链接几乎在压秒级完成，在现网业务中部分运行时数据显示，对一个20TB的向量库进行备份，经过元数据加锁分发，以及所有分片日志的本地备份全部完成在20s内完成。
- CBS盘的快照在首次备份成功后，再进行快照备份，其取决于磁盘更新的量，不需要将整个磁盘的数据拷贝。

本地盘（NVMe）拷贝减少
- 将业务Raft日志依然放在CBS盘，这部分内容可能会超过数据本身的大小，确保备份时这部分数据不再从本地盘拷贝出来。
- 本地盘NVMe主要存放索引数据，将其与日志分离，可以更好的保障客户的检索服务使用磁盘时具备稳定的IOPS。
- 备份期间该数据的硬链接会被建立在本地盘并在备份时直接进行远程备份，以减少对CBS盘的写入。此时如将数据拷贝到CBS盘统一备份，可能会导致CBS盘的写入带宽被拉高，从而导致业务写入时Raft日志落盘变慢，间接导致写入变慢，极端情况下会导致整个系统的处理线程会消耗光，无法为业务提供查询服务。