大部门下面的测试部在搞大批量的硬件信息数据抓取，这次不能用已经存在客户端，比如 puppet，saltstack，nagios这些个可以扩展的客户端，因为我们要远程的用ipmitool的接口来抓取信息，要是用在client搞的话，还要给他们密码，这个是很不安全的。 so，要搞一套基于自己的一套密码认证及数据抓取的平台。
他们最后决定用gearman，虽然我也用过这东西，但是总感觉缺点啥，用着不顺畅。
其实我个人还是推荐用mq的东西。我用zeromq实现了分布式的任务的派发，性能很是强劲，在可用性上也做了很多的监控。
虽然不能推荐他们用rabbitmq，但我还是把rabbitmq在实际中的小应用，分享出来。希望对大家有些帮助。
rabbitmq redis的对比
rabbitMQ和redis等都可以做队列，但是他们还是有区别的，比如，redis的消息队列，如果在从队列pop出去的时候，worker处理失败的话，数据不会回到队列中，需要从业务中手动把失败的处理数据push到队列中，而rabbmitMQ可以自动处理失败的worker使数据不丢失；rabbitMQ还可以保证数据在传输过程中持久化，在通道和队列中的数据可以设置为持久化。
rabbitmq zeromq的对比
rabbitmq 虽然没有zeromq那样的速度，但是他在一定的程度上提供了更加可靠的mq，有持久化和防止崩溃的处理。
下面还有详细的对比的。
烦人的官方化介绍：
RabbitMQ是实现AMQP（高级消息队列协议）的消息中间件的一种，最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然
先来理解他的一些个专有的名词 ~
概念：
channel:通道，amqp支持一个tcp连接上启用多个mq通信通道，每个通道都可以被作为通信流。
producer：生产者，是消息产生的源头。
exchange：交换机，可以理解为具有路由表的路由规则。
queues：队列，装载消息的缓存容器。
consumer：消费者，连接到队列并取走消息的客户端。
核心思想：在RabbitMQ中，生产者从不直接将消息发送给队列。
事实上，有些生产者甚至不知道消息是否被送到某个队列中去了。生产者只负责将消息送给交换机，而交换机确切地知道什么消息应该送到哪。
bind：绑定，实际上可以理解为交换机的路由规则。每个消息都有一个称为路由键的属性(routing key)，就是一个简单的字符串。一个绑定将【交换机，路由键，消息送达队列】三者绑定在一起，形成一条路由规则。
exchange type：交换机类型：
fanout：不处理路由键，转发到所有绑定的队列上
direct：处理路由键，必须完全匹配，即路由键字符串相同才会转发
topic：路由键模式匹配，此时队列需要绑定要一个模式上。符号“#”匹配一个或多个词，符号“*”匹配不多不少一个词。因此“audit.#”能够匹配到“audit.irs.corporate”，但是“audit.*” 只会匹配到“audit.irs”
关于传说中的性能~
下图是一些个大牛做的综合的测试。
对于rabbitmq zeromq，我自己虽然没有专门的测试，但是实际应用中都有应用的。 zeromq的速度不用质疑，确实很快很快，但是他不做数据的存储持久化和可用性，要是client没有开启的话，他照样会把信息pub出去，不管你存不存在。但是rabbitmq就考虑了很多，看下图大家就知道了。
对头，rabbitmq虽然性能不能和zeromq相比，但是在项目中应用还算不错的。
要是不会安装，请看下图
下面是他所依赖的包~ 看到这个，大家应该知道他是erlang写的吧 ！
RabbitMQ 的详细介绍：请点这里
RabbitMQ 的下载地址：请点这里
推荐阅读：
CentOS 5.6 安装RabbitMQ
用Python尝试RabbitMQ
Ubuntu下PHP + RabbitMQ使用