并发已不再是语言层面上的事情了

原文链接  译者:张军 校对:方腾飞

本文将并发和内存管理做了个类比。最近有一个说法是因为现代工程师几乎总是面对计算机集群编程,所以我们需要用于构建分布式系统的工具。这就意味着我们需要在语言层面支持分布式系统开发。像GO和Erlang这样的语言其优势正好符合这个观点。

GO和Erlang可能最终会流行,但我不认为是这个原因。分布式系统开发并不会成为每个应用开发者日常工作的一部分,因为那将会是件非常痛苦的事情。在某种程度上,我想今天发生的事情是因为缺乏良好的分布式计算框架,而迫使应用去重新实现一些分布式系统原语。但这种情况不会一直存在,而必将有一些框架提供不同的编程模型,在弹性机器池上处理分布和并发问题。

MapReduce已经解决了这个问题。MapReduce编程几乎都是单线程的,并发是由框架来管理,另外有助于你写好MapReduce程序的原因是,有很多用户级别(user-level)的并发原语,并且MapReduce是高度并行的。

这不是个新事物,即使是Java servlets,其所有的缺陷主要是因为抽象了线程模型,但是至少对于应用程序来说只需要通过阻塞I/O与一个数据库进行交互。

我觉得有三大基本领域需要处理:在线,近实时和离线。

  • 在线领域,我们创建请求/响应式服务,并行性是通过将每个请求的处理当作一个工作单元,划分到不同的线程和机器。我见过该模型的多个变种,从“服务查询语言”到将REST调用拼接在一起的DSLs,它们的共同点就是抽象并发的处理,而不需要像线程一样直接访问单个服务器的并发机制。
  • 在近实时处理领域,流处理框架做的很好,通过异步处理而根本不用考虑并发。而且你关心的并发和并行只在框架层面,你写的代码看起来完全是单线程的。
  • 离线领域似乎为了不同的目标朝着YARN框架 (校对注:YARN框架介绍)的方向发展。

几乎所有这些框架的共同点是它们都不需要用户直接管理并发。

我认为这些高层次的领域(在线,异步和离线)将被证明会长期存在,但是我不认为我们需要十几个基础分布式计算框架来涵盖这些领域。

这让我花了很多时间来思考,在语言层面支持单机并发(软件事务内存和其他)效果是有限的。它只会帮助框架的实现者而不是最终用户。相比应用开发者,框架实现者会有一些非常不同的需求,他们更关心性能和细粒度的控制。尽管这显然是一个有争议的说法,我不确定线程和锁对框架开发者来说是否是一个可行的模型,毕竟,对于一个受训过的团队它们做的非常好,并有出色的性能和控制能力。

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 并发已不再是语言层面上的事情了


张军

张军,并发编程网译者,互联网研发工程师,对并发编程,分布式计算,NoSQL,Erlang,后端架构,IM即时通信感兴趣,可通过cool_breeze@163.com跟我联系^_^

Latest posts by 张军 (see all)

FavoriteLoading添加本文到我的收藏
  • Trackback 关闭
  • 评论 (3)
    • 阿明
    • 2014/08/07 9:42上午

    博主 总结的很好 提供一些代码实例就更赞了。

  1. “The last thing that would help you write good MapReduce programs is more user-level concurrency primitives.”

    原文中这句话表达的意思是:更多用户级并发编程”原语”并不能帮助我们编写出好的MapReduce程序,恰恰相反,我们已经有太多(足够多)并发编程”原语”了,真正缺的是更高层次的抽象框架。

      • 张军
      • 2014/08/10 2:48下午

      感谢关注,看文章此高层次的抽象框架就是MapReduce,同时它还提供了很多用户级别的并发“原语”来帮助我们写出更好的MapReduce程序;

您必须 登陆 后才能发表评论

return top