關於消息隊列，我們來思考這麼幾個問題： 1、MQ為什麼再系統中使用？一定要在分散式系統中使用嗎？ 2、MQ有哪些中間件？他們有哪些特點？ 3、MQ給系統帶來好處的同時有沒有帶來什麼問題？如何解決？ 一般在我們面試的時候，面試官一般會問如下問題： 1、你的項目中MQ的作用? 2、為什麼選擇這款MQ作為 ...
關於消息隊列，我們來思考這麼幾個問題：
1、MQ為什麼再系統中使用？一定要在分散式系統中使用嗎？
2、MQ有哪些中間件？他們有哪些特點？
3、MQ給系統帶來好處的同時有沒有帶來什麼問題？如何解決？
一般在我們面試的時候，面試官一般會問如下問題：
1、你的項目中MQ的作用?
2、為什麼選擇這款MQ作為消息中間件？
3、重覆消費怎麼辦？
4、如何確保消息被消費？
那麼接下來，帶著這些問題我來給大家一起分享一些關於MQ的知識。
一、消息中間件在系統中的作用
MQ在系統中到底有哪些作用呢？拋開基本的消息發佈訂閱不說，還有以下幾點：
1、分散式系統解耦
2、不需要立即返回的業務非同步處理
3、削峰填谷，不直接訪問服務，緩解服務壓力，增加性能
4、日誌記錄
分散式系統解耦：
在分散式系統中，要麼是通過rest調用，要麼是通過dubbo等RPC調用，但是有些場景需要解耦設計，不能直接調用，比如消息驅動的系統中，消息發送者完成本地業務，發送消息，多平臺的消息消費者服務需要收到推送的消息，然後繼續處理其他業務。
看這兩個架構圖，第一種BC都是直接依賴A服務，那麼如果A中的介面修改，BC都要跟著做修改，耦合度高，第二種，通過MQ來作為中間件接收消息，BC只依賴收到的消息而不是具體的介面，這樣即使A服務修改或者增加其他服務，都只要訂閱MQ就行。
不要求實時的業務非同步處理
以用戶註冊業務流程為例：
1、用戶註冊入庫
2、用戶驗證郵件發送
3、用戶驗證簡訊發送
原來的系統設計，這樣的服務流程會串列處理，即先1-2-3，但是這裡可以思考一下，如果單個服務單台機器的情況下，註冊用戶特別多，系統能不能抗住？
這裡假設哥哥階段的時間1=50ms，2=50ms，3=50ms，那麼一個請求下來all=150ms，這個再假設，這個伺服器CPU=1，且只能處理單線程，那麼以這種單台伺服器單線程的QPS來算，QPS=1000/150≈7現在我讓這個QPS*3，提升三陪，這個時候引入MQ服務作為中間 如圖可見，我在A服務用戶組測完成後，就直接返回了，這個時候，MQ用來發送非同步處理消息，B、C服務分別處理，A不用等待B、C的返回結果，這樣用戶體驗就是只有50ms等待時間，而再郵件、短息這個階段，因為網路延遲原因，用戶可以接收一定時間的等待。
削峰填谷
一般的服務，我們的請求訪問系統都是直接請求，這樣的模式再用戶訪問量不大的情況下，問題不是很大，但是如果用戶請求打到了一定的瓶頸或者產生了一些問題，我們就需要考慮優化我們的系統架構，MQ中間件正式解決辦法之一。
下麵以秒殺系統為例分析問題，秒殺系統瞬間百萬併發，怎麼處理？一般秒殺系統會進行請求過濾，無效、重覆都會被過濾一遍，剩下的才真正進入到秒殺服務、訂單服務。但即使這樣併發仍然很高，如果網關把全部請求都轉發到下優訂單服務，一樣會壓垮下游系統，造成服務不可用甚至雪崩
真實的秒殺系統更複雜，包含Nginx、網關、註冊中心、redis緩存、資料庫集群、消息隊列集群
解決方式就是將上游處理的較快的任務，加入到隊列處理，下游逐一消費隊列。直到所有隊列消費完成。加入秒殺服務處理請求數：1000/s，下游訂單服務處理請求為：10/s，為了不給下游訂單服務造成壓力，秒殺後的信息發送到隊列，訂單服務就可以從容淡定的10/s的速度來逐個處理了，而不是直接塞1000哥請求，也不管人家願不願意。
到這裡，可以總結下秒殺系統的過濾方式：
1、頁面按鈕點擊一次置灰
2、每秒通過請求數限制，例如100/s，可以使用Nginx，sentinel
3、過濾同一用戶的重覆請求，通過用戶唯一標識，商品信息。
4、通過消息隊列儲存成功的秒殺信息，下游訂單系統處理
日誌
所有服務都將日期發送到MQ服務用來作為日誌存儲，MQ作為中間件對日誌進行持久化、轉發、大數據服務對MQ讀取和進行日誌分析。
二、 MQ怎麼選
有人上來就是一通性能比較，然後說RabbitMQ是世界上最好的MQ，你把挑選MQ比作挑老婆吧，上來就要全套，膚白貌美、前凸後翹、性感火辣、勤勞能幹……真是缺乏社會的教育啊，兄弟，養的起來嗎？動不動一套保養套餐，1W/月守得住嗎？隔壁老王經常來你家吃飯吧，吃得消嗎？紅棗+枸杞+補腎片，怕是心有餘而力不足吧。
言歸正傳，其實我覺得這是一個思考題，首先我們要看的應該是條件是哪些？
1、用途？用來做日誌、解耦、還是非同步處理
2、公司情況？人員是否充足，現有人員技術棧情況、人員的技術棧實力
3、項目情況？項目周期、人員、用戶量、架構設計、是否老項目
4、主流MQ現狀？穩定可靠度、社區活躍度、文檔全面性、雲服務支持情況
上圖的例子日誌消息就是用的kafka，為什麼是kafka？kafka是LinkedIn開源的分散式發佈-訂閱消息系統，屬於Apache頂級項目，社區活越。kafka主要特點是基於Pull的模式來處理消息消費，追求高吞吐量，一開始的目的就是用於日誌收集和傳輸，後來版本升級開始支持複製，不支持事務，對消息的重覆、丟失、錯誤沒有嚴格要求，適合產生大量數據的互聯網服務的數據收集業務。但是kafka相對來說很重要，需要依賴zookeeper，大公司里使用沒有問題，也少不了專人維護。
RocketMQ是案里開源的一套可靠消息系統，已經捐贈Apache為頂級項目。剛開始定位於非日誌的可靠消息傳輸，其實再日誌處理方面性能也不錯。目前支持的客戶端包括java、c++、go，社區比較活越，文檔還算全面，但是涉及到核心的要修改還是有難度的，畢竟阿裡雲靠買這個服務賺錢呢。所以如果公司實例不自信還是慎重選擇吧，實在不行可以直接購買雲服務，省心省力，還是那句話，看實際情況。
三、主流MQ的特點：
四、如何確保消息不被重覆消費
這裡簡單說說，後面有時間我會就這個問題詳細說明。大致就是一些特殊原因例如網路原因，服務重啟造成消息消費未被記錄，造成重覆消費的可能，一般的處理方式就是確保介面設計的冪等性，主旨通過唯一標識判斷是否存在。
1、redis緩存使用，唯一性token保存redis，每次消費後刪除token
2、唯一主鍵判斷，資料庫判斷是否存在該逐漸記錄，存在則更新，不存在則插入
