Scala的并发模型环境下的Clojure期货

Question

嗨，大家好：在接触scala的Actors和Clojure的期货后，我觉得这两种语言都对多核数据处理有极好的支持。

但是，我仍然无法确定两个模型的并发特性和优缺点之间的真实工程差异。这些语言在处理并发流程抽象方面是互补的还是反对的？其次，关于大数据问题，Scala社区明确继续支持Hadoop（而clojure社区明确这么做）还不清楚。 Scala开发人员如何与hadoop生态系统进行交互？

对这两个问题的任何见解将不胜感激。

Answer 1

参与者提供了一种处理潜在的交织和同步控制的方法，当试图让多个线程一起工作时，交互和同步控制是不可避免的。每个actor都有一个消息队列，它按顺序逐个处理，以避免需要包含显式锁。在这种情况下，Future提供了一种等待演员响应的方式。

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

Answer 2

一些解决方案很好地由代理商/参与者解决，有些则不是。这种区别不是关于语言超过如何具体问题适合一般类别的解决方案。这是演员/代理人与参考文献（非常短）的比较，试图澄清该工具必须适合并发问题的观点。

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

Clojure的ref s是一个很好的解决方案，很多线程需要同时修改同一个东西。它们擅长共享内存多处理器系统，如今天的个人电脑和服务器。除了银行账户的例子，Rich Hickey（clojure的作者）使用棒球比赛的例子来解释为什么这很重要。如果您想用演员代表棒球比赛，那么在您移动球之前，所有球迷都必须发送一条消息，询问它是在哪里的......如果他们想要看球员接球，那么球甚至会得到更复杂。

Clojure有cascalog，这使得写作hadoop的工作看起来很像写作clojure。