我有兴趣比较各种可扩展性和并发性方法,包括CCR和DSS框架模型.我会特别感兴趣的是与Hadoop和Erlang风格的比较
我查看了CCR,DSS和Erlang,虽然其中,我只将CCR发送到重要的生产代码中.我从来没有看过Hadoop.
Erlang的并发源于它对Actor模型的实现.每个"进程"都有一个邮箱,并从中检索邮件,一次一个.没有消息处理块的进程没有线程.相反,需要完成工作的进程在可用的cpu中进行调度,没有暴露任何底层机制.此外,进程通过消息传递与克隆/不可变性进行通信,确保P1和P2永远不会在逻辑上共享在它们之间传递的消息.
我的感觉是,消息发送和接收的非阻塞特性使Erlang在单个(可能是多核)机器上具有可扩展性的声誉.从本质上讲,有效工作的流程是在可用资源上有效调度的,而静态流程只消耗内存.通过一次处理一条消息,每次保证消息的稳定性,开发人员不再需要担心"竞争条件"之类的问题.
CCR是一组低级异步消息传递原语.其中一个更简单的是接收一个la Erlang.但是有更复杂的原语,例如Join(接收所有某些通道的消息)和Choice(从任何一些通道接收消息),它们可以以有趣的方式嵌套和组合.这些原语也是非阻塞的.接收器生成任务(处理消息)到1..n任务队列,由少量线程提供服务.
我的猜测是,忽略(重要!)平台差异,每个基本任务调度例程基本上都在同一个球场.然而,Erlang是一种语言和一个固定(Actor)模型的平台.CCR既不是这些东西,也只是一个库,你可以更自由地使用/滥用它.
DSS 是一种基于CCR的编程模型.它有服务(Erlang =进程),它要求异步消息传递(默认情况下使用完全克隆)作为服务间通信的唯一形式,外部世界对服务的唯一处理是它的URI(Erlang = PID) .与Erlang一样,调用本地服务和远程服务之间基本没有区别,尽管在后一种情况下会发生(反)序列化.
DSS还具有RESTful模型,这意味着服务通常会公开一组固定且通用的操作,并且服务的状态应被视为由这些操作操纵的资源.与Erlang相比,Erlang可以将任意消息发送到进程.DSS服务可以使用全套CCR原语与其他服务进行通信,这对于分布式分散 - 收集操作等非常有用.
最终,DSS只是一个支持库的框架,而不是一种语言或VM,所以与编写Erlang进程相比,编写甚至单个DSS服务还有更多的"仪式".
在并发性方面,所有这些都提供了编写在多个执行线程下安全有效的代码所需的原语,而不必担心这些执行线程.我认为这是大多数开发人员想要前进的地方.
在可扩展性方面,这是一个更难回答的问题,因为系统设计和使用的工具一样多.您是指单个节点上的可扩展性,即在添加核心时,还是在添加节点时？CCR对后者无话可说.DSS和Erlang都支持相当有效的二进制格式进行有线传输.DSS直接从http继承了它面向资源的世界观,它应该告诉你它的潜在可扩展性,但它在编程模型中有一些限制.
几个技术要点.单个DSS服务比单个erlang进程(300-400字节)消耗更多内存(~2K).此外,每个DSS服务都有自己的任务队列,并且CCR可以有效处理的任务队列数量有一个上限(~10000).我没有Erlang任何这样的上限数字,但怀疑它可能高于此.
说完这一切之后,如果你在.NET平台上,你会认真看待CCR,帮助自己.我发现它非常强大,特别是对于被动事件驱动的程序.
京公网安备 11010802040832号 | 京ICP备19059560号-6 