问题标签 [quasar]

我最近读到了Quasar，它为 JVM 提供了“轻量级”/类似 Go 的“用户模式”线程（它也有一个受 Erlang 启发的 Actor 系统，比如 Akka，但这不是主要问题）

例如：

据我了解，上面的代码不会产生任何 JVM / 内核线程，所有这些都是在用户模式线程中完成的（或者他们声称），这应该更便宜（如果我理解正确的话，就像 Go 协程一样）

我的问题是 - 据我了解，在 Akka 中，一切仍然基于 JVM 线程，大多数情况下映射到本机 OS 内核线程（例如 POSIX 系统中的 pthreads），例如据我所知有没有用户模式线程/像 Akka 中的协同程序/轻量级线程一样，我理解正确吗？

如果是这样，那么您知道这是否是一种设计选择吗？或者未来在 Akka 中是否有类似 go 的轻量级线程的计划？

我的理解是，如果你有一百万个 Actor，但其中大多数是阻塞的，那么 Akka 可以用更少的物理线程来处理它，但是如果它们中的大多数是非阻塞的，你仍然需要系统的一些响应（例如服务百万个小请求流式传输一些数据）然后我可以看到用户模式线程实现的好处，它可以允许更多的“线程”以较低的创建切换和终止的成本存活（当然唯一的好处是平均分配响应许多客户，但响应能力仍然很重要）

我的理解或多或少是正确的？如果我错了，请纠正我。

_{*我可能完全将用户模式线程与 go/co-routines 和轻量级线程混淆了，上面的问题依赖于我对它们都是相同的理解不足。}

I wish to use Quasar in my SBT project. Since Scala is not yet supported the only viable option left is to have SBT compile some java classes that use of Quasar.

I tried putting

and

as I read that for using e.g. JRebel one must insert both these statements into build.sbt

But it does not seem to work either as using a Quasarish class (QuasarExample) yields:

A piece of code that's expected to be running without errors after successful instrumentation:

See also this repository for a starter.

假设我需要在同一个线程中执行N个任务。这些任务有时可能需要来自外部存储的一些值。我事先不知道哪个任务可能需要这样的值以及何时。一次获取M个值比向外部存储的M个查询中获取相同的M个值要快得多。

请注意，我不能指望任务本身的合作，它们只能被视为 java.lang.Runnable 对象。

现在，在我看来，理想的程序看起来像

1. 循环执行所有任务。如果一个任务请求一个外部值，记住这一点，暂停 任务并切换到下一个。
2. 一次获取上一步请求的值。
3. 删除所有已完成的任务（暂停的不计为已完成）。
4. 如果还有任务，则转到步骤 1，但不是执行任务，而是从挂起状态继续执行。

据我所知，“暂停”和“恢复”某事的唯一方法是从 JVM 堆栈中删除其相关帧，将它们存储在某个地方，然后将它们推回堆栈并让 JVM 继续。

是否有任何标准（不涉及比 JVM 字节码更低级别的黑客攻击）方法来做到这一点？

或者您能否提出另一种可能的方法来实现这一点（除了启动N个线程或使任务以某种方式合作）？

我正在尝试安装 Pulsar。我有 lein 版本

我设置了 JAVA_HOME

当我在 git cloned 目录上执行 lein midje 时，我得到了一堆错误。不知道我做错了什么？我怀疑这与首先正确安装java Quasar有关，但我不确定。

所以我下载了Quasar的git repo。首先使用 apt-get 安装系统 gradle，然后在 quasar 目录中运行 gradle。这给了我一个不同的错误：

我一直在尝试在我的应用程序中使用 Quasar 光纤，但我想知道这个库是否不适合 Android JVM。

我在我的build.gradle：

运行构建时，我在 gradle 控制台中得到以下输出：

我被卡住了，有人知道我该怎么办吗？这甚至可以工作吗？

据我所知，最常见的 JVM 并发 API 之一：futures - 至少在 scala 中实现 - 依赖用户代码在线程可能处于空闲状态时放弃它。在 scala 中，它通常被称为“避免阻塞”，开发人员必须在任何有意义的地方实现它。效率不高。

JVM 是否有一些完全固有的东西，可以防止 JVM 将线程的上下文切换到新任务 - 当线程空闲时 - 由操作系统进程调度程序实现？

据我所知，在Akka中，所有参与者都安排在一个线程池上。太多actor同时执行阻塞IO，每个阻塞调用阻塞一个线程，导致线程中断。

现在我正在研究 JVM 上的一个有趣的光纤实现——Quasar，它允许大量用户线程——光纤——并使用线程池来调度它们。但是，我想知道当许多纤程调用遗留阻塞 API 时是否有好处。

我不认为这会有所帮助，因为阻塞 API 仍然会阻塞系统线程，并且 Quasar 无法神奇地将其转换为仅阻塞光纤。这只是我的猜测，如果我错了，请纠正我。

我正在寻找优化当前使用 HTTP/REST 进行内部节点到节点通信的微服务架构。

一种选择是在服务中实现背压功能，（例如）通过将类似 Quasar 的东西集成到堆栈中。这无疑会改善情况。但我看到了一些挑战。一种是，异步客户端线程是瞬态的（在内存中），并且在客户端失败（崩溃）时，这些重试线程将丢失。第二，理论上，如果目标服务器宕机一段时间，客户端最终可能会到达 OOM 尝试重试，因为线程最终是有限的，甚至是 Quasar Fibers。

我知道这有点偏执，但我想知道基于队列的替代方案在非常大的规模上是否更有利。

它仍然可以像 Quasar/fibers 一样异步工作，除了 a) 队列是集中管理的，并且脱离客户端 JVM，b) 队列可以是持久的，因此在客户端和/或目标服务器出现故障时，没有飞行中的消息丢失了。

当然，排队的缺点是有更多的跃点，它会减慢系统的速度。但我认为可能存在一个甜蜜点，即 Quasar ROI 达到峰值，集中且持久的队列对于扩展和 HA 变得更加重要。

我的问题是：

是否讨论过这种权衡？是否有关于使用集中式外部队列/路由器方法进行服务内通信的论文。

TL;博士; 我刚刚意识到我可以将这个问题表述为：

“什么时候适合在微服务架构中使用基于消息总线的服务内通信而不是直接 HTTP。”

我一直在阅读一些东西，发现了一些真正让我的想法混乱的库，比如 Akka、Quasar、Reactor 和 Disruptor，Akka 和 Quasar 实现了 Actor 模式，而 Disruptor 是一个线程间消息传递库，而 Reactor 是基于. 那么与简单的方法调用相比，使用消息驱动架构的优势和用例是什么？

给定一个 RabbitMQ 队列侦听器，我从该方法接收一条消息，决定 RabbitMQ 消息是哪个 Type ( NewOrder, Payment,...)。

使用消息驱动库，我可以做到。

伪代码：

actor.tell('decider-mailbox',message)

基本上是说“我把这个消息放在这里，当你们可以处理它时，做它”）等等，直到它被保存。并且actor再次准备好接收另一条消息

但是像这样直接调用方法messageHandler.handle(message)，不是更好，更不抽象吗？

我在 Kotlin 中使用 Quasar 并开始使用主题和频道。我正在关注一些 Java 示例并编写了一个小片段。不幸的是，我似乎无法让它工作。它只是阻塞主线程并等待。我不太确定 join 正在做什么，想知道这是否是问题所在？

编辑：