我有一个用例,我想向外部系统发送消息,但是发送此消息的流程需要并返回我不能在下游使用的类型。这是传递流程的绝佳用例。我正在使用实现here。最初,我担心如果processingFlow使用mapAsyncUnordered,那么该流程将无法正常工作。由于处理流程可能会重新排序消息,并且zip可能会推出带有不正确对的元组。例如,在以下示例中。
val testSource = Source(1 until 50)
val processingFlow: Flow[Int, Int, NotUsed] = Flow[Int].mapAsyncUnordered(10)(x => Future {
Thread.sleep(Random.nextInt(50))
x * 10
})
val passThroughFlow = PassThroughFlow(processingFlow, Keep.both)
val future = testSource.via(passThroughFlow).runWith(Sink.seq)
我希望处理流程可以相对于其输入重新排序其输出,并且我将得到如下结果:
[(30,1), (40,2),(10,3),(10,4), ...]
使用右侧(通过始终始终按顺序排列),但通过我的mapAsyncUnordered的左侧可能与不正确的元素结合在一起,从而构成错误的元组。
实际上,我得到了:
[(10,1), (20,2),(30,3),(40,4), ...]
每次。经过进一步调查,我发现代码运行缓慢,尽管我的地图异步无序,但实际上根本没有并行运行。我尝试在异步边界前后引入一个缓冲区,但是它似乎总是按顺序运行。这解释了为什么总是订购但我希望我的处理流程具有更高的吞吐量。
我想出了以下解决方法:
object PassThroughFlow {
def keepRight[A, A1](processingFlow: Flow[A, A1, NotUsed]): Flow[A, A, NotUsed] =
keepBoth[A, A1](processingFlow).map(_._2)
def keepBoth[A, A1](processingFlow: Flow[A, A1, NotUsed]): Flow[A, (A1, A), NotUsed] =
Flow.fromGraph(GraphDSL.create() { implicit builder => {
import GraphDSL.Implicits._
val broadcast = builder.add(Broadcast[A](2))
val zip = builder.add(ZipWith[A1, A, (A1, A)]((left, right) => (left, right)))
broadcast.out(0) ~> processingFlow ~> zip.in0
broadcast.out(1) ~> zip.in1
FlowShape(broadcast.in, zip.out)
}
})
}
object ParallelPassThroughFlow {
def keepRight[A, A1](parallelism: Int, processingFlow: Flow[A, A1, NotUsed]): Flow[A, A, NotUsed] =
keepBoth(parallelism, processingFlow).map(_._2)
def keepBoth[A, A1](parallelism: Int, processingFlow: Flow[A, A1, NotUsed]): Flow[A, (A1, A), NotUsed] = {
Flow.fromGraph(GraphDSL.create() { implicit builder =>
import GraphDSL.Implicits._
val fanOut = builder.add(Balance[A](outputPorts = parallelism))
val merger = builder.add(Merge[(A1, A)](inputPorts = parallelism, eagerComplete = false))
Range(0, parallelism).foreach { n =>
val passThrough = PassThroughFlow.keepBoth(processingFlow)
fanOut.out(n) ~> passThrough ~> merger.in(n)
}
FlowShape(fanOut.in, merger.out)
})
}
}
两个问题:
答案 0 :(得分:3)
您目睹的行为是broadcast
和zip
的工作方式的结果:broadcast
在其所有输出均表示需求时向下游发射; zip
等待其所有输入,然后发出需求信号(并向下游发射)。
broadcast.out(0) ~> processingFlow ~> zip.in0
broadcast.out(1) ~> zip.in1
考虑上图中第一个元素(1
)的移动。 1
同时广播到processingFlow
和zip
。 zip
立即收到其输入之一(1
),并等待其其他输入(10
),这将花费更长的时间。仅当zip
同时获得1
和10
时,它才会从上游拉取更多元素,从而触发第二个元素(2
)在流中移动。依此类推。
至于您的ParallelPassThroughFlow
,我不知道为什么您觉得“有些不对劲”。