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

消息隊(duì)列選擇：RabbitMQ & Redis

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

RabbitMQ架構(gòu)：

組件：

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

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

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

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

Queue （隊(duì)列）：一個(gè)存儲(chǔ)Exchange 發(fā)來的消息的緩沖，并將消息主動(dòng)發(fā)送給Consumer，或者 Consumer 主動(dòng)來獲取消息。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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