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