Concurrency CCR&；DSS工具包模型与其他可扩展性的比较；一致性方法？

我感兴趣的是比较各种可伸缩性和并发性方法，包括CCR和DSS框架模型。我对与Hadoop和Erlang风格的Concurrency进行比较特别感兴趣，我已经研究了CCR、DSS和Erlang，尽管其中我只将CCR发布到重要的生产代码中。我从来没有看过Hadoop

Erlang的并发性源于它对Actor模型的实现。每个“进程”都有一个邮箱并从中检索邮件，一次一个。没有消息处理的进程没有线程。相反，有工作要做的进程是跨可用cpu调度的，底层机器都不暴露。此外，进程通过消息传递与克隆/不变性进行通信，确保P1和P2从不在逻辑上共享它们之间传递的消息

我的感觉是，正是消息发送和接收的非阻塞特性使Erlang在单核（可能是多核）机器上具有良好的可伸缩性。本质上，有工作要做的进程是跨可用资源高效调度的，静态进程只消耗内存。通过一次处理一条消息，每一条消息都保证了消息的稳定性，开发人员不再需要担心诸如“竞争条件”之类的事情

CCR是一组低级异步消息传递原语。其中一个比较简单的是Receive，它执行Receive-a-la-Erlang。但是还有更复杂的原语，比如Join（接收来自所有通道的消息）和Choice（接收来自任何通道的消息），它们可以以有趣的方式嵌套和组合。这些原语也是非阻塞的。接收者将任务（处理消息）生成到1..n个任务队列中，这些队列由少量线程提供服务

我的猜测是，忽略（重要的！）平台差异，每个平台的基本任务调度例程基本上在同一个球场上。然而，Erlang是一种语言，是一个嵌入了固定（参与者）模型的平台。CCR不是这两种东西，它只是一个图书馆，你可以更自由地使用/滥用它

DSS是一种基于CCR的编程模型。它有服务（Erlang=processs），它强制异步消息传递（默认情况下为完全克隆）作为服务间通信的唯一形式，外部世界对服务的唯一处理是其URI（Erlang=PID）。与Erlang一样，调用本地服务和远程服务基本上没有区别，尽管（反）序列化发生在后一种情况下

DSS还有一个RESTful模型，这意味着服务通常公开一组固定的公共操作，并且服务的状态应该被认为是由这些操作操纵的资源。与Erlang相比，Erlang可以向进程发送任意消息。DSS服务可以在与其他服务对话时使用全套CCR原语，这对于分布式分散-聚集操作非常有用

最终，DSS只是一个支持库的框架，而不是一种语言或VM，因此编写一个DSS服务所涉及的“仪式”要比编写Erlang进程多得多

就并发性而言，它们都提供了编写在多个执行线程下安全高效的代码所需的原语，而不必担心这些执行线程。我认为这是大多数开发者想要的方向

就可伸缩性而言，这是一个很难回答的问题，因为这既是系统设计的问题，也是所使用的工具的问题。您是指单个节点上的可伸缩性，即添加核心时，还是添加节点时？CCR对后者无话可说。DSS和Erlang都支持相当高效的二进制格式进行有线传输。DSS直接从http继承其面向资源的世界视图，这应该告诉您一些关于其潜在可伸缩性的信息，但它在编程模型中有一些限制

有几个技术要点。单个DSS服务比单个erlang进程（300-400字节）消耗更多内存（~2K）。此外，每个DSS服务都有自己的任务队列，CCR可以有效处理的任务队列数量有一个上限（~10000）。我没有关于Erlang的任何此类上限的数字，但我怀疑它可能会高于这个上限

---

说了这么多，如果你在.NET平台上，那么认真地看一下CCR就是在帮你自己的忙。我发现它非常强大，特别是对于被动事件驱动的程序。

与CCR的+1相关。我发现它非常有帮助，并且非常值得陡峭的（ish）学习曲线。+1对于CCR来说也是如此，但是，与学习适当的多线程技术和.net的APM模型相比，学习曲线算不了什么。如果你做了大量的并行，帮你自己一个忙，检查CCR。