爲何須要消息隊列MQ

主要緣由：是在高併發狀況下，因爲來不及同步處理，請求每每會發生堵塞，好比諸多的insert、update之類的請求同時到達mysql，直接致使無數的行鎖表鎖，甚至最後請求會堆積不少，從而觸發大量的too mang  connnections錯誤。經過消息隊列，咱們能夠異步處理請求，從而緩解系統的壓力。

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

MQ（message queue）是一種跨進程的通訊機制，用於上下游傳遞消息。

mq的特色：

一、先進先出

       不能先進先出，都不能說是隊列了，消息隊列的順序在入隊時基本已經肯定，通常是不須要人工干預的。並且最重要的是，數據是隻有一條數據在使用中，這也是mq在衆多場景中被使用的緣由。

二、發佈訂閱

       發佈訂閱是一種很高效的處理方式，若是不發生阻塞，基本能夠當作是同步操做。這種處理方式能很是有效的提高服務器利用率，這樣的應用場景很是普遍。

三、持久化

       持久化確保MQ的使用不僅是一個部分場景的輔助工具，而是讓MQ能像數據庫同樣存儲核心的數據。

四、分佈式

      在如今大流量、大數據的使用場景下，只支持單體應用的服務器軟件基本是沒法使用的，支持分佈式的部署，才能被普遍使用。並且，MQ的定位就是一個高性能的中間件。

應用場景

基於上文所述的特色，那麼MQ就衍生出了不少的使用場景，在大型的系統中，應用很是普遍，這裏咱們就列舉一下常見的應用場景。

應用解耦（異步） 

系統之間進行數據交互時，在時效性和穩定性之間咱們都要進行選擇；基於線程的異步處理，能確保用戶體驗，但在極端狀況下，可能會出現異常，影響系統的穩定性，而同步調用不少時候沒法保證理想的性能，那麼咱們就能夠用mq來進行處理，上游系統將數據投遞到mq，下游系統取mq的數據進行消費，投遞和消費能夠用同步的方式處理，由於mq接收數據的性能是很是高的，不會影響上游系統的性能，那麼下游系統的及時率能保證嗎？固然能夠，否則就不會有下面的一個應用場景。

通知

 這裏就用到了前文一個重要的特色，發佈訂閱，下游系統一直在監聽MQ的數據，若是MQ有數據，下游系統則會按照 先進先出 這樣的規則， 逐條進行消費 ，而上游系統只須要將數據存入MQ裏，這樣既下降了不一樣系統之間的耦合度，同時也確保了消息通知的及時性，並且也不影響上游系統的性能。

限流

上文有說了一個很是重要的特性，MQ 數據是隻有一條數據在使用中。 在不少存在併發，而又對數據一致性要求高，並且對性能要求也高的場景，如何保證，那麼MQ就能起這個做用了。無論多少流量進來，MQ都會讓你遵照規則，排除處理，不會由於其餘緣由，致使併發的問題，而出現不少意想不到髒數據。

數據分發

MQ的發佈訂閱確定不是隻是簡單的一對一，一個上游和一個下游的關係，MQ中間件基本都是支持一對多或者廣播的模式，並且均可以根據規則選擇分發的對象。這樣上游的一份數據，衆多下游系統中，能夠根據規則選擇是否接收這些數據，這樣擴展性就很強了。
PS:上文中的上游和下游，在MQ更多的是叫作生產者（producer）和消費者（consumer）

分佈式事務

分佈式事務是咱們開發中一直儘可能避免的一個技術點，可是，如今愈來愈多的系統是基於微服務架構開發，那麼分佈式事務成爲必需要面對的難題，解決分佈式事務有一個比較容易理解的方案，就是二次提交。基於MQ的特色，MQ做爲二次提交的中間節點，負責存儲請求數據，在失敗的狀況能夠進行屢次嘗試，或者基於MQ中的隊列數據進行回滾操做，是一個既能保證性能，又能保證業務一致性的方案，固然，這個方案的主要問題就是定製化較多，有必定的開發工做量。

應用示例

爲了更加直觀的展現MQ的應用場景，這裏咱們就用一個常見的電商系統中的幾個業務，來具體說明下MQ在實際開發中應用場景。
咱們的實際場景大概是一個基於微服務架構的電商系統，分爲用戶微服務、商品微服務、訂單微服務、促銷微服務等。基於微服務模式開發的系統，MQ的使用場景更多，下面咱們逐一說明：
一、註冊後咱們可能須要作不少初始化的操做，如：調用郵件服務器發送郵件、調用促銷服務贈送優惠劵、下發用戶數據到客戶關係系統等。那麼這時候咱們將這些操做去監聽MQ，當用戶註冊成功事後，經過MQ通知其餘業務進行操做。確保註冊用戶的性能。
二、後臺發佈商品的時候，商品數據須要從數據庫中轉換成搜索引擎數據（基於elasticsearch），那麼咱們應該將商品寫入數據庫後，再寫入到MQ，而後經過監聽MQ來生成elasticsearch對應的數據。
三、用戶下單後，24小時未支付，須要取消訂單。之前咱們多是定時任務循環查詢，而後取消訂單。實際上，我更推薦相似延遲MQ的方式，避免了不少無效的數據庫查詢，將一個MQ設置爲24小時後才讓消費者消費掉，這樣很大程度上能減輕服務器壓力。
四、支付完成後，須要及時的通知子系統（進銷存系統發貨，用戶服務積分，發送短信）進行下一步操做，可是，支付回調咱們都是須要保證高性能的，因此，我應該直接修改數據庫狀態，存入MQ，讓MQ通知子系統作其餘非實時的業務操做。這樣能保證核心業務的高效及時。

注意事項

其實，還有很是多的業務場景，是能夠考慮用MQ方式的，可是不少時候，也會存在濫用的狀況，咱們須要清楚認識咱們的業務場景：
發驗證碼短信、郵件，這種過度依賴外部，並且時效性能夠接收幾十秒延遲的，其實更好的方式是多線程異步處理，而不是過多依賴MQ。
秒殺搶購確保庫存不爲負數，更多的依賴高性能緩存（如redis），以及強制加鎖，千萬不要依賴消費者最終的返回結果。（實際工做中已經看到好幾個這樣的案例了）上游-下游 這種直接的處理方式效率確定是比 上游-MQ-下游 方式要高，MQ效率高，是由於，我只是上游-MQ 這個階段就當作已經成功了