關(guān)于消息隊列，我們來思考這么幾個問題：

1、MQ為什么再系統(tǒng)中使用？一定要在分布式系統(tǒng)中使用嗎？

2、MQ有哪些中間件？他們有哪些特點？

3、MQ給系統(tǒng)帶來好處的同時有沒有帶來什么問題？如何解決？

一般在我們面試的時候，面試官一般會問如下問題：

1、你的項目中MQ的作用?

2、為什么選擇這款MQ作為消息中間件？

3、重復(fù)消費怎么辦？

4、如何確保消息被消費？

那么接下來，帶著這些問題我來給大家一起分享一些關(guān)于MQ的知識。

一、消息中間件在系統(tǒng)中的作用

MQ在系統(tǒng)中到底有哪些作用呢？拋開基本的消息發(fā)布訂閱不說，還有以下幾點：

1、分布式系統(tǒng)解耦

2、不需要立即返回的業(yè)務(wù)異步處理

3、削峰填谷，不直接訪問服務(wù)，緩解服務(wù)壓力，增加性能

4、日志記錄

分布式系統(tǒng)解耦：

 在分布式系統(tǒng)中，要么是通過rest調(diào)用，要么是通過dubbo等RPC調(diào)用，但是有些場景需要解耦設(shè)計，不能直接調(diào)用，比如消息驅(qū)動的系統(tǒng)中，消息發(fā)送者完成本地業(yè)務(wù)，發(fā)送消息，多平臺的消息消費者服務(wù)需要收到推送的消息，然后繼續(xù)處理其他業(yè)務(wù)。

看這兩個架構(gòu)圖，第一種BC都是直接依賴A服務(wù)，那么如果A中的接口修改，BC都要跟著做修改，耦合度高，第二種，通過MQ來作為中間件接收消息，BC只依賴收到的消息而不是具體的接口，這樣即使A服務(wù)修改或者增加其他服務(wù)，都只要訂閱MQ就行。

不要求實時的業(yè)務(wù)異步處理

以用戶注冊業(yè)務(wù)流程為例：

1、用戶注冊入庫

2、用戶驗證郵件發(fā)送

3、用戶驗證短信發(fā)送

原來的系統(tǒng)設(shè)計，這樣的服務(wù)流程會串行處理，即先1-2-3，但是這里可以思考一下，如果單個服務(wù)單臺機器的情況下，注冊用戶特別多，系統(tǒng)能不能抗??？

這里假設(shè)哥哥階段的時間1=50ms，2=50ms，3=50ms，那么一個請求下來all=150ms，這個再假設(shè)，這個服務(wù)器CPU=1，且只能處理單線程，那么以這種單臺服務(wù)器單線程的QPS來算，QPS=1000/150≈7現(xiàn)在我讓這個QPS*3，提升三陪，這個時候引入MQ服務(wù)作為中間 如圖可見，我在A服務(wù)用戶組測完成后，就直接返回了，這個時候，MQ用來發(fā)送異步處理消息，B、C服務(wù)分別處理，A不用等待B、C的返回結(jié)果，這樣用戶體驗就是只有50ms等待時間，而再郵件、短息這個階段，因為網(wǎng)絡(luò)延遲原因，用戶可以接收一定時間的等待。

削峰填谷

一般的服務(wù)，我們的請求訪問系統(tǒng)都是直接請求，這樣的模式再用戶訪問量不大的情況下，問題不是很大，但是如果用戶請求打到了一定的瓶頸或者產(chǎn)生了一些問題，我們就需要考慮優(yōu)化我們的系統(tǒng)架構(gòu)，MQ中間件正式解決辦法之一。

下面以秒殺系統(tǒng)為例分析問題，秒殺系統(tǒng)瞬間百萬并發(fā)，怎么處理？一般秒殺系統(tǒng)會進行請求過濾，無效、重復(fù)都會被過濾一遍，剩下的才真正進入到秒殺服務(wù)、訂單服務(wù)。但即使這樣并發(fā)仍然很高，如果網(wǎng)關(guān)把全部請求都轉(zhuǎn)發(fā)到下優(yōu)訂單服務(wù)，一樣會壓垮下游系統(tǒng)，造成服務(wù)不可用甚至雪崩

 真實的秒殺系統(tǒng)更復(fù)雜，包含Nginx、網(wǎng)關(guān)、注冊中心、redis緩存、數(shù)據(jù)庫集群、消息隊列集群

解決方式就是將上游處理的較快的任務(wù)，加入到隊列處理，下游逐一消費隊列。直到所有隊列消費完成。加入秒殺服務(wù)處理請求數(shù)：1000/s，下游訂單服務(wù)處理請求為：10/s，為了不給下游訂單服務(wù)造成壓力，秒殺后的信息發(fā)送到隊列，訂單服務(wù)就可以從容淡定的10/s的速度來逐個處理了，而不是直接塞1000哥請求，也不管人家愿不愿意。

到這里，可以總結(jié)下秒殺系統(tǒng)的過濾方式：

1、頁面按鈕點擊一次置灰

2、每秒通過請求數(shù)限制，例如100/s，可以使用Nginx，sentinel

3、過濾同一用戶的重復(fù)請求，通過用戶唯一標識，商品信息。

4、通過消息隊列儲存成功的秒殺信息，下游訂單系統(tǒng)處理

日志

所有服務(wù)都將日期發(fā)送到MQ服務(wù)用來作為日志存儲，MQ作為中間件對日志進行持久化、轉(zhuǎn)發(fā)、大數(shù)據(jù)服務(wù)對MQ讀取和進行日志分析。

二、 MQ怎么選

有人上來就是一通性能比較，然后說RabbitMQ是世界上最好的MQ，你把挑選MQ比作挑老婆吧，上來就要全套，膚白貌美、前凸后翹、性感火辣、勤勞能干……真是缺乏社會的教育啊，兄弟，養(yǎng)的起來嗎？動不動一套保養(yǎng)套餐，1W/月守得住嗎？隔壁老王經(jīng)常來你家吃飯吧，吃得消嗎？紅棗+枸杞+補腎片，怕是心有余而力不足吧。

言歸正傳，其實我覺得這是一個思考題，首先我們要看的應(yīng)該是條件是哪些？

1、用途？用來做日志、解耦、還是異步處理

2、公司情況？人員是否充足，現(xiàn)有人員技術(shù)棧情況、人員的技術(shù)棧實力

3、項目情況？項目周期、人員、用戶量、架構(gòu)設(shè)計、是否老項目

4、主流MQ現(xiàn)狀？穩(wěn)定可靠度、社區(qū)活躍度、文檔全面性、云服務(wù)支持情況

上圖的例子日志消息就是用的kafka，為什么是kafka？kafka是LinkedIn開源的分布式發(fā)布-訂閱消息系統(tǒng)，屬于Apache頂級項目，社區(qū)活越。kafka主要特點是基于Pull的模式來處理消息消費，追求高吞吐量，一開始的目的就是用于日志收集和傳輸，后來版本升級開始支持復(fù)制，不支持事務(wù)，對消息的重復(fù)、丟失、錯誤沒有嚴格要求，適合產(chǎn)生大量數(shù)據(jù)的互聯(lián)網(wǎng)服務(wù)的數(shù)據(jù)收集業(yè)務(wù)。但是kafka相對來說很重要，需要依賴zookeeper，大公司里使用沒有問題，也少不了專人維護。

RocketMQ是案里開源的一套可靠消息系統(tǒng)，已經(jīng)捐贈Apache為頂級項目。剛開始定位于非日志的可靠消息傳輸，其實再日志處理方面性能也不錯。目前支持的客戶端包括java、c++、go，社區(qū)比較活越，文檔還算全面，但是涉及到核心的要修改還是有難度的，畢竟阿里云靠買這個服務(wù)賺錢呢。所以如果公司實例不自信還是慎重選擇吧，實在不行可以直接購買云服務(wù)，省心省力，還是那句話，看實際情況。

三、主流MQ的特點：

四、如何確保消息不被重復(fù)消費

這里簡單說說，后面有時間我會就這個問題詳細說明。大致就是一些特殊原因例如網(wǎng)絡(luò)原因，服務(wù)重啟造成消息消費未被記錄，造成重復(fù)消費的可能，一般的處理方式就是確保接口設(shè)計的冪等性，主旨通過唯一標識判斷是否存在。

1、redis緩存使用，唯一性token保存redis，每次消費后刪除token

2、唯一主鍵判斷，數(shù)據(jù)庫判斷是否存在該逐漸記錄，存在則更新，不存在則插入