后端并发编程异步编程【免费下载链接】akka-coreA platform to build and run apps that are elastic, agile, and resilient. SDK, libraries, and hosted environments.项目地址https://gitcode.com/gh_mirrors/ak/akka-core点击查看免费下载Source.queue是 Akka Streams 中用于将外部生产者与流式处理管线衔接的核心操作符它把Source材质化materialize为一个可以持续推入元素的队列对象元素在存在下游需求demand时被发射否则进入缓冲区。本文以官方文档 Source/queue.md 为骨架结合akka-stream模块的真实实现源码系统讲解该操作符的两种形态——同步反馈的BoundedSourceQueue与支持多种溢出策略的异步SourceQueue包括它们的签名、QueueOfferResult结果语义、底层状态机与无锁队列实现、OverflowStrategy全策略对比以及在高负载场景下的选型建议。读完本文你将能够根据业务对丢弃元素 快速反馈或背压 多种溢出策略的不同诉求正确选择并落地Source.queue。一个操作符两种材质化类型Source.queue在akka-stream中提供三个重载分别材质化为两种不同的队列接口重载签名Scala材质化类型反馈方式适用溢出策略Source.queueTBoundedSourceQueue[T]同步返回QueueOfferResult固定为dropNew语义丢弃新元素Source.queueTSourceQueueWithComplete[T]异步返回Future[QueueOfferResult]任意OverflowStrategySource.queueTSourceQueueWithComplete[T]异步返回Future[QueueOfferResult]任意OverflowStrategy支持并发 offerJava DSL 与之对应在 javadsl/Source.scala 中提供Source.queue(int)、Source.queue(int, OverflowStrategy)与Source.queue(int, OverflowStrategy, int)异步反馈类型为CompletionStageQueueOfferResult。同步变体 BoundedSourceQueue面向高负载丢弃场景的优化实现签名与语义def queueT: Source[T, BoundedSourceQueue[T]]对应 Javastatic T SourceT, BoundedSourceQueueT queue(int bufferSize)BoundedSourceQueue是SourceQueue在OverflowStrategy.dropNew语义下的优化变体。其核心设计目标是在缓冲区满时直接拒绝新元素并通过offer()立即、同步返回QueueOfferResult告知生产者结果是入队还是被丢弃参见 scaladsl/Source.scala 的实现Source.fromGraph(new BoundedSourceQueueStageT)。为什么同步反馈如此重要文档明确指出如果元素入队的速度快于异步反馈的送达速度那么反馈机制本身就会成为 OOMOut Of Memory的一部分成因——Future/CompletionStage的完成回调也会占用内存。同步返回结果可以从根本上规避offer 确认慢于元素注入速率导致的无限堆积。QueueOfferResult 的四种结果BoundedSourceQueue.offer()返回的QueueOfferResult是 sealed trait具体取值在 BoundedSourceQueue.scala 的实现注释中定义得十分清晰结果含义QueueOfferResult.Enqueued元素已加入缓冲区但不保证最终被流处理——队列被fail或下游取消时仍可能被丢弃QueueOfferResult.Dropped元素被丢弃缓冲区已满QueueOfferResult.QueueClosed队列已通过complete()完成不再接受元素QueueOfferResult.Failure(ex)队列被fail()失败或流本身失败值得注意的是Enqueued 不等于已处理源码注释强调An element that was reported to beenqueuedis not guaranteed to be processed by the rest of the stream如果队列被BoundedSourceQueue.fail或下游取消缓冲区中的元素会被直接丢弃。因此BoundedSourceQueue适用于元素可丢、需要快速止损的场景而不适用于必须恰好处理一次的强保证场景。源码级实现剖析从 BoundedSourceQueue.scala 可以看到该变体的工程细节有界无锁队列内部使用AbstractBoundedNodeQueueTakka.dispatch包基于AtomicReference的无锁 MPSC 队列配合AtomicReference[State]状态机NeedsActivation/Running/Done实现多线程生产者的安全入队文档中buffer that can be used by many producers on different threads正是由此支撑构造约束require(bufferSize 0)即BoundedSourceQueue的缓冲区大小必须大于 0不允许用 0 禁用缓冲offer 的原子路径offer(elem)在Running | NeedsActivation状态下调用queue.add(elem)成功返回Enqueued失败返回Dropped若入队瞬间发现 stage 处于NeedsActivation则通过getAsyncCallback唤醒主循环避免元素滞留缓冲区完成与失败路径onDownstreamFinish将状态置为Done(Failure(cause))postStop会排空缓冲区并置为StreamDetachedException的FailureDone(QueueClosed)状态会在缓冲排空后completeStage()。完整示例以下是仓库测试 IntegrationDocSpec.scala 中的#source-queue-synchronous片段Scalaval bufferSize 1000 val queue Source .queueInt .map(x x * x) .toMat(Sink.foreach(x println(scompleted $x)))(Keep.left) .run() val fastElements 1 to 10 fastElements.foreach { x queue.offer(x) match { case QueueOfferResult.Enqueued println(senqueued $x) case QueueOfferResult.Dropped println(sdropped $x) case QueueOfferResult.Failure(ex) println(sOffer failed ${ex.getMessage}) case QueueOfferResult.QueueClosed println(Source Queue closed) } }对应的 Java 版本见 IntegrationDocTest.javaint bufferSize 10; int elementsToProcess 5; BoundedSourceQueueInteger sourceQueue Source.Integerqueue(bufferSize) .throttle(elementsToProcess, Duration.ofSeconds(3)) .map(x - x * x) .to(Sink.foreach(x - System.out.println(got: x))) .run(system); ListInteger fastElements Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10); fastElements.stream() .forEach( x - { QueueOfferResult result sourceQueue.offer(x); if (result QueueOfferResult.enqueued()) { System.out.println(enqueued x); } else if (result QueueOfferResult.dropped()) { System.out.println(dropped x); } else if (result instanceof QueueOfferResult.Failure) { QueueOfferResult.Failure failure (QueueOfferResult.Failure) result; System.out.println(Offer failed failure.cause().getMessage()); } else if (result instanceof QueueOfferResult.QueueClosed$) { System.out.println(Bounded Source Queue closed); } });注意 Scala 与 Java 在结果类型判断上的差异Scala 使用模式匹配Java 则对单例结果enqueued()、dropped()用比较对带载荷的结果Failure、QueueClosed$用instanceof判断并强制转换。异步变体 SourceQueue完整溢出策略与异步确认签名与语义def queueT: Source[T, SourceQueueWithComplete[T]] def queueT: Source[T, SourceQueueWithComplete[T]]SourceQueueWithComplete除了offer()还提供complete()正常完成队列、fail(ex)失败队列与watchCompletion()观测流是否完成/失败。offer()返回Future[QueueOfferResult]Java 为CompletionStage确认是异步的。核心行为依据 scaladsl/Source.scala 的文档注释向队列推入元素后若下游存在需求则立即发射否则缓冲直到收到下游的 demand 请求下游终止时缓冲区中的元素会被丢弃缓冲可用bufferSize 0禁用此时元素会等待下游需求若已有另一个元素在等待offer结果将按溢出策略处理SourceQueueWithComplete默认仅限单一生产者使用maxConcurrentOffers 1这是与BoundedSourceQueue的显著差异之一。完整示例Scala 版本IntegrationDocSpec.scalaval bufferSize 10 val elementsToProcess 5 val queue Source .queueInt .throttle(elementsToProcess, 3.second) .map(x x * x) .toMat(Sink.foreach(x println(scompleted $x)))(Keep.left) .run() val source Source(1 to 10) source .map(x { queue.offer(x).map { case QueueOfferResult.Enqueued println(senqueued $x) case QueueOfferResult.Dropped println(sdropped $x) case QueueOfferResult.Failure(ex) println(sOffer failed ${ex.getMessage}) case QueueOfferResult.QueueClosed println(Source Queue closed) } }) .runWith(Sink.ignore)Java 版本IntegrationDocTest.javaint bufferSize 10; int elementsToProcess 5; BoundedSourceQueueInteger sourceQueue Source.Integerqueue(bufferSize) .throttle(elementsToProcess, Duration.ofSeconds(3)) .map(x - x * x) .to(Sink.foreach(x - System.out.println(got: x))) .run(system); SourceInteger, NotUsed source Source.from(Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)); source.map(x - sourceQueue.offer(x)).runWith(Sink.ignore(), system);maxConcurrentOffers多生产者并发能力第三个重载引入maxConcurrentOffers参数用于在缓冲区满时允许指定数量的待确认 offer 并发挂起默认值为 1即单一生产者必须大于 0否则 QueueSource.scala 中的require(maxConcurrentOffers 0)会直接抛异常当使用OverflowStrategy.backpressure时缓冲区满后最多有maxConcurrentOffers个offer()的Future不完成等待空间释放若并发 offer 数超过该上限源码会抛出 Too many concurrent offers. Specified maximum is N 的异常该参数对dropNew策略不适用丢弃策略下 offer 立即有结果无需挂起。OverflowStrategy 策略全解析SourceQueue的溢出策略定义在 OverflowStrategy.scala当元素到达速度超过下游消费速度、缓冲区无法容纳时生效策略行为是否背压dropHead丢弃缓冲区中最旧的元素为新元素腾出空间否dropTail丢弃缓冲区中最新最年轻的元素否dropBuffer丢弃缓冲区中全部元素为新元素腾出空间否dropNew丢弃新到达的元素已废弃见下否backpressure背压上游生产者直到缓冲区释放空间与maxConcurrentOffers配合缓冲满时不完成对应数量的offerFuture是fail缓冲区满时直接以失败终止流否关键点OverflowStrategy.dropNew在 2.6.11 起已被标记废弃deprecated(Use Source.queue instead, 2.6.11)官方明确建议需要丢弃新元素时改用Source.queue(bufferSize)返回的同步BoundedSourceQueue。这正是文档结论preferBoundedSourceQueueoverSourceQueuewithOverflowStrategy.dropNew在 API 层面的落实——两者语义等价但同步反馈消除了异步确认的延迟与内存开销。此外OverflowStrategy均支持withLogLevel设置丢弃/失败时的日志级别如dropNew默认DebugLevel、fail默认ErrorLevel。选型决策何时用 BoundedSourceQueue何时用 SourceQueue综合文档与源码可以给出如下决策框架高负载 允许丢弃 需要快速止损→ 用Source.queue(bufferSize)BoundedSourceQueue。它把缓冲满就丢和立即告知结果合并为一次同步调用多线程生产者直接通过无锁有界队列入队避免异步反馈成为 OOM 的放大器需要精确控制丢弃哪个元素丢头/丢尾/丢全部或需要背压backpressure或需要失败快速终止fail→ 用Source.queue(bufferSize, overflowStrategy[, maxConcurrentOffers])并接受异步确认的成本必须恰好处理的场景需要额外警惕两种变体的Enqueued都不保证元素最终被下游消费下游取消或队列fail时缓冲会被丢弃必要时应结合持久化或重试机制兜底生产者数量BoundedSourceQueue面向多线程生产者优化SourceQueue默认单生产者需要并发 offer 时显式调大maxConcurrentOffers且该参数不适用于dropNew。与 throttle 组合限流控制处理速率文档特别推荐将队列与throttle操作符组合使用以把处理速率限制到给定上限。上面的两个示例即为标准用法Source .queueInt .throttle(elementsToProcess, 3.second) // 每 3 秒最多处理 5 个元素 .map(x x * x) .toMat(Sink.foreach(x println(scompleted $x)))(Keep.left) .run()throttle在下游制造节流需求队列据此决定元素是立即发射还是滞留缓冲从而让外部生产者以受控速率被消费——这在对接不可控的外部数据源如传感器、消息队列拉取、用户请求时是控制资源消耗的常用手段。Reactive Streams 语义该操作符的 Reactive Streams 语义文档末尾 callout简洁而明确emits发射当下游存在 demand 且队列中含有元素时completes完成当下游完成时。对应到源码QueueSource与BoundedSourceQueueStage都在onPull下游请求元素时从缓冲区取元素push到下游两者均遵循无需求不发射、有需求才出队的拉模型SourceQueue的complete()对应QueueOfferResult.QueueClosed下游取消则触发缓冲丢弃并失败。实践要点小结缓冲区大小BoundedSourceQueue要求bufferSize 0SourceQueue支持bufferSize 0禁用缓冲元素直接等待下游需求此时溢出策略决定多个待处理元素时的 offer 结果反馈差异同步BoundedSourceQueue适合元素来得比确认快的高负载场景异步SourceQueue的确认本身可能成为 OOM 诱因需要评估确认速率是否跟得上注入速率生命周期管理善用complete()/fail()/watchCompletion()管理队列生命周期下游取消后继续offer只会得到Failure/QueueClosed结果代码即文档上述结论均可回溯到 scaladsl/Source.scala、BoundedSourceQueue.scala 与 QueueSource.scala 的实现与注释示例代码可在 IntegrationDocSpec.scala 与 IntegrationDocTest.java 中直接运行验证。赞分享后端并发编程异步编程【免费下载链接】akka-coreA platform to build and run apps that are elastic, agile, and resilient. SDK, libraries, and hosted environments.项目地址https://gitcode.com/gh_mirrors/ak/akka-core点击查看免费下载相关推荐Akka Streams 的 mapAsync 操作符在保持顺序的同时实现异步并发处理Akka Streams 的 mapAsync 操作符在保持顺序的同时实现异步并发处理 导读 mapAsync 是 Akka Streams 中最重要的异步操后端并发编程异步编程RL4CO社区贡献指南如何参与开源项目开发与维护RL4CO社区贡献指南如何参与开源项目开发与维护 欢迎来到RL4CO社区 这是一个专注于强化学习RL在组合优化CO领域的PyTorch库为研究后端并发编程异步编程Akka Streams scanAsync 操作符详解基于 Future/CompletionStage 的异步累加扫描Akka Streams scanAsync 操作符详解基于 Future/CompletionStage 的异步累加扫描 scanAsync 是 Akka后端并发编程异步编程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Akka Streams Source.queue 操作符全解析：同步 BoundedSourceQueue 与异步 SourceQueue 的选型与背压实践
后端并发编程异步编程【免费下载链接】akka-coreA platform to build and run apps that are elastic, agile, and resilient. SDK, libraries, and hosted environments.项目地址https://gitcode.com/gh_mirrors/ak/akka-core点击查看免费下载Source.queue是 Akka Streams 中用于将外部生产者与流式处理管线衔接的核心操作符它把Source材质化materialize为一个可以持续推入元素的队列对象元素在存在下游需求demand时被发射否则进入缓冲区。本文以官方文档 Source/queue.md 为骨架结合akka-stream模块的真实实现源码系统讲解该操作符的两种形态——同步反馈的BoundedSourceQueue与支持多种溢出策略的异步SourceQueue包括它们的签名、QueueOfferResult结果语义、底层状态机与无锁队列实现、OverflowStrategy全策略对比以及在高负载场景下的选型建议。读完本文你将能够根据业务对丢弃元素 快速反馈或背压 多种溢出策略的不同诉求正确选择并落地Source.queue。一个操作符两种材质化类型Source.queue在akka-stream中提供三个重载分别材质化为两种不同的队列接口重载签名Scala材质化类型反馈方式适用溢出策略Source.queueTBoundedSourceQueue[T]同步返回QueueOfferResult固定为dropNew语义丢弃新元素Source.queueTSourceQueueWithComplete[T]异步返回Future[QueueOfferResult]任意OverflowStrategySource.queueTSourceQueueWithComplete[T]异步返回Future[QueueOfferResult]任意OverflowStrategy支持并发 offerJava DSL 与之对应在 javadsl/Source.scala 中提供Source.queue(int)、Source.queue(int, OverflowStrategy)与Source.queue(int, OverflowStrategy, int)异步反馈类型为CompletionStageQueueOfferResult。同步变体 BoundedSourceQueue面向高负载丢弃场景的优化实现签名与语义def queueT: Source[T, BoundedSourceQueue[T]]对应 Javastatic T SourceT, BoundedSourceQueueT queue(int bufferSize)BoundedSourceQueue是SourceQueue在OverflowStrategy.dropNew语义下的优化变体。其核心设计目标是在缓冲区满时直接拒绝新元素并通过offer()立即、同步返回QueueOfferResult告知生产者结果是入队还是被丢弃参见 scaladsl/Source.scala 的实现Source.fromGraph(new BoundedSourceQueueStageT)。为什么同步反馈如此重要文档明确指出如果元素入队的速度快于异步反馈的送达速度那么反馈机制本身就会成为 OOMOut Of Memory的一部分成因——Future/CompletionStage的完成回调也会占用内存。同步返回结果可以从根本上规避offer 确认慢于元素注入速率导致的无限堆积。QueueOfferResult 的四种结果BoundedSourceQueue.offer()返回的QueueOfferResult是 sealed trait具体取值在 BoundedSourceQueue.scala 的实现注释中定义得十分清晰结果含义QueueOfferResult.Enqueued元素已加入缓冲区但不保证最终被流处理——队列被fail或下游取消时仍可能被丢弃QueueOfferResult.Dropped元素被丢弃缓冲区已满QueueOfferResult.QueueClosed队列已通过complete()完成不再接受元素QueueOfferResult.Failure(ex)队列被fail()失败或流本身失败值得注意的是Enqueued 不等于已处理源码注释强调An element that was reported to beenqueuedis not guaranteed to be processed by the rest of the stream如果队列被BoundedSourceQueue.fail或下游取消缓冲区中的元素会被直接丢弃。因此BoundedSourceQueue适用于元素可丢、需要快速止损的场景而不适用于必须恰好处理一次的强保证场景。源码级实现剖析从 BoundedSourceQueue.scala 可以看到该变体的工程细节有界无锁队列内部使用AbstractBoundedNodeQueueTakka.dispatch包基于AtomicReference的无锁 MPSC 队列配合AtomicReference[State]状态机NeedsActivation/Running/Done实现多线程生产者的安全入队文档中buffer that can be used by many producers on different threads正是由此支撑构造约束require(bufferSize 0)即BoundedSourceQueue的缓冲区大小必须大于 0不允许用 0 禁用缓冲offer 的原子路径offer(elem)在Running | NeedsActivation状态下调用queue.add(elem)成功返回Enqueued失败返回Dropped若入队瞬间发现 stage 处于NeedsActivation则通过getAsyncCallback唤醒主循环避免元素滞留缓冲区完成与失败路径onDownstreamFinish将状态置为Done(Failure(cause))postStop会排空缓冲区并置为StreamDetachedException的FailureDone(QueueClosed)状态会在缓冲排空后completeStage()。完整示例以下是仓库测试 IntegrationDocSpec.scala 中的#source-queue-synchronous片段Scalaval bufferSize 1000 val queue Source .queueInt .map(x x * x) .toMat(Sink.foreach(x println(scompleted $x)))(Keep.left) .run() val fastElements 1 to 10 fastElements.foreach { x queue.offer(x) match { case QueueOfferResult.Enqueued println(senqueued $x) case QueueOfferResult.Dropped println(sdropped $x) case QueueOfferResult.Failure(ex) println(sOffer failed ${ex.getMessage}) case QueueOfferResult.QueueClosed println(Source Queue closed) } }对应的 Java 版本见 IntegrationDocTest.javaint bufferSize 10; int elementsToProcess 5; BoundedSourceQueueInteger sourceQueue Source.Integerqueue(bufferSize) .throttle(elementsToProcess, Duration.ofSeconds(3)) .map(x - x * x) .to(Sink.foreach(x - System.out.println(got: x))) .run(system); ListInteger fastElements Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10); fastElements.stream() .forEach( x - { QueueOfferResult result sourceQueue.offer(x); if (result QueueOfferResult.enqueued()) { System.out.println(enqueued x); } else if (result QueueOfferResult.dropped()) { System.out.println(dropped x); } else if (result instanceof QueueOfferResult.Failure) { QueueOfferResult.Failure failure (QueueOfferResult.Failure) result; System.out.println(Offer failed failure.cause().getMessage()); } else if (result instanceof QueueOfferResult.QueueClosed$) { System.out.println(Bounded Source Queue closed); } });注意 Scala 与 Java 在结果类型判断上的差异Scala 使用模式匹配Java 则对单例结果enqueued()、dropped()用比较对带载荷的结果Failure、QueueClosed$用instanceof判断并强制转换。异步变体 SourceQueue完整溢出策略与异步确认签名与语义def queueT: Source[T, SourceQueueWithComplete[T]] def queueT: Source[T, SourceQueueWithComplete[T]]SourceQueueWithComplete除了offer()还提供complete()正常完成队列、fail(ex)失败队列与watchCompletion()观测流是否完成/失败。offer()返回Future[QueueOfferResult]Java 为CompletionStage确认是异步的。核心行为依据 scaladsl/Source.scala 的文档注释向队列推入元素后若下游存在需求则立即发射否则缓冲直到收到下游的 demand 请求下游终止时缓冲区中的元素会被丢弃缓冲可用bufferSize 0禁用此时元素会等待下游需求若已有另一个元素在等待offer结果将按溢出策略处理SourceQueueWithComplete默认仅限单一生产者使用maxConcurrentOffers 1这是与BoundedSourceQueue的显著差异之一。完整示例Scala 版本IntegrationDocSpec.scalaval bufferSize 10 val elementsToProcess 5 val queue Source .queueInt .throttle(elementsToProcess, 3.second) .map(x x * x) .toMat(Sink.foreach(x println(scompleted $x)))(Keep.left) .run() val source Source(1 to 10) source .map(x { queue.offer(x).map { case QueueOfferResult.Enqueued println(senqueued $x) case QueueOfferResult.Dropped println(sdropped $x) case QueueOfferResult.Failure(ex) println(sOffer failed ${ex.getMessage}) case QueueOfferResult.QueueClosed println(Source Queue closed) } }) .runWith(Sink.ignore)Java 版本IntegrationDocTest.javaint bufferSize 10; int elementsToProcess 5; BoundedSourceQueueInteger sourceQueue Source.Integerqueue(bufferSize) .throttle(elementsToProcess, Duration.ofSeconds(3)) .map(x - x * x) .to(Sink.foreach(x - System.out.println(got: x))) .run(system); SourceInteger, NotUsed source Source.from(Arrays.asList(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)); source.map(x - sourceQueue.offer(x)).runWith(Sink.ignore(), system);maxConcurrentOffers多生产者并发能力第三个重载引入maxConcurrentOffers参数用于在缓冲区满时允许指定数量的待确认 offer 并发挂起默认值为 1即单一生产者必须大于 0否则 QueueSource.scala 中的require(maxConcurrentOffers 0)会直接抛异常当使用OverflowStrategy.backpressure时缓冲区满后最多有maxConcurrentOffers个offer()的Future不完成等待空间释放若并发 offer 数超过该上限源码会抛出 Too many concurrent offers. Specified maximum is N 的异常该参数对dropNew策略不适用丢弃策略下 offer 立即有结果无需挂起。OverflowStrategy 策略全解析SourceQueue的溢出策略定义在 OverflowStrategy.scala当元素到达速度超过下游消费速度、缓冲区无法容纳时生效策略行为是否背压dropHead丢弃缓冲区中最旧的元素为新元素腾出空间否dropTail丢弃缓冲区中最新最年轻的元素否dropBuffer丢弃缓冲区中全部元素为新元素腾出空间否dropNew丢弃新到达的元素已废弃见下否backpressure背压上游生产者直到缓冲区释放空间与maxConcurrentOffers配合缓冲满时不完成对应数量的offerFuture是fail缓冲区满时直接以失败终止流否关键点OverflowStrategy.dropNew在 2.6.11 起已被标记废弃deprecated(Use Source.queue instead, 2.6.11)官方明确建议需要丢弃新元素时改用Source.queue(bufferSize)返回的同步BoundedSourceQueue。这正是文档结论preferBoundedSourceQueueoverSourceQueuewithOverflowStrategy.dropNew在 API 层面的落实——两者语义等价但同步反馈消除了异步确认的延迟与内存开销。此外OverflowStrategy均支持withLogLevel设置丢弃/失败时的日志级别如dropNew默认DebugLevel、fail默认ErrorLevel。选型决策何时用 BoundedSourceQueue何时用 SourceQueue综合文档与源码可以给出如下决策框架高负载 允许丢弃 需要快速止损→ 用Source.queue(bufferSize)BoundedSourceQueue。它把缓冲满就丢和立即告知结果合并为一次同步调用多线程生产者直接通过无锁有界队列入队避免异步反馈成为 OOM 的放大器需要精确控制丢弃哪个元素丢头/丢尾/丢全部或需要背压backpressure或需要失败快速终止fail→ 用Source.queue(bufferSize, overflowStrategy[, maxConcurrentOffers])并接受异步确认的成本必须恰好处理的场景需要额外警惕两种变体的Enqueued都不保证元素最终被下游消费下游取消或队列fail时缓冲会被丢弃必要时应结合持久化或重试机制兜底生产者数量BoundedSourceQueue面向多线程生产者优化SourceQueue默认单生产者需要并发 offer 时显式调大maxConcurrentOffers且该参数不适用于dropNew。与 throttle 组合限流控制处理速率文档特别推荐将队列与throttle操作符组合使用以把处理速率限制到给定上限。上面的两个示例即为标准用法Source .queueInt .throttle(elementsToProcess, 3.second) // 每 3 秒最多处理 5 个元素 .map(x x * x) .toMat(Sink.foreach(x println(scompleted $x)))(Keep.left) .run()throttle在下游制造节流需求队列据此决定元素是立即发射还是滞留缓冲从而让外部生产者以受控速率被消费——这在对接不可控的外部数据源如传感器、消息队列拉取、用户请求时是控制资源消耗的常用手段。Reactive Streams 语义该操作符的 Reactive Streams 语义文档末尾 callout简洁而明确emits发射当下游存在 demand 且队列中含有元素时completes完成当下游完成时。对应到源码QueueSource与BoundedSourceQueueStage都在onPull下游请求元素时从缓冲区取元素push到下游两者均遵循无需求不发射、有需求才出队的拉模型SourceQueue的complete()对应QueueOfferResult.QueueClosed下游取消则触发缓冲丢弃并失败。实践要点小结缓冲区大小BoundedSourceQueue要求bufferSize 0SourceQueue支持bufferSize 0禁用缓冲元素直接等待下游需求此时溢出策略决定多个待处理元素时的 offer 结果反馈差异同步BoundedSourceQueue适合元素来得比确认快的高负载场景异步SourceQueue的确认本身可能成为 OOM 诱因需要评估确认速率是否跟得上注入速率生命周期管理善用complete()/fail()/watchCompletion()管理队列生命周期下游取消后继续offer只会得到Failure/QueueClosed结果代码即文档上述结论均可回溯到 scaladsl/Source.scala、BoundedSourceQueue.scala 与 QueueSource.scala 的实现与注释示例代码可在 IntegrationDocSpec.scala 与 IntegrationDocTest.java 中直接运行验证。赞分享后端并发编程异步编程【免费下载链接】akka-coreA platform to build and run apps that are elastic, agile, and resilient. SDK, libraries, and hosted environments.项目地址https://gitcode.com/gh_mirrors/ak/akka-core点击查看免费下载相关推荐Akka Streams 的 mapAsync 操作符在保持顺序的同时实现异步并发处理Akka Streams 的 mapAsync 操作符在保持顺序的同时实现异步并发处理 导读 mapAsync 是 Akka Streams 中最重要的异步操后端并发编程异步编程RL4CO社区贡献指南如何参与开源项目开发与维护RL4CO社区贡献指南如何参与开源项目开发与维护 欢迎来到RL4CO社区 这是一个专注于强化学习RL在组合优化CO领域的PyTorch库为研究后端并发编程异步编程Akka Streams scanAsync 操作符详解基于 Future/CompletionStage 的异步累加扫描Akka Streams scanAsync 操作符详解基于 Future/CompletionStage 的异步累加扫描 scanAsync 是 Akka后端并发编程异步编程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考