消息隊列做用（解耦、異步、削峯）圖詳解

本篇是初次學習消息隊列整理的一些筆記，分享給初學者，祝你們學有所獲。數據庫

消息隊列概念
服務器

MQ全稱爲Message Queue,消息隊列（MQ）是一種應用程序對應用程序的通訊方法。應用程序經過讀寫出入隊列的消息（針對應用程序的數據）來通訊，而無需專用鏈接來連接它們。
消息傳遞指的是程序之間經過在消息中發送數據進行通訊，而不是經過直接調用彼此來通訊，直接調用一般是用於諸如遠程過程調用的技術。排隊指的是應用程序經過隊列來通訊。隊列的使用除去了接收和發送應用程序同時執行的要求。

消息隊列中間件是分佈式系統中重要的組件，主要解決應用耦合，異步消息，流量削鋒等問題架構

傳統作法
- 傳統的作法是，訂單系統調用庫存系統的接口。以下圖：
- 傳統模式的缺點：假如庫存系統沒法訪問，則訂單減庫存將失敗，從而致使訂單失敗，訂單系統與庫存系統耦合

如何解決以上問題呢？異步

使用消息隊列
- 引入應用消息隊列後的方案，以下圖：
  
  分佈式
- 訂單系統：用戶下單後，訂單系統完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功學習
- 庫存系統：訂閱下單的消息，採用拉/推的方式，獲取下單信息，庫存系統根據下單信息，進行庫存操做spa
- 在下單時庫存系統不能正常使用。也不影響正常下單，由於下單後，訂單系統寫入消息隊列就再也不關心其餘的後續操做了。實現訂單系統與庫存系統的應用解耦.3d

舉個新例子：
日誌

好比說某一個系統A要與其餘系統打交道（即調用其中的方法），若是其它系統改變或者新增系統，那麼A系統都會改變，這樣的話耦合度比較高，比較麻煩。code

使用消息隊列來解決這個問題。

咱們A系統將產生的數據發入消息隊列中，其它的系統再去消息隊列來進行消費，那麼其餘系統的減小或者新增系統即與A系統關係不大了，這樣來實現解耦的功能。

場景說明：用戶註冊後，須要發註冊郵件和註冊短信

傳統作法
- a.串行：將註冊信息寫入數據庫成功後，發送註冊郵件，再發送註冊短
- b.並行：將註冊信息寫入數據庫成功後，發送註冊郵件的同時，發送註冊短信
使用消息隊列
- 將不是必須的業務邏輯，異步處理。改造後的架構以下：

舉個新例子

某一個用戶使用系統A，可是A要調用系統B,C,D,可是每個系統返回的時間是不同的，你必需要等待所有返回後才能夠響應用戶。

若是咱們這裏採用消息隊列，當用戶發送請求後，咱們把數據傳給消息隊列，而後再直接響應給用戶我已經發送了信息。

場景說明：商品秒殺業務，通常會由於流量過大，致使流量暴增，應用掛掉

舉個新例子

好比日常用戶的請求咱們會直接訪問數據庫，在大量用戶過來的時候，這樣的話咱們會對數據庫照常比較大的壓力

在這裏咱們增長一個消息隊列，這樣的話無論你請求來多少，我先存入消息隊列，而後我再讓系統慢慢的處理你的請求（如右圖），這樣很好的減緩了數據庫的訪問壓力。

消息通信是指，消息隊列通常都內置了高效的通訊機制，所以也能夠用在純的消息通信。好比實現點對點消息隊列，或者聊天室等

日誌處理是指將消息隊列用在日誌處理中，好比Kafka的應用，解決大量日誌傳輸的問題

使用消息隊列完成日誌處理
- 日誌採集客戶端，負責日誌數據採集，定時寫受寫入Kafka隊列
- Kafka消息隊列，負責日誌數據的接收，存儲和轉發
- 日誌處理應用：訂閱並消費kafka隊列中的日誌數據

一、系統可用性下降：
系統可用性在某種程度上下降，爲何這樣說呢？在加入MQ以前，你不用考慮消息丟失或者說MQ掛掉等等的狀況，可是，引入MQ以後你就須要去考慮了！

二、系統複雜性提升：
加入MQ以後，你須要保證消息沒有被重複消費、處理消息丟失的狀況、保證消息傳遞的順序性等等問題！

三、一致性問題:
我上面講了消息隊列能夠實現異步，消息隊列帶來的異步確實能夠提升系統響應速度。可是，萬一消息的真正消費者並無正確消費消息怎麼辦？這樣就會致使數據不一致的狀況了。

The best investment is to invest in yourself

2020.05.16 記錄辰兮的第66篇博客