在單體應(yīng)用中获枝，我們常常使用簡單的數(shù)據(jù)結(jié)構(gòu)——隊(duì)列蠢正，來解決一些實(shí)際問題，比如生產(chǎn)者消費(fèi)者模式使用隊(duì)列作為中間傳輸省店。在復(fù)雜的分布式環(huán)境中嚣崭，簡單隊(duì)列是無法解決分布式環(huán)境一定存在的問題，比如應(yīng)用之間的通信萨西、消息持久化有鹿、消息傳輸控制等等問題。消息隊(duì)列又能解決那些問題呢谎脯？
1.異步處理
舉個例子：在商城系統(tǒng)中葱跋，訂單系統(tǒng)下單成功后，需要一些后處理源梭，比如扣減庫存娱俺、統(tǒng)計(jì)銷售數(shù)量、短信通知废麻、消息推送荠卷、優(yōu)惠卷占用等等。如果所有這些操作都是同步處理烛愧，那下單耗時(shí)非常嚴(yán)重油宜，影響用戶體驗(yàn)×耍可以利用消息隊(duì)列將這些同步操作改為向各個系統(tǒng)發(fā)送消息慎冤，接口直接返回訂單信息。
2. 流量控制（削峰填谷）
我們的應(yīng)用處理請求能力是有限沧卢，在一些存在海量請求的場景中蚁堤，比如秒殺、搶購等等但狭。如果直接處理這海量請求披诗，可能我們的應(yīng)用早掛掉了。這時(shí)候可以把這些請求丟進(jìn)消息隊(duì)列中立磁，下游系統(tǒng)以自己的處理能力消費(fèi)這些消息呈队，起到了削峰填谷的作用。
3. 應(yīng)用間解耦
下游應(yīng)用依賴上游應(yīng)用唱歧，如果在代碼每個地方都依賴掂咒，這樣維護(hù)應(yīng)用之間的依賴關(guān)系非常頭疼。比如電商系統(tǒng)中常見的訂單狀態(tài)迈喉，有許多下游系統(tǒng)依賴訂單系統(tǒng)绍刮，訂單狀態(tài)可能是待付款、待發(fā)貨挨摸、待收貨等等孩革。如果訂單狀態(tài)每次變更都在訂單系統(tǒng)中調(diào)用其他系統(tǒng)，那么維護(hù)訂單系統(tǒng)的人肯定還在加班（哈哈）得运。如果所有的訂單狀態(tài)變更狀態(tài)處理都在訂單系統(tǒng)膝蜈，那么應(yīng)用之間的耦合度太高。這時(shí)候可以使用消息隊(duì)列這把利器熔掺，可以利用消息隊(duì)列中主題-訂閱模式饱搏，訂單狀態(tài)發(fā)生變化只需要發(fā)送消息，而需要處理訂單狀態(tài)變更的系統(tǒng)只需訂閱訂單狀態(tài)變更的Topic置逻。這樣訂單系統(tǒng)與其他系統(tǒng)就不是強(qiáng)耦合推沸。
4. 總結(jié)
消息隊(duì)列的典型應(yīng)用場景：異步處理、流量控制券坞、應(yīng)用間解耦鬓催。除此之外消息對了還可以：
- 作為發(fā)布 / 訂閱系統(tǒng)實(shí)現(xiàn)一個微服務(wù)級系統(tǒng)間的觀察者模式；
- 連接流計(jì)算任務(wù)和數(shù)據(jù)
- 將消息廣播給大量消費(fèi)者
消息隊(duì)列不是銀彈恨锚，引入消息隊(duì)列也會存在一些問題： - 消息延遲
- 數(shù)據(jù)可能不一致
- 增加系統(tǒng)復(fù)雜度
所以我們一定要根據(jù)自身的業(yè)務(wù)特點(diǎn)選擇是否使用消息隊(duì)列宇驾。
