前言

提高系統(tǒng)性能首先考慮的是數(shù)據(jù)庫的優(yōu)化，之前一篇文章《數(shù)據(jù)庫的使用你可能忽略了這些》中有提到過開發(fā)中，針對數(shù)據(jù)庫需要注意的事項。但是數(shù)據(jù)庫因為歷史原因，橫向擴展是一件非常復雜的工程，所有我們一般會盡量把流量都擋在數(shù)據(jù)庫之前。
不管是無限的橫向擴展服務器，還是縱向阻隔到達數(shù)據(jù)庫的流量，都是這個思路。阻隔直達數(shù)據(jù)庫的流量，緩存組件和消息組件是兩大殺器。之前文章《Redis常見的應用場景解析》已經(jīng)描述了最常用的緩存組件redis的應用場景，那么今天，就重點說說MQ的應用場景。

MQ簡介

MQ,Message queue,消息隊列，就是指保存消息的一個容器。具體的定義這里就不類似于數(shù)據(jù)庫、緩存等，用來保存數(shù)據(jù)的。當然，與數(shù)據(jù)庫、緩存等產(chǎn)品比較，也有自己一些特點，具體的特點后文會做詳細的介紹。
現(xiàn)在常用的MQ組件有activeMQ、rabbitMQ、rocketMQ、zeroMQ,當然近年來火熱的kafka,從某些場景來說，也是MQ，當然kafka的功能更加強大，雖然不同的MQ都有自己的特點和優(yōu)勢，但是，不管是哪種MQ，都有MQ本身自帶的一些特點，下面，咱們就先聊聊MQ的特點。

MQ特點

• 先進先出
  不能先進先出，都不能說是隊列了。消息隊列的順序在入隊的時候就基本已經(jīng)確定了，一般是不需人工干預的。而且，最重要的是，數(shù)據(jù)是只有一條數(shù)據(jù)在使用中。 這也是MQ在諸多場景被使用的原因。
• 發(fā)布訂閱
  發(fā)布訂閱是一種很高效的處理方式，如果不發(fā)生阻塞，基本可以當做是同步操作。這種處理方式能非常有效的提升服務器利用率，這樣的應用場景非常廣泛。
• 持久化
  持久化確保MQ的使用不只是一個部分場景的輔助工具，而是讓MQ能像數(shù)據(jù)庫一樣存儲核心的數(shù)據(jù)。
• 分布式
  在現(xiàn)在大流量、大數(shù)據(jù)的使用場景下，只支持單體應用的服務器軟件基本是無法使用的，支持分布式的部署，才能被廣泛使用。而且，MQ的定位就是一個高性能的中間件。

應用場景

基于上文所述的特點，那么MQ就衍生出了中的使用場景，在大型的系統(tǒng)中，應用非常廣泛，這里我們就列舉一下常見的應用場景。

應用解耦（異步）

image

通知

這里就用到了前文一個重要的特點，發(fā)布訂閱，下游系統(tǒng)一直在監(jiān)聽MQ的數(shù)據(jù)，如果MQ有數(shù)據(jù)，下游系統(tǒng)則會按照 先進先出 這樣的規(guī)則， 逐條進行消費 ，而上游系統(tǒng)只需要將數(shù)據(jù)存入MQ里，這樣就既降低了不同系統(tǒng)之間的耦合度，同時也確保了消息通知的及時性，而且也不影響上游系統(tǒng)的性能。

限流

上文有說了一個非常重要的特性，MQ 數(shù)據(jù)是只有一條數(shù)據(jù)在使用中。 在很多存在并發(fā)，而又對數(shù)據(jù)一致性要求高，而且對性能要求也高的場景，如何保證，那么MQ就能起這個作用了。不管多少流量進來，MQ都會讓你遵守規(guī)則，排除處理，不會因為其他原因，導致并發(fā)的問題，而出現(xiàn)很多意想不到臟數(shù)據(jù)。

數(shù)據(jù)分發(fā)

MQ的發(fā)布訂閱肯定不是只是簡單的一對一，一個上游和一個下游的關(guān)系，MQ中間件基本都是支持一對多或者廣播的模式，而且都可以根據(jù)規(guī)則選擇分發(fā)的對象。這樣上游的一份數(shù)據(jù)，眾多下游系統(tǒng)中，可以根據(jù)規(guī)則選擇是否接收這些數(shù)據(jù)，這樣擴展性就很強了。
PS:上文中的上游和下游，在MQ更多的是叫做生產(chǎn)者（producer）和消費者（consumer）。

分布式事務

分布式事務是我們開發(fā)中一直盡量避免的一個技術(shù)點，但是，現(xiàn)在越來越多的系統(tǒng)是基于微服務架構(gòu)開發(fā)，那么分布式事務成為必須要面對的難題，解決分布式事務有一個比較容易理解的方案，就是二次提交?；贛Q的特點，MQ作為二次提交的中間節(jié)點，負責存儲請求數(shù)據(jù)，在失敗的情況可以進行多次嘗試，或者基于MQ中的隊列數(shù)據(jù)進行回滾操作，是一個既能保證性能，又能保證業(yè)務一致性的方案，當然，這個方案的主要問題就是定制化較多，有一定的開發(fā)工作量。

應用示例

為了更加直觀的展示MQ的應用場景，這里我們就用一個常見的電商系統(tǒng)中的幾個業(yè)務，來具體說明下MQ在實際開發(fā)中應用場景。
我們的實際場景大概是一個基于微服務架構(gòu)的電商系統(tǒng)，分為用戶微服務、商品微服務、訂單微服務、促銷微服務等?；谖⒎漳Ｊ介_發(fā)的系統(tǒng)，MQ的使用場景更多，下面我們逐一說明：
1、注冊后我們可能需要做很多初始化的操作，如：調(diào)用郵件服務器發(fā)送郵件、調(diào)用促銷服務贈送優(yōu)惠劵、下發(fā)用戶數(shù)據(jù)到客戶關(guān)系系統(tǒng)等。那么這時候我們將這些操作去監(jiān)聽MQ，當用戶注冊成功過后，通過MQ通知其他業(yè)務進行操作。確保注冊用戶的性能。
2、后臺發(fā)布商品的時候，商品數(shù)據(jù)需要從數(shù)據(jù)庫中轉(zhuǎn)換成搜索引擎數(shù)據(jù)（基于elasticsearch），那么我們應該將商品寫入數(shù)據(jù)庫后，再寫入到MQ，然后通過監(jiān)聽MQ來生成elasticsearch對應的數(shù)據(jù)。
3、用戶下單后，24小時未支付，需要取消訂單。以前我們可能是定時任務循環(huán)查詢，然后取消訂單。實際上，我更推薦類似延遲MQ的方式，避免了很多無效的數(shù)據(jù)庫查詢，將一個MQ設(shè)置為24小時后才讓消費者消費掉，這樣很大程度上能減輕服務器壓力。
4、支付完成后，需要及時的通知子系統(tǒng)（進銷存系統(tǒng)發(fā)貨，用戶服務積分，發(fā)送短信）進行下一步操作，但是，支付回調(diào)我們都是需要保證高性能的，所以，我應該直接修改數(shù)據(jù)庫狀態(tài)，存入MQ，讓MQ通知子系統(tǒng)做其他非實時的業(yè)務操作。這樣能保證核心業(yè)務的高效及時。

注意事項

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

總結(jié)

任何一個技術(shù)的出現(xiàn)，都有他的業(yè)務場景，只有清楚技術(shù)的特點，才能更加貼切的挖掘出應用場景，深入思考，深入實踐才能將一個技術(shù)用在最合適的地方。