RabbitMq應用一的補充（RabbitMQ的應用場景）

直接進入正題。

一.異步處理

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

傳統古老處理方式以下圖

這個流程，所有在主線程完成，註冊-》入庫-》發送郵件-》發送短信，因爲都在主線程，因此要等待每一步完成才能繼續執行。因爲每一步的操做時間響應時間不固定，因此主線程的請求耗時可能會很是長，若是請求過多，會致使IIS站點巨慢，排隊請求，甚至宕機，嚴重影響用戶體驗。

如今大多數的處理方式以下圖

這個作法是主線程只作耗時很是短的入庫操做，發送郵件和發送短信，會開啓2個異步線程，扔進去並行執行，主線程無論，繼續執行後續的操做，這種處理方式要遠遠好過第一種處理方式，極大的加強了請求響應速度，用戶體驗良好。缺點是，因爲異步線程裏的操做都是很耗時間的操做，一個請求要開啓2個線程，而一臺標準配置的ECS服務器支撐的併發線程數大概在800左右，假設一個線程在10秒作完，這個單個服務器最多能支持400個請求的併發，後面的就要排隊。出現這種狀況，就要考慮增長服務器作負載，尷尬的增長成本。

消息隊列RabbitMq的處理方式

 

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

二.應用解耦

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

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

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

第三種方式，

 

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

三.流量削峯

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

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

四.日誌處理

這個場景應該都很熟悉，一個系統有大量的業務須要各類日誌來保證後續的分析工做，並且實時性要求不高，用隊列處理再好不過了

五.消息通信

如今上線的各大社交通信項目中，其實是沒有用消息隊列作即時通信的，可是它確實能夠用來作，有興趣的不妨去試試吧

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

羣聊的作法，全部客戶端同時訂閱隊列，又同時是發送，製造者。

-------------------------------------------------------------------------------------------------------------------------------------------------------------

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

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

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

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

先寫這麼多吧，大體的應用場景，歡迎各路大神來補充，我也是公司須要，學習整理出來的，可能會有理解誤差，見諒哈！