RabbitMq應用一的補充（RabbitMQ的應用情境）

標籤：報錯   長度   目的   bsp   耦合   image   com   style   中介軟體   

直接進入正題。

一.非同步處理

情境：發送手機驗證碼，郵件

傳統古老處理方式如

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

現在大多數的處理方式如

這個做法是主線程只做耗時非常短的入庫操作，發送郵件和傳送簡訊，會開啟2個非同步線程，扔進去並存執行，主線程不管，繼續執行後續的操作，這種處理方式要遠遠好過第一種處理方式，極大的增強了請求響應速度，使用者體驗良好。缺點是，由於非同步線程裡的操作都是很耗時間的操作，一個請求要開啟2個線程，而一台標準配置的ECS伺服器支撐的並發線程數大概在800左右，假設一個線程在10秒做完，這個單個伺服器最多能支援400個請求的並發，後面的就要排隊。出現這種情況，就要考慮增加伺服器做負載，尷尬的增加成本。

訊息佇列RabbitMq的處理方式

 

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

二.應用解耦

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

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

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

第三種方式，

 

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

三.流量削峰

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

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

四.Tlog

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

五.訊息通訊

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

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

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

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

上述大致的5種RabbitMq的應用情境，下面來介紹幾個訊息佇列的區別

ActiveMq:這個應用於JAVA中介軟體較多

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

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

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

 

RabbitMq應用一的補充（RabbitMQ的應用情境）