這篇文章將為大家詳細講解有關MQ對比之RabbitMQ和redis有什么區(qū)別，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

創(chuàng)新互聯(lián)公司專業(yè)為企業(yè)提供普定網(wǎng)站建設、普定做網(wǎng)站、普定網(wǎng)站設計、普定網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、普定企業(yè)網(wǎng)站模板建站服務，十載普定做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡服務。

消息隊列選擇：RabbitMQ & Redis

RabbitMQ

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

RabbitMQ架構：

組件：

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

• Producer（生產(chǎn)者）： 消息的生產(chǎn)者，負責產(chǎn)生消息并把消息發(fā)到交換機Exhange的應用：Consumer （消費者）：使用隊列 Queue 從 Exchange 中獲取消息的應用；

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

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

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

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

Redis

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ù)結構的存儲。

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

---

Redis 優(yōu)勢

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

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

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

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

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

RabbitMQ和Redis的簡單對比

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

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

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

RabbitMQ demo之生產(chǎn)者消費者

生產(chǎn)者

消費者（不發(fā)送ack，模擬程序中斷）

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

正常發(fā)送ack的消費者：

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

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

關于“MQ對比之RabbitMQ和Redis有什么區(qū)別”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。

本文標題：MQ對比之RabbitMQ和Redis有什么區(qū)別
文章鏈接：http://www.aaarwkj.com/article44/pcsohe.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供手機網(wǎng)站建設、網(wǎng)頁設計公司、品牌網(wǎng)站建設、網(wǎng)站內(nèi)鏈、企業(yè)網(wǎng)站制作、電子商務

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)