面試篇之MQ一文帶你總結

1.MQ的應用場景

導讀-xmind

1.1.解耦

• 智能客服系統中，企業註冊完成後，須要完成一系列初始化操做，如建立es的索引，建立默認的一些數據

• 發短信

  1.2.異步

  減小耗時，異步下單操做，接收到參數以後寫入mq，經過多個節點去下單，而後websocket推送結果(參數中帶有clientid)

  1.3.削峯

  高併發場景排隊

2.技術選型

mq	優點	缺點
RabbitMQ	erlang語言開發，沒法二次維護，穩定及社區活躍度比較高
RocketMQ	java，阿里系，可二度開發
Kafka	高吞吐量，通常的日誌，海量數據傳輸使用

咱們選擇rabbitmq的緣由是，系統比較穩定，社區維護性比較高，國內的開源項目多爲kap項目，如dubbo

3.引入mq會帶來哪些問題

• 一致性問題：若A系統向B、C、D系統發消息，某個消息失敗會致使數據不一致
• 系統可用性下降：若MQ出現問題，會致使系統不可用
• 系統複雜度提升：

4.高可用

4.一、RabbitMQ

• 單機模式

• 普通集羣
  
  queue會存在某個集羣中，其餘機器上存儲的是該機器queue的配置信息(如ip等)。如上圖，若client鏈接到了實例C中要訪問位於實例B中的queue2時，就會由實例C和實例B進行通訊。
  缺點

  內部大量的數據傳輸，可靠性沒法保證

• 鏡像集羣
  
  生產者寫入指定queue以後會同步給其餘節點，任何一個節點都擁有所有完整的數據。
  缺點
• 非分佈式。容量過大，形成浪費，每一個節點存儲全部同樣的數據。

4.2.Kafka

kafka-broker的副本，如broker1與broker2中有一個leader，一個broker，數據徹底一致，leader負責讀寫

5.面試題集錦

5.1.如何保證Kafka消息不被重複消費(冪等性)?

• 產生緣由：consumer準備提交offset的時候，進程掛掉了
• 解決方案：添加判斷邏輯，判斷消息是否已被消費，好比msg_id，經過redis的set判斷。或者mysql設置惟一鍵，若已被消費，則丟棄該消息

5.2.如何保障Kafka消息的順序性？

kafka保證topic中的每一個partition都是有序的，(每一個Topic中可能包含多個partition),這個時候要保障有序，就要保障須要有序的數據寫入一個partition

• 業務數據有序，好比同一個order_id的數據有序，能夠按照order_id進行設置partition，以由於同一個partition確定被同一個consumer消費
• 如果全部數據都要求有序，則須要設置partition爲1
• 若消費端多個線程去獲取數據，還要求順序一致，則能夠按照業務id進行hash放入同一個內存隊列

5.3.如何保障消息不丟失？

消息丟失有3個地方，1.producer未寫入，2.kafka內部異常,3.consumer未處理

• 關閉自動提交offset，改成手動提交
• partition副本保障至少有2個，leader宕機的時候還有備份
• acks=all，全部副本寫入成功纔算成功。

5.4.Kafka消息積壓問題

• 消費能力不足的問題的話，增長partition,同時增長消費者，即添加服務器
• 或者上線臨時服務器，將消息臨時處理，好比我能夠再次寫會kafka，等待消費端再次消費

** weixin關注"SpringForAll社區"實時獲取Java/Spring周邊最新動態

本文由博客一文多發平臺 OpenWrite 發佈！