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

消息隊列選擇：RabbitMQ & Redis

RabbitMQ是一個由erlang開發的AMQP（Advanced Message Queue ）的開源實現的產品，RabbitMQ是一個消息代理，從“生產者”接收消息并傳遞消息至“消費者”，期間可根據規則路由、緩存、持久化消息。“生產者”也即message發送者以下簡稱P，相對應的“消費者”乃message接收者以下簡稱C，message通過queue由P到C，queue存在于RabbitMQ，可存儲盡可能多的message，多個P可向同一queue發送message，多個C可從同一個queue接收message

RabbitMQ架構：

組件：

Message （消息）：RabbitMQ 轉發的二進制對象，包括Headers（頭）、Properties （屬性）和 Data （數據），其中數據部分不是必要的；

Producer（生產者）： 消息的生產者，負責產生消息并把消息發到交換機Exhange的應用；

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

Exchange （交換機）：負責接收生產者的消息并把它轉到到合適的隊列；

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

Binding （綁定）：隊列 和 交換機 之間的關系。Exchange 根據消息的屬性和 Binding 的屬性來轉發消息。綁定的一個重要屬性是 binding_key。

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

Redis 是完全開源免費的，遵守BSD協議，是一個高性能的key-value數據庫。

Redis 與其他 key - value 緩存產品有以下三個特點：

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

Redis不僅僅支持簡單的key-value類型的數據，同時還提供list，set，zset，hash等數據結構的存儲。

Redis支持數據的備份，即master-slave模式的數據備份。

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

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

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

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

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

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

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

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

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

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

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