2.1.3　基于消息中枢的计算模式

由于Fourinone提供简单MQ的支持，因此包工头和工人之间的交互也可以以消息中枢的模式进行，包工头将需要工人执行的任务/命令/消息发送到消息中枢，工人监听消息中枢上各自的消息队列，一旦自己的队列有新内容，便接收执行任务，各个工人以并行的方式进行，如图2-3所示。

图2-3　消息中枢模式

如果要支持消息中枢模式，在Fourinone里只需要修改一个配置即可，在config.xml配置文件里：

<PROPSROW DESC="COMPUTEMODE">
        <MODE DESC="DEFAULT">0</MODE>
        <MODE>1</MODE>
</PROPSROW>

可以看到默认的计算模式选项为0，代表工头工人直接交互模式（下章会介绍），如果将默认改为1，便是消息中枢模式。

提示

对于开发者来说，实现程序上一行代码都不用改动，doTask和giveTask仍然按照实现的内容执行，只不过它们背后的交互机制完全不同，模式0是直接交互，模式1是把任务发到消息中枢上交互。

消息中枢模式的优点：最直接的优点就是包工头机器和工人机器可以互相不可见，可以互相网络不通，只要它们都跟消息中枢机器能连接即可。比如我们一个网吧或者一个公司的机器，可以访问外面的互联网服务器，但是互联网服务器却不能直接连接到局域网网关内的每台机器，那么使用模式0的方式肯定连接不了，使用模式1消息中枢是最好的方式，因为如果包工头在另外一个局域网网络里，那么公共的互联网服务器是大家都可以连接的，但是包工头和工人却无法直接连接。比如每日访问淘宝网站的有几千万用户PC机，他们可以直接连接淘宝服务器，但是反过来淘宝的工头程序无法连接到每台用户PC，如果能使用消息中枢模式利用用户这几千台PC做一次并行计算，将产生一个巨大的计算能力。

消息中枢模式的缺点：所有的任务发送到消息中枢来实现异步传递，消息中枢本身很容易形成瓶颈，因为它只有一台机器，容量有限，也容易形成故障单点，很明显，太大数据的任务或者太频繁、太多的消息请求都对它的性能有严重影响，它只适合数量不多连续性质的增量消息，但是不适合各种并行计算场景，特别是输入输出数据庞大，并且耗费网络带宽很大的计算，比如我们下面的2.3节还会谈及MPI方式的并行计算。

所有的任务通过消息中枢中转而不是直接交互，数据多了一个中转环节，经过我们测试，显然速度上不如直接交互的计算快。

消息中枢模式意味着包工头无法直接对工人进行各种复杂点的计算控制，因为这两者隔离开来了，所以框架很多高级功能支持（比如避免工人任务重复调用、工人任务中止或者超时中止、工人网络波动抢救期设置等等）在消息中枢模式下使用不了，以及我们下一节会谈到工人和工人之间传递数据也使用不了。消息中枢模式只能完成最简单基本的计算。

因此，框架默认和推荐的方式是直接交互模式，该模式几乎能完成所有的分布式并行计算需求了，只有工头/工人无法直接连接的网络环境才考虑使用消息中枢模式。