MySpace 解释他们是如何使用并发与协调运行时的

CCR，即并发与协调运行时，一开始是.NET 机器人工具箱的一部分。由于许多公司在大量非机器人的项目中使用了CCR，MySpace 也在他们的项目中采用了这一框架。

CCR 使用消息传递机制来隔离应用程序的不同部分。在低层实现中，精细管理的线程和任务窃取队列（work-stealing queue）比传统的线程和锁少了很多开销。

MySpace 在它们的通信层使用 CCR，使用了基于原生 Socket 的自定义格式。每个服务器使用两个队列，第一个用作单向的消息，而第二个则用于处理那些需要立即得到回复的同步消息。每个服务器都可以调整分配给两种队列的线程数量。

他们的缓存集群构建在通信层之上，每台机器包含一个存储组件以及一个用于处理的组件集合。当一个单向消息达到时，它直接进入第三个 CCR 队列，然后再传递到存储组件以及订阅至特定消息类型的某个处理组件中。除了跳过“缓冲”队列以外，同步消息的处理方式与此类似。

MySpace 使用 CCR，是由于它提供了比传统线程池高得多的吞吐量。其中一个原因是.NET 线程池在确定保留多少线程方面有过大的开销。此外，线程之间的上下文切换也耗费了可观的时间。CCR 使用了为每个 CPU 分配单个线程的做法避免了很多此类问题。为了对线程有更多控制，MySpace 还扩展了 CCR，这样他们就可以在运行时动态改变分配给队列的线程数量了。

每个节点除了应对每秒进入的数千条消息之外，它也要处理对外的消息。为此他们使用了 CCR 的多重接受器和一些其他的模式，这样每次便可以使用“等待 100 个消息或 500 毫秒”的方式来对外批量发送数据了。据 MySpace 的说法，这种模式是移动大量数据的基础。

在采用 CCR 之前，MySpace 使用.NET 线程池或手动管理线程。他们声称在之前并不知道有其他线程管理的替代方式，直到有一天，他们在解决内部实现问题的时候碰巧遇上了类似的宣传用例，于是便开始使用 CCR 了。

目前，MySpace 在他们的 1200 台中间层服务器和 3000 台 Web 服务器上使用了 CCR。MySpace 经常会在他们的框架中自然地融入额外的东西，以至于许多开发人员并没有意识到其中的改变。

你可以在 Channel 9 中浏览 Erik Nelson 和 Akash Patel 对 MySpace 的采访。更多有关 CCR 的信息，请访问 CCR and DSS Toolkit 2008 R2 。

查看英文原文： MySpace Explains How They Use the Concurrency and Coordination Runtime