图数据库集群扩容要停机吗？在线扩容与滚动升级的风险控制

图数据库集群的扩容方案批下来那天，会议纪要上写着一句「业务无感知」。两周后复盘，运维说这次扩容很顺利，监控全程绿；业务说那两天有几个接口慢了一截，只是没到报警线。两边都没说错，因为他们量的不是同一个东西：运维量的是可用性，业务量的是响应时间。

这就是图数据库集群扩容最先要澄清的一件事——「不停机」和「没影响」不是一个意思。前者是对服务是否中断的承诺，后者是对性能是否波动的描述。厂商说不停止服务，说的是前者；业务感受到的委屈，多半来自后者。

把这两件事分开之后，扩容和滚动升级的大部分风险，都能提前落到一个具体位置上，而不是笼统地归到「扩容有风险」这一类。

一、你要加的是计算节点，还是存储节点？

这个问题决定扩容是十分钟的事，还是几十个小时的事。

存算分离与 Shared-Nothing 的架构把集群分成两层：存储层是分布式键值存储，管数据分片与多副本；计算层是图查询引擎与 Meta 服务，管遍历、计算和元数据协调。两层可以独立扩。

这是它和存算一体架构最实际的差别——不只是性能上互不拖累，而是扩容时要不要搬数据这件事被拆开了。计算存储分离架构对这层机制有更完整的拆解，本节只取它对扩容的那一个推论：两层能分开扩，也就能分开扩错。

维度	计算层扩容	存储层扩容
节点状态	无状态	有状态，持有分片
加节点要做什么	注册、建连接、纳入路由	迁分片、追赶增量、切主、重分布副本
是否搬数据	不搬	要搬，且按分片逐个搬
影响面	几乎不可见	搬迁期 IO 与网络占用、跨分片查询比例上升
耗时量级	分钟级	由数据量与分片数决定，通常以小时计
回退难度	低，摘掉节点即可	高，回退等于再搬一次

判断瓶颈在哪一层，有个不需要工具的粗判法：看 CPU 与磁盘 IO 谁先打满。CPU 打满、IO 空闲，瓶颈在计算层，加 Graph 节点；IO 打满、查询进程 CPU 不高，瓶颈在存储层，加 Storage 节点；两者都不高但请求排队，多半不在容量上，回去查执行计划——这个问题后面第六节还会说一次。

扩错层的代价不难想象：加了一排计算节点，瓶颈还在存储，钱花了、机器添了，延迟曲线一动不动。反过来只扩存储不扩计算，写入吞吐上去了，多跳查询依然排队。

二、「不停机」到底意味着什么？

「不停服」的准确含义是：扩容和升级期间，集群持续接受读写请求，不出现整体不可用。它不承诺请求的处理时间不变。

不停服带来的影响有三类，都能被业务侧看见，只是时间尺度和表现形式不同。

影响	现象	成因	持续多久
延迟抖动	P99 上升，均值几乎不动	分片搬迁占用磁盘带宽与网络	搬迁进行期间
请求多一跳	少量请求延迟小幅上升，无报错	客户端仍按旧分片路由发请求，被转发一次	路由变更传播到客户端为止
新节点偏慢	扩容后几小时查询反而没变快	新节点本地缓存与索引尚未预热	随访问量自然升温

这三类里，第一类最容易被误判成「扩容把系统搞慢了」，第二类最容易被忽略——没有报错，只有一点点延迟，一周后自己好了，也就没人再查。第三类最冤：扩容本来是为了快，结果头几个小时更慢，如果这时候正好撞上业务高峰，结论就变成了「扩容没用」。

判断方法只有一条：扩容前后用同一条查询、同一批起点，比 P99，不比均值。 均值会把搬迁期的抖动抹平，也会把新节点未热的慢抹平，两头都不敏感。

还有一件必须提前确认的事：扩容期间的写入要不要限流。数据迁徙和业务写入会争抢同一批磁盘，多数产品支持搬迁限速，但限速的默认值往往按「不影响业务」以外的目标设定。这一项不写进方案，等于默认让搬迁跑满带宽。

三、分片搬迁为什么会牵动整张图？

关系型数据库扩建分库分表，本质是把一张表的数据挪个位置。图数据库搬一个分片，是把图切开一次。

差别在边上。一条边的两个端点可能落在不同分片，平时靠跨分片遍历解决；搬迁期间，原本在同一分片内的边被拆到两台机器上，跨分片遍历的比例会短时上升。这个比例的上升不会体现在报错里，只体现在延迟上。扩容是否真的成功，不看节点数有没有加上去，看跨分片查询占比有没有降下来。

还有一类点会让搬迁窗口被显著拉长。

度数极高的超级节点，它所在的分片在数据量上可能并不大，但这一片关联的边数量惊人，搬迁时搬的是边，不是点。一个分片里混进几个这样的点，整个搬迁进度条就会卡在那一段不动，看起来像挂了，实际在搬边。单点瓶颈在千亿规模下的其他表现，千亿点边图谱建设，原生分布式图数据库如何避免单点瓶颈有更系统的讨论，本篇只取它在搬迁期露出来的那一面。

副本与主的关系是第二个容易被忽略的地方。搬迁完成指的是分片落在新节点上了，但分片的主副本分布会随之变化，热点也跟着换位置。有的方案在搬迁结束后会做一次均衡，这次均衡同样消耗资源，而且它发生在「扩容已完成」的通报之后——这就是为什么扩容结束两三天后才出现的延迟上升，往往查不到原因。

四、滚动升级的风险，为什么集中在混合版本期？

滚动升级的流程本身不难：逐个节点停进程、换版本、启动、健康检查通过，再处理下一个。停机时间被压缩到单个节点重启的量级，业务侧看到的是连接重连，不是服务中断。

风险不在单个节点的重启，在混合版本期——集群里同时跑着两个版本的进程，这段时间的长度等于节点数乘以单节点重启与健康检查时间，串行执行，一个都不能跳。

混合版本期的三个风险点：

风险	具体表现	判断方式
数据格式的向前兼容边界	新版本写入的数据，旧版本读不懂或读错	查版本兼容矩阵，确认读写两个方向
元数据变更的传播	新版本 Meta 下发的结构，旧版本 Graph 不认	看是否声明「混合版本可运行」
查询计划行为漂移	同一句查询，升级后走了不同的执行路径	升级前后各存一份执行计划对比

第一条是最硬的边界。多数产品能保证旧数据新版本读得懂（向后兼容），但不一定保证新数据旧版本读得懂（向前兼容）。滚动升级期间，如果新节点已经开始接收写入，而旧节点还在服务读请求，向前兼容就成了硬要求。这一条不清楚，就只能退化成停机升级。

顺序也不能混。一般先升 Meta，再升计算与存储节点，两类角色不并行。反过来先升查询引擎、Meta 还是旧版本，新引擎拿到的元数据格式可能对不上，症状是启动即失败或者部分查询报错，比慢更麻烦。

回退这件事要提前想清楚。滚动升级的回退不是「卸了新版本装回旧版本」这么简单：新版本一旦写入过数据，旧版本进程可能读不了，回退就退化成一次数据恢复，耗时从分钟变成小时。

所以方案里必须写明两件事之一：升级期间关闭写入，或者升级前做一次快照。前者把不停服换成一段短暂停写，后者多花一次备份的时间与空间。两样都不做，「可回退」这三个字在混合版本期里其实是空的——你没有退路，只是当时没意识到。

判断一款图数据库产品支不支持真正的滚动升级，看三件事就够了：有没有公开的版本兼容矩阵、有没有明确声明混合版本期可运行、有没有降级路径（回退是否需要清数据重导）。三样缺一样，这份「支持滚动升级」就要打个折。

五、扩容做完，怎么验它真的成了？

扩容的验收标准不是「节点起来了、监控绿了」。那只能证明进程活着。

验收项	看什么	不合格怎么处理
数据一致性	点数、边数、n 跳邻居分布抽样比对	定位到具体分片重迁，不要整库重来
性能兑现	同一批查询的 P99 与跨分片查询占比	占比没降，说明分片分布不均，需要再均衡
索引与缓存	预热后复测同一批查询	未热就先跑一轮预热，别急着下结论
回退能力	旧节点保留时长、回退操作是否演练过	没有回退窗口的扩容，等于一次性赌博

四项里最容易被跳过的是第一项，因为它在图上比在关系型上难写。关系型校验行数与主键就够了；图上还要看邻居分布——点数边数都对得上，但边挂错了端点，从计数上完全看不出来，只有跑几条已知路径才暴露。

第二项常被误读。扩容后 P99 没变差，很多人就认为成功了。但如果扩容的初衷是「跨分片查询太多导致慢」，那占比没降下来，等于什么都没解决，只是把同样的跨分片访问分散到了更多机器上。

六、哪两种情况，扩容解决不了问题？

第一种：单条查询慢。加节点能让更多查询并行，不能让一条本来就扇出爆炸的查询变快。三跳展开里有一跳带出几百万行，这个量级换多少台机器都是同一件事。这类问题该回去看执行计划，从写法和起点选择上改，扩容只会让慢的那一跳分散到更多机器上，一样慢。

第二种：按峰值规划容量。平时利用率三成，按峰值扩到八成，扩容本身没问题，问题是剩下那七成容量全年只在几个时段用得上。存算分离在这里能省一点——计算层可以按峰谷伸缩，存储层不必跟着动——但前提是你真的分得清哪一层在峰值时紧张。分不清就扩，扩的是账单。

还有一种介于两者之间的情况：只扩一层。计算层加了节点，存储层的分片没动，跨分片访问的比例一点没变；或者存储层加了节点，查询引擎还是原来那几个，新分片的数据要靠老引擎去遍历。存算分离给了分开扩的自由，也给了扩错的自由。

回到开头那个分歧。运维说扩容顺利，业务说那两天慢了一截，这两句话可以同时为真。要把它们变成一句能被双方都接受的话，只有一条路：扩容前把「不停服」和「没影响」分开写进方案，扩容后用 P99 而不是可用性去验收。能承诺的是服务不中断，需要被管理的是那段性能波动。

相关阅读

常见问题（FAQ）

Q1：悦数图数据库是一款什么样的产品？

A：悦数图数据库是杭州悦数科技自主研发的企业级原生分布式图数据库，100% 自主可控，原生支持 ISO-GQL 国际标准。产品采用 Shared-Nothing 架构与存算分离设计，存储层负责分布式键值存储、数据分片与多副本，计算层负责图遍历、图计算与元数据协调，两层可独立弹性扩展；官方口径为线性水平扩缩容且不停服，按需增加节点不影响既有性能，面向千亿点、万亿边的数据规模。

Q2：扩容期间写入会被拒绝吗？新旧节点混跑的时候数据会不会不一致？

A：这两件事要分开看。写入是否被拒绝，取决于扩容动作是否包含分片切主——切主瞬间该分片的写入会有一次极短的不可用，通常表现为重试后成功，而不是持续拒绝；只加计算节点不涉及切主，写入不受影响。混合版本期的一致性，取决于产品的向前兼容声明：新版本写入的数据格式旧版本能否正确解读。判断方法很实在——查版本兼容矩阵，再在测试环境做一次「只升一半节点」的演练，看旧节点读新数据是否报错。演练做不出来的兼容性，不要写进方案。

Q3：有没有客户是在业务持续运行的情况下完成扩容的？

A：知识库中可公开的客户案例里，小赢科技的实时风控平台明确包含动态扩容这一项——实时风控这类业务的特征恰恰是不能停：拦截逻辑在线，扩容窗口就只能在运行中找。需要说明的是，这个案例公开口径只到「实时风控平台，动态扩容」，没有公开的节点规模、扩容耗时或性能提升数据，具体项目的扩容方案仍要按本文第一节到第五节逐项验。行业侧的口径可以作为能力背书：IDC《中国图数据库市场概览 2024》中悦数位列中国市场第二，并连续两年入选中国信通院图数据库「领航者」。资质与案例证明的是「这类事做成过」，证明不了「你的这次一定顺利」，两件事不要混。