摘要：消息隊列選擇是一個由開發(fā)的的開源實現(xiàn)的產(chǎn)品，是一個消息代理，從生產(chǎn)者接收消息并傳遞消息至消費者，期間可根據(jù)規(guī)則路由緩存持久化消息。綁定隊列和交換機之間的關(guān)系。根據(jù)消息的屬性和的屬性來轉(zhuǎn)發(fā)消息。

消息隊列選擇：RabbitMQ & Redis

RabbitMQ是一個由erlang開發(fā)的AMQP（Advanced Message Queue ）的開源實現(xiàn)的產(chǎn)品，RabbitMQ是一個消息代理，從“生產(chǎn)者”接收消息并傳遞消息至“消費者”，期間可根據(jù)規(guī)則路由、緩存、持久化消息?！吧a(chǎn)者”也即message發(fā)送者以下簡稱P，相對應(yīng)的“消費者”乃message接收者以下簡稱C，message通過queue由P到C，queue存在于RabbitMQ，可存儲盡可能多的message，多個P可向同一queue發(fā)送message，多個C可從同一個queue接收message

RabbitMQ架構(gòu)：

組件：

Message （消息）：RabbitMQ 轉(zhuǎn)發(fā)的二進制對象，包括Headers（頭）、Properties （屬性）和 Data （數(shù)據(jù)），其中數(shù)據(jù)部分不是必要的；

Producer（生產(chǎn)者）： 消息的生產(chǎn)者，負責(zé)產(chǎn)生消息并把消息發(fā)到交換機Exhange的應(yīng)用；

Consumer （消費者）：使用隊列 Queue 從 Exchange 中獲取消息的應(yīng)用；

Exchange （交換機）：負責(zé)接收生產(chǎn)者的消息并把它轉(zhuǎn)到到合適的隊列；

Queue （隊列）：一個存儲Exchange 發(fā)來的消息的緩沖，并將消息主動發(fā)送給Consumer，或者 Consumer 主動來獲取消息。

Binding （綁定）：隊列 和 交換機 之間的關(guān)系。Exchange 根據(jù)消息的屬性和 Binding 的屬性來轉(zhuǎn)發(fā)消息。綁定的一個重要屬性是 binding_key。

Connection （連接）和 Channel （通道）：生產(chǎn)者和消費者需要和 RabbitMQ 建立 TCP 連接。一些應(yīng)用需要多個connection，為了節(jié)省TCP 連接，可以使用 Channel，它可以被認為是一種輕型的共享 TCP 連接的連接。連接需要用戶認證，并且支持 TLS (SSL)。連接需要顯式關(guān)閉。

Redis 是完全開源免費的，遵守BSD協(xié)議，是一個高性能的key-value數(shù)據(jù)庫。

Redis 與其他 key - value 緩存產(chǎn)品有以下三個特點：

Redis支持數(shù)據(jù)的持久化，可以將內(nèi)存中的數(shù)據(jù)保存在磁盤中，重啟的時候可以再次加載進行使用。

Redis不僅僅支持簡單的key-value類型的數(shù)據(jù)，同時還提供list，set，zset，hash等數(shù)據(jù)結(jié)構(gòu)的存儲。

Redis支持數(shù)據(jù)的備份，即master-slave模式的數(shù)據(jù)備份。

性能極高 – Redis能讀的速度是110000次/s,寫的速度是81000次/s 。

豐富的數(shù)據(jù)類型 – Redis支持二進制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數(shù)據(jù)類型操作。

原子 – Redis的所有操作都是原子性的，意思就是要么成功執(zhí)行要么失敗完全不執(zhí)行。單個操作是原子性的。多個操作也支持事務(wù)，即原子性，通過MULTI和EXEC指令包起來。

豐富的特性 – Redis還支持 publish/subscribe, 通知, key 過期等等特性。

首先Redis的設(shè)計是用來做緩存的，但是由于它自身的某種特性使得他可以用來做消息隊列(Redis的List數(shù)據(jù)結(jié)構(gòu)比較適合做MQ)。它有幾個阻塞式的API可以使用，正是這些阻塞式的API讓他有做消息隊列的能力。 另外做消息隊列的其他特性，例如FIFO也很容易實現(xiàn)，只需要一個list對象從頭取數(shù)據(jù)，從尾部塞數(shù)據(jù)即可實現(xiàn)。 Redis能做消息隊列得益于它的list對象blpop brpop接口以及Pub/Sub(發(fā)布/訂閱)的某些接口。他們都是阻塞版的，所以可以用來做消息隊列。

RabbitMQ和Redis都可以做隊列，但是他們還是有區(qū)別的。比如，Redis的消息隊列，如果在從隊列pop出去的時候，worker處理失敗的話，數(shù)據(jù)不會回到隊列中，需要從業(yè)務(wù)中手動把失敗的處理數(shù)據(jù)push到隊列中；而RabbitMQ可以自動處理失敗的worker使數(shù)據(jù)不丟失；RabbitMQ還可以保證數(shù)據(jù)在傳輸過程中持久化，在通道和隊列中的數(shù)據(jù)可以設(shè)置為持久化。首先Redis嚴(yán)格來說并不是消息隊列，它是一個內(nèi)存數(shù)據(jù)庫，不過因為其某些特性適合用來充當(dāng)隊列，所以也多被用于做簡單的mq, Redis之父倒是開發(fā)了個真正的消息隊列disque，有興趣可以看看。

相比起Redis，RabbitMQ有更加完善的MQ機制，這里我們僅討論消息的durable（持久性），后續(xù)一系列其他機制有時間再交流。

RabbitMQ有一個消息確認機制來保證消息的不丟失：客戶端從隊列中取出消息之后，可能需要一段時間才能處理完成，如果在這個過程中，客戶端出錯了，異常退出了，而數(shù)據(jù)還沒有處理完成，那么非常不幸，這段數(shù)據(jù)就丟失了，因為RabbitMQ默認會把此消息標(biāo)記為已完成，然后從隊列中移除，消息確認是客戶端從RabbitMQ中取出消息，并處理完成之后，會發(fā)送一個ack告訴RabbitMQ，消息處理完成，當(dāng)RabbitMQ收到客戶端的獲取消息請求之后，或標(biāo)記為處理中，當(dāng)再次收到ack之后，才會標(biāo)記為已完成，然后從隊列中刪除。當(dāng)RabbitMQ檢測到客戶端和自己斷開鏈接之后，還沒收到ack，則會重新將消息放回消息隊列，交給下一個客戶端處理，保證消息不丟失，也就是說，RabbitMQ給了客戶端足夠長的時間來做數(shù)據(jù)處理。

no-ack ＝ False，如果消費者遇到情況(its channel is closed, connection is closed, or TCP connection is lost)掛掉了，那么，RabbitMQ會重新將該任務(wù)添加到隊列中。

發(fā)送ack則被認為是正常消費message的consumer，則RabbitMQ會把message從隊列中移除，此時再看隊列中已經(jīng)沒有消息。

關(guān)于RabbitMQ的其他features，如 Publish/Subscribe、Routing、Topics和RPC等，有興趣可以Google。除了RabbitMQ除了Python的實踐外，也可考慮其他語言的實踐，這里提供另外一個語言golang的選擇，可參考Ubuntu14.04+RabbitMQ3.6.3+Golang的最佳實踐，這個文章講的非常詳盡，實踐意義比較具有參考價值，有興趣可以閱覽一番。