《面試》你須要知道的消息隊列基礎

__沒有最好的 只有適合的

前言

消息隊列在互聯網技術存儲方面使用如此普遍，幾乎全部的後端技術面試官都要在消息隊列的使用和原理方面對小夥伴們進行360°的刁難。

消息系統的使用場景

你爲啥用消息隊列？

公司初期業務體量小，因此直接單機直接無壓力，可是後面業務體量不斷增大，因而採用微服務的設計思想，分佈式的部署方式，因此拆分了不少的服務，隨着體量的增長以及業務場景愈來愈複雜了，後來調研了不少方案，咱們決定引入消息隊列中間件。

消息隊列的經典三場景

• 異步 某些複雜的場景下一個流程裏面有不少步驟，步驟越多系統響應就越慢；
  例如電商常見的下單系統:
  
  假設每一個步驟的時間都是500ms, 那系統的響應就是1.5s！ 但若是是這樣呢?
  
  系統響應就是支付步驟的500ms, 其餘步驟都異步執行！
• 削峯 這個好理解，你的系統平時沒什麼流量，可是老闆臨時決定搞一個促銷。促銷時流量忽然涌入，數據庫緩存都扛不住了，怎麼辦？好辦，把全部請求都放入消息隊列，你仍是按照日常的處理能力消費。系統平穩的度過了促銷！
• 解耦 上面下單系統的的三個步驟每一個步驟都當作一個子系統的話。系統每次都要調用三個子系統完成下單操做。也就是說系統與三個子系統耦合在一塊兒了。 但若是使用了消息隊列呢，下單成功後，發送一個成功消息到消息隊列，其餘子系統監聽這個消息就好了，不須要去調用其餘子系統了。

消息隊列的缺點

• 系統可用性下降 系統引入的外部依賴越多，越容易掛掉。原本下單系統調用三個系統的接口就行了，如今加了一個MQ，萬一MQ掛了咋整，MQ一掛，整套系統崩潰的，你不就完了？這裏就必須保證MQ的高可用！
• 系統複雜度提升 加個MQ進來，你怎麼保證消息沒有重複消費？怎麼處理消息丟失的狀況？怎麼保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已。
• 一致性問題 下單成功了，可是子系統失敗了，咋整？你這數據就不一致了。 這個實際上是分佈式服務自己就存在的一個問題，不單單是消息隊列的問題。這就是分佈式事務的知識點了！之後再講

消息隊列選型

選擇哪一個應該根據你的使用場景，若是一個幾萬用戶的小系統硬上Kafka，可能獲取的回報是至關小的。

沒有最好的技術，只有最合適的技術!

回見!