多核时代:并行程序设计探讨(6)——多机协作(又叫分布式处理)

                                  多机协作(又叫分布式处理)

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

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

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

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

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

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

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

u       没有多机同步机制

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

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

u       没有“老大”

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

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

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

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

 

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

 

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

详细的方案请各位参考COMCORBARMI的相关文档。

 

上一篇:Flutter 强大的MediaQuery控件


下一篇:Flutter 裁剪类组件 最全总结