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

2025-12-09 20:11 tlnshuju 阅读(0) 评论(0) 收藏举报

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

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

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

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

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

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

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

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

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

为什么这样的资料可靠性还不够？

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

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

程序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备份前和备份中会有以下行为：

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

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

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

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

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

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

再回复索引数据（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之间用户发起了新增表、删除表、添加索引字段、删除库等行为，则会导致元内容不一致，例如：

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

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

分布式元数据状态一致

，当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日志落盘变慢，间接导致写入变慢，极端情况下会导致整个框架的处理线程会消耗光，无法为业务提供查询服务。