2

我有兴趣比较各种可扩展性和并发性方法，包括 CCR 和 DSS 框架模型。我会对与 Hadoop 和 Erlang 风格的并发性进行比较特别感兴趣

4

1 回答 1

9

我看过 CCR、DSS 和 Erlang，尽管其中我只将 CCR 交付到重要的生产代码中。我从来没有看过Hadoop。

Erlang 的并发性源自其对 Actor 模型的实现。每个“进程”都有一个邮箱并从中检索消息，一次一个。没有消息来处理的进程不会阻塞任何线程。相反，有工作要做的进程被安排在可用的 cpu 上，而没有暴露任何底层机器。此外，进程通过具有克隆/不变性的消息传递进行通信，确保 P1 和 P2 永远不会在逻辑上共享它们之间传递的消息。

我的感觉是，正是消息发送和接收的非阻塞特性赋予了 Erlang 在单台（可能是多核）机器上的可扩展性而享有盛誉。从本质上讲，有工作要做的进程在可用资源上被有效地调度，而静止进程只消耗内存。通过一次处理一条消息，每条消息都保证消息的稳定性，开发人员不再需要担心诸如“竞争条件”之类的事情。

CCR 是一组低级异步消息传递原语。其中一个更简单的是 Receive ，它可以接收 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 是对自己有利的。我发现它非常强大，尤其是对于反应式事件驱动程序。

于 2009-05-06T12:02:19.507 回答