RabbitMQ怎么應用

這篇文章將為大家詳細講解有關RabbitMQ怎么應用，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

異步處理

場景：發送手機驗證碼，郵件

傳統古老處理方式如下圖

這個流程，全部在主線程完成，注冊-》入庫-》發送郵件-》發送短信，由于都在主線程，所以要等待每一步完成才能繼續執行。由于每一步的操作時間響應時間不固定，所以主線程的請求耗時可能會非常長，如果請求過多，會導致IIS站點巨慢，排隊請求，甚至宕機，嚴重影響用戶體驗。

現在大多數的處理方式如下圖

這個流程是，主線程依舊處理耗時低的入庫操作，然后把需要處理的消息寫進消息隊列中，這個寫入耗時可以忽略不計，非常快，然后，獨立的發郵件子系統，和獨立的發短信子系統，同時訂閱消息隊列，進行單獨處理。處理好之后，向隊列發送ACK確認，消息隊列整條數據刪除。這個流程也是現在各大公司都在用的方式，以SOA服務化各個系統，把耗時操作，單獨交給獨立的業務系統，通過消息隊列作為中間件，達到應用解耦的目的，并且消耗的資源很低，單臺服務器能承受更大的并發請求。

應用解耦

以電商的下訂單為例子，假設中間的流程為下單=》減庫存=》發貨

第一種方式，通過連續操作表，在單一系統中，通過主線程，連續操作。呵呵噠，這種做法，相信很多人剛入門，甚至幾年經驗了，由于項目小，也在繼續使用吧。用戶量少，或者都是內部人使用，必然沒問題，因為不會在意出的問題，這種做法，只要一個環節出問題，請求直接報錯，導致用戶懵逼，假設在執行到減庫存操作報錯了，整個流程沒有用事務回滾的話，還會造成數據不一致。

第二種方式，把這三個業務，拆成三個獨立系統，通過JSON方式相互調用請求。這個做法，其實已經很不錯了，起碼獨立出來，各自做各自的事情，一定程度上減小了整個系統的耦合性。但是問題是，就算是通過API形式請求，發送請求的系統一般情況下會等待被請求方的響應，如果響應錯了，整個程序還是會終止，前面的業務系統假如已經做了入庫操作，就必須要混滾了。很麻煩。如果說不等待被請求方響應的話，如果出錯，如果還要保證數據一致性，就要做更多的操作，去補全數據，比如，下單成功，減庫存失敗，發貨成功，這樣當減庫存系統修復后，就要通過訂單數據，去補庫存表的對應數據。先對麻煩，難處理。

第三種方式，

把消息隊列作為中間件，當訂單系統下完單后，把數據消息寫入消息隊列中，庫存系統和發貨系統同時訂閱這個消息隊列，思想上和純API系統調用類似，但是，消息隊列RabbitMq本身的強大功能，會幫我們做大量的出錯善后處理，還是，假設下單成功，庫存失敗，發貨成功，當我們修復庫存的時候，不需要任何管數據的不一致性，因為庫存隊列未被處理的消息，會直接發送到庫存系統，庫存系統會進行處理。實現了應用的大幅度解耦。

流量削峰

這個主要用在團購，秒殺活動中

這個主要原理就是，控制隊列長度，當請求來了，往隊列里寫入，超過隊列的長度，就返回失敗，給用戶報一個可愛的錯誤頁的等等。

日志處理

這個場景應該都很熟悉，一個系統有大量的業務需要各種日志來保證后續的分析工作，而且實時性要求不高，用隊列處理再好不過了

消息通訊

現在上線的各大社交通訊項目中，實際上是沒有用消息隊列做即時通訊的，但是它確實可以用來做，有興趣的不妨去試試吧

這個是點對點通信，消費者A和B同時訂閱消息隊列，又同時是制造者，就能實現點對點通信

群聊的做法，所有客戶端同時訂閱隊列，又同時是發送，制造者。

區別

上述大致的5種RabbitMq的應用場景，下面來介紹幾個消息隊列的區別

ActiveMq:這個應用于JAVA中間件較多

ZeroMq:這個是分發效率最高的隊列，是其他隊列的十倍以上，缺點是不能數據持久化。

kafka：這是一種高吞吐量的發布訂閱消息系統，當每秒達到10W+的分發要求時，可以用這個嘗試，新浪微博就是用這個做分發。

RabbitMQ 上的一個 queue 中存放的 message 是否有數量限制？

可以認為是無限制，因為限制取決于機器的內存，但是消息過多會導致處理效率的下降。

RabbitMQ 概念里的 channel、exchange 和 queue 這些東東是邏輯概念，還是對應著進程實體？這些東東分別起什么作用？

queue 具有自己的 erlang 進程；exchange 內部實現為保存 binding 關系的查找表；channel 是實際進行路由工作的實體，即負責按照 routing_key 將 message 投遞給 queue 。由 AMQP 協議描述可知，channel 是真實 TCP 連接之上的虛擬連接，所有 AMQP 命令都是通過 channel 發送的，且每一個 channel 有唯一的 ID。一個 channel 只能被單獨一個操作系統線程使用，故投遞到特定 channel 上的 message 是有順序的。但一個操作系統線程上允許使用多個 channel 。channel 號為 0 的 channel 用于處理所有對于當前 connection 全局有效的幀，而 1-65535 號 channel 用于處理和特定 channel 相關的幀。AMQP 協議給出的 channel 復用模型如下

其中每一個 channel 運行在一個獨立的線程上，多線程共享同一個 socket。

關于“RabbitMQ怎么應用”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。