(30 hackdays day 7) Iron.io + beantalk - 来颗铁豆

前面说到我打算用PubNub实现爬虫模块之间通信，但PubNub有一个比较麻烦的问题就是不能像MessageQueue那样实现异步消息传递。虽然PubNub也提供history()这样的函数可以封装为MQ的样子，但始终是有点文不对题的意思。
所以我决定再找一个MessageQueue的服务来做这事儿。以前我用过RabbitMQ，但那个毕竟要自己搭建服务。所以决定尝试一下另一个MessageQueue的Service Provider

Iron.io

Iron.io提供一系列用于Scale的服务，IronMQ (message queue)，IronWorker (其实这才是重头戏), IronCache (呃 就是cache)。
这次我们只用message queue。Iron.io使用的是自家的IronMQ，2011年得到过$1.1M Citrix的投资。Iron.io做了一个compare table来跟其他MQ做比较。主要的优势体现在scalability上，就是各种能轻易扩大规模，换句话说，就是等你做大了只要多交钱就好啦～

Naked Message Queue

用过RabbitMQ的人都应该对它SDK封装的程度印象深刻（简单说就是超好用）。而IronMQ的特点就是...赤裸裸...至少Nodejs的SDK是这样。 node SDK提供的接口里最让人不爽的就是Retrieve message的部分。一次只能get一条消息，然后一旦没有消息就得到一个empty message的callback。虽然get可以设置一个wait，让它不立刻返回。但wait最多也就等30秒。所以如果要做一个简单的Daemon来接受消息就还要做一些循环封装（弄点儿Timeout啥的）。
作为一个这么懒的人，这咋行呢！按以往的习惯，这时候应该已经开始寻找替代品了。但...我交了5刀...所以...

Beanstalk Interface

为了5刀，一条条翻看Document，突然发现了个好玩的东西：Beanstalk Interface。稍微一搜发现这玩意儿正是我要的！（有没有想起JavaBean...）

Beanstalk is a simple, fast work queue.

Beanstalk是个抽象设计，所以有各种语言的实现。一一翻看Nodejs部分的Client。
NPM里的repo可以看到每天的下载量，这就给开发者一个很好的选择标准。我的标准是这样 NPM downloads > Github watch > Github fork > Github last update time。fivebeans和nodestalker，最后决定用后者，因为更新时间比较近。

Watchman

测试了一下nodestalker的watch以后，发现似乎它的实现是同步的，会导致整个node项目无法处理新的request。而nodejs默认来说每个Process就一个thread，所以如果要在一个项目里同时监控message以及随时可以发送message的话，就得单起一个Process。worker.js是我的一个用来放watch process的文件。

var childProcess = require("child_process");
this._retrieveChild = childProcess.fork("worker.js");

Iron.io的服务需要认证，而认证的方式似乎比较奇怪：连上Queue以后先发一个Message，里面包含认证信息。

var authJob = client.put('oauth ' + MQ_TOEN + ' ' + MQ_PROJECT_ID);

在这个Job完成以后就可以做事儿啦～

抱怨

因为nodestalker用的是大名鼎鼎的mikeal的request。而因为受到AVOS的熏陶，写点儿啥都想用Promise。但...丫就是不支持！还看到一个牛逼哄哄的回复

你丫就得搭金字塔，你丫就得...哎...所以我就搜Promise Request mikeal。发现一坨坨的...Promisify大有“互联网思维”的范儿。

Sample Source code