前言：
大部門下面的測試部在搞大批量的硬件信息數據抓取，這次不能用已經存在客戶端，比如 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寫的吧 ！
更多詳情見請繼續閱讀下一頁的精彩內容： http://www.linuxidc.com/Linux/2013-11/92591p2.htm
RabbitMQ 的詳細介紹：請點這裡
RabbitMQ 的下載地址：請點這裡