Scala 并发模型中的 Clojure 期货

Question

在接触了 scala 的 Actors 和 Clojure 的 Futures 之后，我觉得这两种语言对多核数据处理都有很好的支持。

但是，我仍然无法确定两种模型的并发特性和优缺点之间的真正工程差异。这些语言在处理并发进程抽象方面是互补的还是相反的？

其次，关于大数据问题，尚不清楚 scala 社区是否继续明确支持 Hadoop（而 clojure 社区明确支持）。 Scala 开发人员如何与 hadoop 生态系统交互？

Answer 1

代理/参与者可以很好地解决一些解决方案，而有些则不然。这种区别实际上与语言无关，而不仅仅是具体问题如何适应一般的解决方案类别。这是对 Actors/agents 与 References 的（非常简短的）比较，试图阐明该工具必须适合并发问题的观点。

Actor 在不需要同时修改数据的分布式情况下表现出色。如果您的问题可以纯粹通过传递消息来表达，那么演员就会做到这一点。参与者在需要同时修改多个相关数据结构的情况下工作不佳。典型的例子是在银行账户之间转移资金。

Clojure 的refs 很好地解决了许多线程需要同时修改同一事物的问题。他们擅长共享内存多处理器系统，例如当今的 PC 和服务器。除了银行帐户示例之外，Rich Hickey（clojure 的作者）还使用棒球比赛的示例来解释为什么这很重要。如果你想用演员来代表一场棒球比赛，那么在你移动球之前，所有的球迷都必须向它发送一条消息，询问它在哪里……如果他们想看一个球员接球，事情就会变得平衡更复杂。

Clojure 具有 cascalog，这使得编写 hadoop 作业看起来很像编写 clojure。

Answer 2

Actor 提供了一种处理潜在的交错和同步控制的方法，这些控制在尝试让多个线程一起工作时不可避免地会出现。每个参与者都有一个消息队列，它一次按顺序处理一个消息，以避免需要包含显式锁。在这种情况下，Future 提供了一种等待参与者响应的方式。

就 Hadoop 而言，Twitter 刚刚发布了一个专门用于 Hadoop 的库，名为 Scalding，但只要该库是为 JVM 编写的，它就可以使用任何一种语言。