使用 Play Frameworks Enumerators、Iteratees 和 Enumeratees 与使用 RxScalas Observables、Subscriptions 等进行异步数据流相比如何？
在什么类型的场景下你会选择使用 RxScala，什么时候会选择 Play？
如果您有大数据流过您的流，那会影响您的决定吗？
问问题
507 次
2 回答
3
这取决于你想做什么。如果您想进行组合器样式解析，迭代器就会发光。它们非常简单——它们有一个称为 fold 的方法，迭代器、枚举器和枚举器中的其他所有内容都只是调用折叠的东西。但是对于许多人来说，流处理的函数式方法对于学习它们来说是一种过多的心理投资，因此诸如 RX 之类的命令式方法可能更合适。出于这个原因，Play 本身正在转向 Akka 流。
于 2015-07-01T12:25:04.760 回答
2
这个问题很有趣，因为它比较了做同一件事的两种完全不同的方式。在 EPFL 的 Martin Odersky 的一个项目中，我一直在研究这些库的差异。
请注意，这项工作是在 Play 迁移到 Akka 流之前完成的，所以当我们看现在和未来时，James Roper 的反应很好。但是，由于您确实在询问两者之间的差异，因此我可以尝试在此处提供见解。
如果您熟悉面向对象的编程（大多数时候都是这样），那么 Rx 很容易使用。Play iteratee 来自纯粹的函数世界（参见Haskell Enumerator 和 Iteratee）并且不太直观。因此，同一个应用程序的编写是非常不同的。但是，可以在 Iteratees 和 Observables 之间进行映射（参见下面的 GitHub 链接）。但它有它的极限。
我们可以确定的主要问题是 Iteratees 本身支持背压而 Observables 不支持。事实上，如果数据流太大，Rx 会将数据存储在对象中（即堆栈上）。在这种情况下，这可能会很快导致内存问题。但是，由于 Iteratee 是纯函数式的，因此每条数据都将被折叠操作中的函数消耗。从这个意义上说，如果第一个元素仍未被消耗（该函数仍然不存在！），则无法将第二个元素提供给 Iteratee。这就是我们所说的背压，因为数据生产者对消费率有一个概念，并且流量问题会传播回数据生产者。
作为结论，如果您对这两个库都非常满意并且想要在两者之间进行选择，您可以考虑应用程序的用途。如果你永远不会有大流量，你可以使用 Rx。在另一种情况下，我建议使用 Iteratees。
对 Akka Streams 中的背压有一个想法会很有趣。原生，因为它是一个消息传递库，问题应该和 Rx 一样。但是，该领域似乎有一些有趣的工作，例如这篇文章，使用 TCP 来规避问题。
在这里查看GitHub或全文：Observables for Play！
于 2015-07-22T16:53:10.067 回答