消息传递的性能损失而不是共享数据

use*_*855 8 concurrency erlang transactions distributed-computing

这些天有很多关于不使用锁和使用像Erlang这样的Message传递方法的嗡嗡声.或者关于使用函数式编程与C++/Java之类的不可变数据结构.

但我关心的是以下内容:

  1. AFAIK,Erlang不保证邮件传递.消息可能会丢失.如果您不得不担心消息丢失,那么算法和代码是否会膨胀并再次变得复杂?无论您使用何种分布式算法,都不能依赖于保证的消息传递.
  2. 如果Message是一个复杂的对象怎么办?在复制和发送消息时是否存在巨大的性能损失,而不是将其保留在共享位置(如两个进程都可以访问的数据库)?
  3. 你真的可以完全取消共享国家吗?我不这么认为.例如,在DB中,您必须访问和修改相同的记录.你不能在那里使用消息传递.您需要锁定或采用乐观并发控制机制,然后对错误进行回滚.Mnesia如何运作?
  4. 此外,您并不总是需要担心并发性.任何项目也将有一大块的,不都与在所有并发或交易任何代码(但他们确实有性能和速度的关注).很多这些算法都依赖于共享状态(这就是为什么传递引用或指针非常有用的原因).

鉴于这一事实,在Erlang等中编写程序是一件痛苦的事情,因为你无法做任何这些事情.可能是,它使程序健壮,但是对于诸如解决线性规划问题或计算凸起等问题,性能更重要,并且当它与并发/事务无关时强制算法的不变性等是一个糟糕的决定.不是吗?

jld*_*ont 6

  1. 这就是现实生活:无论语言/平台如何,您都需要考虑这种可能性.在分布式世界(现实世界)中,事情失败了:与之共存.

  2. 当然有成本:宇宙中没有任何东西是免费的.但是你不应该使用另一种媒介(例如文件,数据库)而不是在通信管道中穿梭"大对象"吗?您始终可以使用"消息"来指代存储在某处的"大对象".

  3. 当然不是:函数式编程/ Erlang OTP背后的想法是尽可能" 隔离 "区域"共享状态"被操纵.Futhermore,有明确标示的地方在那里共享状态突变有助于可测试性和可追溯性.

  4. 我相信你错过了重点:没有银弹这样的东西.如果使用Erlang无法成功构建应用程序,则不要这样做.您可以以另一种方式使用整个系统的其他部分,即使用不同的语言/平台.Erlang在这方面与其他语言没有什么不同:使用正确的工具来完成正确的工作.

请记住:Erlang旨在帮助解决并发,异步分布式问题.它没有针对共享内存块高效工作进行优化,例如...除非你计算与nif在游戏的共享块上工作的函数的接口:-)