前言
提高系統性能首先考慮的是數據庫的優化，之前一篇文章《數據庫的使用你可能忽略了這些》中有提到過開發中，針對數據庫需要注意的事項。但是數據庫因為歷史原因，橫向擴展是一件非常復雜的工程，所有我們一般會盡量把流量都擋在數據庫之前。
不管是無限的橫向擴展服務器，還是縱向阻隔到達數據庫的流量，都是這個思路。阻隔直達數據庫的流量，緩存組件和消息組件是兩大殺器。之前文章《Redis常見的應用場景解析》已經描述了最常用的緩存組件redis的應用場景，那么今天，就重點說說MQ的應用場景。
MQ簡介
MQ,Message queue,消息隊列，就是指保存消息的一個容器。具體的定義這里就不類似於數據庫、緩存等，用來保存數據的。當然，與數據庫、緩存等產品比較，也有自己一些特點，具體的特點后文會做詳細的介紹。
現在常用的MQ組件有activeMQ、rabbitMQ、rocketMQ、zeroMQ,當然近年來火熱的kafka,從某些場景來說，也是MQ，當然kafka的功能更加強大，雖然不同的MQ都有自己的特點和優勢，但是，不管是哪種MQ，都有MQ本身自帶的一些特點，下面，咱們就先聊聊MQ的特點。
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的使用場景更多，下面我們逐一說明：
1、注冊后我們可能需要做很多初始化的操作，如：調用郵件服務器發送郵件、調用促銷服務贈送優惠劵、下發用戶數據到客戶關系系統等。那么這時候我們將這些操作去監聽MQ，當用戶注冊成功過后，通過MQ通知其他業務進行操作。確保注冊用戶的性能。
2、后台發布商品的時候，商品數據需要從數據庫中轉換成搜索引擎數據（基於elasticsearch），那么我們應該將商品寫入數據庫后，再寫入到MQ，然后通過監聽MQ來生成elasticsearch對應的數據。
3、用戶下單后，24小時未支付，需要取消訂單。以前我們可能是定時任務循環查詢，然后取消訂單。實際上，我更推薦類似延遲MQ的方式，避免了很多無效的數據庫查詢，將一個MQ設置為24小時后才讓消費者消費掉，這樣很大程度上能減輕服務器壓力。
4、支付完成后，需要及時的通知子系統（進銷存系統發貨，用戶服務積分，發送短信）進行下一步操作，但是，支付回調我們都是需要保證高性能的，所以，我應該直接修改數據庫狀態，存入MQ，讓MQ通知子系統做其他非實時的業務操作。這樣能保證核心業務的高效及時。
注意事項
其實，還有非常多的業務場景，是可以考慮用MQ方式的，但是很多時候，也會存在濫用的情況，我們需要清楚認識我們的業務場景：
發驗證碼短信、郵件，這種過分依賴外部，而且時效性可以接收幾十秒延遲的，其實更好的方式是多線程異步處理，而不是過多依賴MQ。
秒殺搶購確保庫存不為負數，更多的依賴高性能緩存（如redis），以及強制加鎖，千萬不要依賴消費者最終的返回結果。（實際工作中已經看到好幾個這樣的案例了）上游-下游 這種直接的處理方式效率肯定是比 上游-MQ-下游 方式要高，MQ效率高，是因為，我只是上游-MQ 這個階段就當做已經成功了。
總結
任何一個技術的出現，都有他的業務場景，只有清楚技術的特點，才能更加貼切的挖掘出應用場景，深入思考，深入實踐才能將一個技術用在最合適的地方。
歡迎大家關注我的公眾號交流、學習、第一時間獲取最新的文章。
微信號：itmifen
