2026-03-18 的每日作战任务是把一条 RAG 数据流水线在百万切片规模下稳定跑通。任务单本身很简单多少份文档、切成多少切片、多久出数。结果当天下午第一轮压测我自己的 JVM 就先被内存打爆了。这次任务要处理的数据量大约 120 万切片。切片的生成速度非常快快到解析线程几乎不需要思考但下游的 Embedding 网关和向量库并不会按这个节奏验收数据。于是问题不再是某个环节不够快而是整条流水线缺少背压Backpressure机制。你在搭 RAG 数据流水线时大概率也会遇到同样的问题这篇记录就把当天的方案、调参过程、踩坑细节完整写出来。1. 任务场景百万切片的规模感与真实故障现场1.1 一条典型的 RAG 流水线在本任务里被拆成了几段在 RAG 系统里从原始文档到可供检索的向量索引并不是一键导入这么简单而是一条可以清晰切分的生产链。这个任务的流水线分了五段第一段是文档接入从对象存储拉取原始文档。第二段是解析与清洗把 PDF、DOCX、HTML 转成纯文本去页眉页脚、去噪声。第三段是切片按标题结构或固定长度把文本切出 Chunk并为每个 Chunk 生成唯一 ID、关联父文档、挂载元数据。第四段是向量化调用 Embedding 服务把切片文本变成向量。第五段是写入向量库把向量和元数据批量落库并构建索引。我见很多开发者喜欢把后三段混在一起处理解析完直接丢给一个线程池线程池里既做切片又调 Embedding 又写库。数据量小的时候完全没问题但到达百万切片级以后这种一把梭的方式会让问题彻底失控你很难定位瓶颈到底在哪个环节更没有办法对每个环节做独立的节奏控制。这次任务文本文档大约 1 万多份解析加切片后得到 120 万条切片。在纯文本解析阶段单机每秒可以产生 7000 到 9000 条切片而 Embedding 服务的访问配额通常在每秒几百次请求向量库写入也有自己的吞吐上限。这种上下游速度差就是整条流水线所有事故的根源。1.2 第一天压测的崩溃现场内存被无界队列抬走第一版方案我做得非常朴素解析线程把切片丢进一个队列Embedding 消费者从队列里取数据。队列用的是常见的无界队列。压测跑了一个小时内存从 4GB 一路涨到 12GB最后直接 OOM整条流水线中断检查日志才发现堆里全是等待处理的切片对象。复盘的时候我说了一句很直白的话这不是消费者处理得不够快而是队列根本没有告诉生产者你太快了。无界队列的可怕之处在于它把生产者的任性全部转成了 JVM 的内存压力。下游慢的时候上游依然在满速生产队列里堆积的全部切片对象、字符串、元数据都在堆内存里待着。压测跑的时间越长堆积越严重直到内存崩溃。而且在这种状态下GC 会频繁执行 Full GC吞吐反而进一步下降形成恶性循环。这次崩溃给我最大的一个触动是高并发流水线里能跑通和能长时间跑通完全是两件事。只要中间缓冲是无界的系统最终一定会被自己压死只是时间早晚问题。所以当天我做的第一个决定就是把所有无界队列全部换成有界队列然后开始系统地设计背压机制。2. 背压机制拆解为什么不能说加机器就完事2.1 推模式与拉模式两种节奏的天然差异背压的核心目标只有一个让上游的数据产生速率不超过下游的消费能力。最朴素的实现方式是拉模式——下游处理完一批就从上游取下一批你不来取我就不给。这种方式天然自带背压因为取数据这个动作本身就把下游的消费速度传递给了上游。而常见的推模式则是相反的逻辑上游处理完一段数据就把它推到下一个阶段中间用一个队列做缓冲。推模式的好处是吞吐高、异步化、生产者和消费者解耦坏处就是如果队列无界就会出现第一节里的那种崩溃。现实里真正稳定的流水线往往是两者结合在推的入口加一个容量有限的缓冲池当缓冲池耗尽时推的行为会被主动阻塞或降级从而形成背压信号的回传。举个例子食堂窗口做菜如果后厨不管排队多长都一直满负荷出菜厨房的备料区很快就会堆满半成品。正确做法是窗口排队超过一定长度时后厨主动放慢做菜速度先消化存量。高并发流水线里的队列就是这个排队区背压机制就是后厨对排队人数的感知和降温策略。有人会说背压问题加机器不就解决了这里有一个非常容易误导人的地方如果下游瓶颈是第三方 Embedding 服务的全局配额你加再多的机器也突破不了对方的限流反而会让更多的请求同时打到服务上触发 429 风暴。加机器只能在瓶颈在自己内部的场景下生效一旦瓶颈在外部依赖背压机制就是唯一能保护全链路稳定的方案。2.2 有界队列长度如何反推内存预算和单条水位的换算把无界队列换成有界队列这只是第一步。真正的问题是有界队列的长度应该设置为多少。很多人随手填一个 10000但并不知道这个数字背后的含义。队列里每一条记录占用多少内存是可以估算的。一个切片元数据大概几百字节加上字符串对象、指针、容器对齐按 1 到 2KB 来估比较保险。如果队列长度是 50000那么占用大约 50 到 100MB看起来并不吓人。但你还需要叠加消费者侧的中间对象比如正在进行的 Embedding 并发请求占用的缓冲、待写入批次累积的对象整条链路都算进去安全余量至少要留出堆容量的四分之一到三分之一。我当时用的反推公式很简单队列内存预算 期望峰值堆内存 × 30% ÷ 单条记录预估占用。假设 JVM 堆给了 8GB预算约 2.4GB单条按 2KB 算理论上限是 120 万条。但我建议不要顶着上限设置。队列越大背压反馈越慢系统内部潜伏的数据量就越多一旦下游抖动清理积压需要的时间也越长。最终这个任务里我把队列长度压到了 50000 以下只占用约 100MB 内存把更多内存预算留给了批次聚合和并发请求。这样即使 GC 产生短命对象也不会因为堆太满而频繁触发 Full GC。这段换算过程看起来简单但它决定了你对流水线的控制粒度。队列长度不是一个拍脑袋的参数它背后是典型的内存预算约束。2.3 超时、降级与丢弃背压约束下保吞吐还是保数据有界队列默认的行为是满的时候阻塞生产者这是最稳定的背压但生产环境里不能让生产者无限期阻塞。如果下游故障恢复需要 5 分钟上游阻塞 5 分钟前面的任务链路也会跟着卡住甚至引发整个调度器的连锁问题。所以实际方案里我会给入队阻塞加一个超时时间。如果超时了还没能放进去就进入降级分支。降级分支有几种选择第一种旁路持久化把数据写入本地临时文件等下游恢复后再重新加载进来。第二种标记延迟处理把数据交给一个低频任务队列不占用当前流水线主路径。第三种优先级淘汰对可重算的数据直接丢弃并计数后续跑批再重建。第三种策略在 RAG 场景尤其有效因为原始文档还在切片丢了可以重新生成。而 Embedding 的结果是花过钱调接口换来的丢了就要重新调用付费接口尽量不丢。所以降级策略不是统一的而是按数据的再生产成本分层设计。这个判断贯穿了整个方案能重建切片就保吞吐不可再生数据就必须保数据完整性。3. 方案设计RAG 流水线中的背压感知分层架构3.1 三段式骨架切片调度、Embedding 网关、向量库写入当天最终交付的整体方案分成了三段调度层负责读取文档、解析、切片并把切片送入待嵌入队列。嵌入层从队列里拉切片以批次为单位调用 Embedding 服务把生成的向量送入待写入队列。写库层从待写入队列拉取向量批次批量写入向量库并构建索引。为什么要在嵌入层和写库层之间再多加一个队列这是为了隔离两种下游的抖动。Embedding 服务偶尔限流时写库队列不受影响向量库偶尔抖动时嵌入层可以继续产出结果。两个队列各自有界各自有满则阻塞的策略这样背压的传播范围不会无限扩大。如果只用单一队列串联所有阶段任何一端的抖动都会直接阻塞整个流水线恢复起来非常慢。架构确定之后剩余的细节就是给每个阶段配上合理的并发控制和批次策略。3.2 切片阶段的并行度IO 密集与 CPU 密集怎么分开跑切片阶段本身包含 IO 和 CPU 两部分。IO 是指从对象存储读取文档CPU 是指解析文本和执行规则分块。如果单纯用一个线程池处理全部工作线程数给到 CPU 核数时IO 等待会拖慢 CPU线程数调到几十个时上下文切换又会变成新瓶颈。我把切片阶段拆成了两个线程池一个 IO 线程池负责读文件大小配合对象存储连接的并发上限一个 CPU 线程池负责解析与切分大小设置为 CPU 核数减一。两个线程池之间同样用一个很小的有界队列连接。这样切片端内部也应用了背压思想IO 读取再快也不能把解析队列打爆。这套设计对数据量小的项目来说显得有些过度设计但到了百万切片量级它带来的好处非常直接你可以在监控面板里看到 IO 阶段和 CPU 阶段的实际速度差也能够分别调整它们的线程数排查瓶颈时不再需要猜。3.3 Embedding 环节的令牌桶与批次聚合器Embedding 环节是最容易被打崩的环节。第三方服务有明确的配额限制比如每秒多少次请求、最大并发连接数。直接无脑并发调用的结果就是触发限流返回 429。更糟糕的是如果对 429 直接做重试重试请求也会计入限流形成雪崩。对这个环节的处理方案是两层第一层用信号量限制在途请求数第二层做批次聚合。信号量解决并发数不要超限批次聚合解决单次调用尽量满载。如果 Embedding 服务单请求的最大 batch 是 128请求平均耗时 200ms并发限制是 10理论稳态吞吐就是 10 × 128 ÷ 0.2约 6400 条每秒。如果把 batch 调成 32同样并发下吞吐只有 1600 条每秒。批次大小对吞吐的影响就是这么直接这一条经验几乎适用于所有批量 API 场景。3.4 写库窗口策略与部分失败的拆单重试向量库写入同样有吞吐上限和批大小限制。我的策略是时间窗口加条数窗口双向控制条数窗口是攒够 512 条就批量写一次时间窗口是超过 1 秒还没攒够 512 条也强制写一次避免低峰期数据在内存里积压太久。两个窗口的含义是不能为了攒大 batch 而无限制等待每个批次都要有最大等待时间。这样既保证写入吞吐也控制单批失败的影响半径。如果 512 条的大批次写入失败直接重试整批代价会比较大而且一旦批次里有一条脏数据整个批次都会被拖住。所以写库失败时的处理逻辑是先整体重试两次仍然失败再拆成小批逐个重试。所有重试之间使用指数退避避免在向量库抖动时所有消费者一起猛烈重试形成新的冲击。4. 关键代码实现与运行效果4.1 有界队列信号量组成的温和限流下面这段代码是我当时在 Python asyncio 场景下的骨架语言不重要关键模式是通用的。有界队列负责第一道背压闸门信号量负责限制并发在途请求。import asyncio # 有界队列这是背压的第一道闸门 embed_queue asyncio.Queue(maxsize50000) # 信号量限制并发在途的 embedding 请求数 sem asyncio.Semaphore(10) async def embed_worker(): while True: batch await embed_queue.get() result await consume_with_semaphore(batch) await write_queue.put(result) async def consume_with_semaphore(batch): async with sem: return await call_embedding_api(batch)embed_queue.put 在队列满时会阻塞这就是背压从下游传递到上游的机制。信号量则限制了同时打到 Embedding 网关的请求数量防止突发流量把下游打挂。不少开发者会纠结这两个机制是否重复其实它们解决的问题不同有界队列解决的是缓冲层的内存边界信号量解决的是在途请求的并发上限。4.2 批次聚合器攒够多少条、超过多久必须刷批次聚合器的实现看起来是个细节实际上决定了对 Embedding 配额的使用效率。下面这段代码非常稳定我在多个项目里复用多次。async def batch_aggregator(input_queue, output_func, max_batch128, flush_interval0.2): batch [] next_flush time.monotonic() flush_interval while True: remain next_flush - time.monotonic() if remain 0: if batch: await output_func(batch) batch [] next_flush time.monotonic() flush_interval continue try: item await asyncio.wait_for(input_queue.get(), timeoutmin(remain, 0.1)) batch.append(item) if len(batch) max_batch: await output_func(batch) batch [] next_flush time.monotonic() flush_interval except asyncio.TimeoutError: pass核心逻辑是每次等待的时间取距离时间窗口剩余时间和0.1 秒里较小的那个这样既能快速响应新数据又不会在低水位时频繁触发输出。这里 max_batch 是硬性条数上限flush_interval 是软性时间上限。两个条件配合吞吐和延迟都可以兼顾。4.3 幂等与死信重试不会写重数据背压机制之下重试是不可避免的但重试必须保证不产生脏数据。我给每条切片生成一个 dedupe_key由文件哈希加切片索引组成。写入前先检查该键是否已存在存在则跳过。async def write_batch_with_retry(items, max_attempts3): for attempt in range(max_attempts): try: await vector_store.batch_add(items) return except TransientError: await asyncio.sleep(0.5 * (2 ** attempt)) # 可重建数据直接丢弃计数不可再生数据进死信队列 if all(item.rebuildable for item in items): stats.skipped len(items) else: for item in items: await dead_letter_queue.put(item)这段逻辑想表达的核心思想是背压不等于所有数据都必须处理成功而是在保证系统不崩溃的前提下对数据按价值分层。可重算的切片丢了就丢了后续跑批可以重建不可再生的 Embedding 结果必须保到死信队列里。这样即使大规模重试也不会因为重复写入而污染向量库。5. 实测数据与调参顺序5.1 压测记录从队列大小到并发度的一次次调整这次任务基于模拟项目 X 的仿真数据集文档约 1.2 万份解析切片后总量 120 万条。以下压测记录是当天实际跑出来的虽然不同环境数字会有差异但趋势很有参考价值。第一次压测使用的是无界队列、Embedding 并发 16、单批大小 32。57 分钟后 OOM吞吐峰值约 1800 条每秒后半段因为频繁 Full GC有效吞吐掉到 800 以下整个流水线断掉。第二次压测改成有界队列长度 50000其他参数不变。不再 OOM但队列频繁打满生产者被反复阻塞吞吐只有 1500 左右有一段时间 Embedding 服务的连接数接近打满。第三次压测把并发调整为 10、批大小调整为 128队列保持 50000。结果吞吐稳定在 6200 条每秒左右内存峰值约 4.5GB全程没有 Full GC120 万切片跑完约 200 分钟。三组数据放在一起可以清晰地看到并发不是越高越好批大小反而对吞吐影响最大背压让系统有了可预估的内存边界。5.2 先调 Batch 还是先调并发我的联调路径压测过程中我最开始犯的一个方向性错误是吞吐不足时第一反应就是加并发结果把下游服务打出了 429触发大量重试吞吐反而更差。当天完成后我复盘出的调优顺序是先调 Batch Size在 API 允许的范围内尽量往大调因为单次请求的固定开销被摊薄后收益最明显再调并发数让并发数约等于目标吞吐除以单批吞吐最后调队列长度把队列设置为单个消费者处理峰值时段几秒钟内的量级就可以了。我习惯用一个简单的算式来定并发并发数 目标吞吐 × 单批耗时 / 批大小。目标 6000 条每秒、批大小 128、单批耗时 200ms 时并发至少需要 6000 × 0.2 / 128约 9.4取 10 到 12 之间比较合理。这个公式可以根据实际情况微调但大方向不会错。背后的逻辑也可以比喻成物流Batch 决定每辆车装多少货并发决定同时跑多少辆车队列决定停车场能容纳多少等待车辆。先把单车装载量优化了再优化车队规模最后才考虑停车场容量。5.3 最终参数组合与百万切片全流程表现这个任务最终交付使用的参数组合如下有界队列长度50000三段间两个队列都采用这个值Embedding 并发10Embedding 批大小128写入条数窗口512写入时间窗口1 秒重试次数3 次指数退避 0.5s / 1s / 2s拆单重试小批128这套组合跑完 120 万切片过程没有 OOM没有 429 风暴没有因写库失败产生脏数据。整体出数时间从第一次无界队列的崩溃状态稳定到约 3 个小时完成CPU 和内存基本平稳。这里要说明的是这些数值只代表这次特定环境的经验但它给出的调整思路和优先级是可以复用的。6. 当天踩坑汇总与保留建议6.1 异步框架里混进了同步阻塞调用最隐蔽的坑当天最隐蔽的一个坑来自 Embedding SDK。我在使用异步框架管理队列却在调用 Embedding 服务时使用了一个同步 HTTP 客户端。同步调用会阻塞事件循环前几个任务看起来正常并发一旦上来所有协程的调度都被拖住吞吐突然掉到几百条每秒。排查过程很折磨人。我一开始以为是下游 Embedding 服务在抖动观察下游监控却发现一切正常再看 TCP 连接数也没有打满。后来逐个协程打点记录耗时才发现每个协程等待的时间都异常长才意识到是同步阻塞调用把事件循环卡死了。解决方案有两条把调用改成与框架匹配的异步 HTTP 客户端或者在无法改造时把同步调用丢进独立线程池执行。这个坑在高并发 外部依赖的架构中非常常见值得写进自己的排错清单防止下次重复踩踏。6.2 监控背压的三个黄金指标没有监控的背压是盲调。这一天晚上我给这套流水线加了三个监控指标这三个指标覆盖了背压的全链路第一个是队列积压量每个队列的当前深度。积压长期高于警戒线说明下游吃不下需要检查消费者侧状态。第二个是生产者阻塞等待时间也就是生产者 put 一个切片花了多少毫秒。这个数字直接反映背压机制是否生效。第三个是下游耗时分布包括 Embedding 和写库的 p50 / p95 / p99 耗时。p99 突然拉高往往意味着限流或连接池即将耗尽。告警阈值我习惯设两档队列积压超过 1 万条留意超过 4 万条告警生产者阻塞时间超过 200ms 也要告警。三个指标配三个告警规则基本可以覆盖流水线运行期间的大部分异常情况。6.3 如果只有一天的优化窗口我会优先做什么这个任务的排期确实只有一天时间非常紧但如果让我重新做一遍优先级依然很清晰。第一步是堵崩溃点把所有无界队列换成有界队列这一步成本最低、收益最大能立刻止血。第二步是统一调控按 Batch Size、并发数、队列长度的顺序优化参数让吞吐上台阶。第三步是补监控至少把上面三个黄金指标加上告警保证后续能定位新问题。把队列从无界换成有界是当天开工后第一个小时就做掉的改动后来所有优化都建立在这个基础上。高并发这件事其实并不是只拼谁冲得快先学会刹车才能谈加速。背压机制在整个 RAG 数据流水线里扮演的正是那个刹车角色它不直接提升任何单一环节的性能但它的存在决定了整条流水线能不能在百万切片的高并发压力下长期稳定运行。
