多机协作（又叫分布式处理）

嗯，费了九牛二虎之力，终于将Windows和Linux对比完了。你是否准备伸个懒腰，喝杯热咖啡，听点音乐来放松一下呢？

别急，革命尚未成功，同志还需努力，铁还得趁热打。还记得第二篇博文里面总结的两种并行实现技术没有？一个是“多进程多线程”，另一个是“多机协作”，到目前为止我们基本上只把“多进程多线程”分析完毕了，还有另外一个“多机协作”没有分析，本篇我们就探讨一下“多机协作”这种实现机制。

不过事先申明，由于“多机协作”这种实现机制范围太广：小到普通的双机、中到模拟地球运算的大型机或者巨型机、又如Google这样NB的公司发明的分布式文件系统、再到现在热热闹闹的“云计算”、或者大家最常用的BT、电骡等P2P技术都属于这一范畴，且实现太过复杂，不同的系统实现机制也相差很大，限于本人能力，只能“蜻蜓点水”了，如有兴趣研究，推荐《分布式系统概念与设计》这本书，我也没有读过，不过据说还不错。

幸运的是“多机协作”实现机制和“多核编程”并没有什么关系，因此即使蜻蜓点水对大家的多核设计水平影响不大。

废话了半天，让我们转到正题上。虽然前面提到了“多机协作”范围很广，实现机制也各不相同，但既然大家都划到“多机协作”这一类里面，自然有一些基因是相同的。那么就让我们对“多机协作”进行一次基因图谱制作，看看究竟有哪些共同基因。

u       只有一种通信方式：消息。

是的，看到这个不要惊讶，虽然实现形式可以多种多样，但本质上来说，多机协作系统只有一种通信方式：消息。不管是基于TCP/IP的Socket消息，还是基于电信网7号信令的MAP消息，还是内部光纤通信的XX消息，本质上这些都是消息通信。和“多进程多线程”多种多样的方式来比，显得有点单薄，因此也就增大了设计的难度。

u       没有多机同步机制

看到这个是不是更加吃惊？但现实就是如此残酷，多机协作没有一个现成可用的同步机制来实现诸如互斥、事件、信号量等同步功能。

但实际应用中你的应用又不得不用到这些东东，例如Google的分布式文件系统，因此你要自己去实现这些东东，这也增大了设计的难度。

u       没有“老大”

这里的老大不是指黑社会的老大哈，相反它是一个好公仆，这个“老大”负责全局的事物管理。嗯，你可能会说“多进程多线程”里面也没有老大的啊？

多进程多线程之间确实没有天然的老大，谁当老大完全是由我们设计人员决定的，但还有一个我们无法决定的老大：操作系统！操作系统在“多进程多线程”实现机制里面完成了众多我们没有怎么关注但却不得不用到的功能：进程线程创建、调度、隔离、通信、同步等。

在“多机协作”实现机制中，唯一的老大就是我们设计人员！你要决定如何隔离、如何调度、如何通信、如何同步等所有这些事情，因此设计难度又上一层楼！

举个最简单的例子：多进程多线程实现机制中，时间或者时钟都是操作系统来控制和提供；而在多机协作中，光一个时间或者时钟同步就能让你累个半死！！

 

看完上面的初步分析，我们可以得出一个这样的结论：多机协作只有一个消息通信，然后要基于消息通信来实现同步、通信、管理、调度、分布式处理等所有你所需要的功能！所以“多机协作”要比“多进程多线程”设计复杂得多。

 

看到这里，你是否泄气了呢？本着“不抛弃，不放弃”的精神，我们还是要勇敢面对，而且幸好现在也有很多多机协作的解决方案了。流行的有三个：微软的COM/DCOM、ORG的CORBA、SUN的Java RMI。这些多机协作（或者叫分布式）方案封装了很多底层的通信、调用、同步等机制，使得我们能够简单的实现多机协作。

详细的方案请各位参考COM、CORBA、RMI的相关文档。