当所有异步任务故障转移超过阈值时停止所有异步任务?

Question

我正在使用MonixTask进行异步控制。

场景

1. 任务并行执行
2. 如果发生故障超过 X 次
3. 停止所有尚未处于完成状态的任务(越快越好(

我的解决方案

我提出了在 1. 结果和 2. 错误计数器之间比赛的想法，并取消失败者。
通过Task.race，如果错误计数器首先达到阈值，则任务将被取消Task.race.

实验

在菊石REPL 上

{
import $ivy.`io.monix::monix:3.1.0`
import monix.eval.Task
import monix.execution.atomic.Atomic
import scala.concurrent.duration._
import monix.execution.Scheduler
//import monix.execution.Scheduler.Implicits.global
implicit val s = Scheduler.fixedPool("race", 2) // pool size
val taskSize = 100
val errCounter = Atomic(0)
val threshold = 3
val tasks = (1 to taskSize).map(_ => Task.sleep(100.millis).map(_ => errCounter.increment()))
val guard = Task(f"stop because too many error: ${errCounter.get()}")
.restartUntil(_ => errCounter.get() >= threshold)
val race = Task
.race(guard, Task.gather(tasks))
.runToFuture
.onComplete { case x => println(x); println(f"completed task: ${errCounter.get()}") }
}

---

问题

结果取决于线程池大小！？

对于池大小 1
，结果几乎总是任务成功，即没有停止。

Success(Right(.........))
completed task: 100 // all task success !

对于池大小 2，
成功和失败之间的不确定性非常不确定，并且取消不准确。 例如：

Success(Left(stop because too many error: 1))
completed task: 98

取消最迟在 98 个任务完成时。
错误计数小到阈值很奇怪。

默认全局调度程序将获得相同的结果行为。

对于池大小 200
，它更具确定性，并且停止时间更早，因此在完成的任务较少的意义上更准确。

Success(Left(stop because too many error: 2))
completed task: 8

池大小越大越好。

---

如果我将Task.gather更改为Task.sequence执行，则所有问题都消失了！

---

这种对池大小的依赖的原因是什么？ 如何改进它，或者一旦发生太多错误，是否有更好的选择来停止任务？

Answer 1

您所看到的可能是Monix调度程序及其旨在实现公平性的效果。这是一个相当复杂的主题，但文档和 scaladocs 非常出色(参见：https://monix.io/docs/3x/execution/scheduler.html#execution-model(

当你只有一个(或几个(线程时，需要一段时间才能"守卫"任务轮到另一个轮到检查。使用Task.gather，您可以一次启动 100 个任务，因此调度程序非常繁忙，"守卫"无法再次检查，直到其他任务已经完成。 如果每个任务有一个线程，则调度程序无法保证公平性，因此"守卫"会更频繁地不公平地检查并且可以更快地完成。

如果您使用Task.sequence这 100 个任务将按顺序执行，这就是为什么"守卫"任务有更多机会在需要时尽快完成的原因。如果你想保持你的代码原样，你可以使用Task.gatherN(parallelism = 4)这将限制并行性，从而允许你的"守卫"更频繁地检查(Task.sequence和Task.gather之间的中间地带(。

对我来说，这似乎有点像 Go 代码(使用 Go 的select之类的Task.race(，而且您还使用了不受约束的副作用，这进一步使理解正在发生的事情变得复杂。我试图以一种更惯用的方式重写你的程序，对于复杂的并发性，我通常会使用像Observable这样的流：

import cats.effect.concurrent.Ref
import monix.eval.Task
import monix.execution.Scheduler
import monix.reactive.Observable
import scala.concurrent.duration._
object ErrorThresholdDemo extends App {
//import monix.execution.Scheduler.Implicits.global
implicit val s: Scheduler = Scheduler.fixedPool("race", 2) // pool size
val taskSize  = 100
val threshold = 30
val program = for {
errCounter <- Ref[Task].of(0)
tasks = (1 to taskSize).map(n => Task.sleep(100.millis).flatMap(_ => errCounter.update(_ + (n % 2))))
tasksFinishedCount <- Observable
.fromIterable(tasks)
.mapParallelUnordered(parallelism = 4) { task =>
task
}
.takeUntilEval(errCounter.get.restartUntil(_ >= threshold))
.map(_ => 1)
.sumL
errorCount <- errCounter.get
_          <- Task(println(f"completed tasks: $tasksFinishedCount, errors: $errorCount"))
} yield ()
program.runSyncUnsafe()
}

如您所见，我不再使用全局可变副作用，而是Ref内部也使用Atomic，但提供了一个我们可以与Task一起使用的功能 api。 出于演示目的，我还将阈值更改为 30，只有其他所有任务都会"出错"。因此，无论线程池大小如何，预期的输出始终在completed tasks: 60, errors: 30左右。

我仍在使用轮询errCounter.get.restartUntil(_ >= threshold)这可能会消耗太多的 CPU 以满足我的口味，但它接近您的原始想法并且效果很好。

通常，我不会预先创建任务列表，而是将输入放入可观察对象并在.mapParallelUnordered中创建任务。此代码保留您的列表，这就是为什么不涉及实际映射的原因(它已经包含任务(。

您可以选择所需的并行度，就像使用Task.gatherN一样，这是非常好的imo。

如果还有什么不清楚的，请告诉我:)