乙個用訊息佇列 的人，不知道為啥用 mq，這就有點尷尬
mq之間的選擇：
1.rabbitmq吞吐量低，適合資料量比較小的場景，並且其功能都是比較完善的，但是因為是用erlang開發的，懂erlang語言的較少，因此定製化比較麻煩複雜。
2.kafka和rocketmq都是分布式架構，具有高吞吐量，適用於分布式環境和資料量龐大的場景，rocketmq功能比較完善，kafka只支援主要的mq功能，但是如果是用於日誌採集的場景，首選kafka。
kafka保證訊息的有序性：
就把有序的訊息指定同乙個key，然後相同的key會分發到同乙個partition分割槽，這就保證了訊息的有序，
如果消費者是用多執行緒來消費訊息，則還可以使用像queue，然後同乙個key的訊息存放到同乙個queue中，然後乙個queue只能由乙個執行緒來消費，這樣就保障了訊息的有序性。
訊息佇列的應答引數配置：
ack 引數配置：
0：producer 不等待 broker 的 ack，這提供了最低延遲，
broker 一收到資料還沒有寫入磁碟就已經返回，當 broker 故障時有可能丟失資料。
1：producer 等待 broker 的 ack，partition 的 leader 落盤成功後返回 ack，
如果在 follower 同步成功之前 leader 故障，那麼將會丟失資料。 -1
(all)：producer 等待 broker 的 ack，partition 的 leader 和 follower 全部落盤成功後才返回 ack。
但是在 broker 傳送 ack 時，leader 發生故障，則會造成資料重複。
kafka offset 的維護方式
消費者消費方式：
1、consumer 採用 pull
(拉取)模式從 broker 中讀取資料。
2、consumer 採用 push
(推送)模式，broker 給 consumer 推送訊息的速率是由 broker 決定的，很難適應消費速率不同的消費者。
push的目標是盡可能以最快速度傳遞訊息，但是這樣很容易造成 consumer 來不及處理訊息，典型的表現就是拒絕服務以及網路擁塞。
而 pull 模式則可以根據 consumer 的消費能力以適當的速率消費訊息。
pull 模式不足之處是，如果 kafka 沒有資料，消費者可能會陷入迴圈中，一直返回空資料。
因為消費者從 broker 主動拉取資料，需要維護乙個長輪詢，針對這一點， kafka 的消費者在消費資料時會傳入乙個時長引數 timeout。
如果當前沒有資料可供消費，consumer 會等待一段時間之後再返回，這段時長即為 timeout。
MQ 集群高可用
transaction 即事務機制，手動提交和回滾 confirm 機制提供了 confirmlistener 和waitforconfirms 兩種方式。confirm 機制效率明顯會高於 transaction 機制，但後者的優勢在於強一致性。如果沒有特別的要求，建議使用 conrim 機制。2...
使用MQ訊息佇列的優缺點
首先要知道，為什麼要用mq，說白了就是以下3點 就是乙個系統或者乙個模組，呼叫了多個系統或者模組，互相之間的呼叫很複雜，維護起來很麻煩。其實這個呼叫是不需要直接同步呼叫介面的，皆可以用mq給他非同步化解耦。比如 像如圖所示 a系統和其他系統沒有直接的關聯 那我們進行擴充套件的時候也會更靈活 如圖所示...
為什麼要使用MQ，以及使用MQ的優缺點
為什麼要使用mq 1.解耦 比如a系統需要呼叫b系統的介面傳遞資料，然而當不需要被呼叫的時候，a系統需要重新打包部署到伺服器，這樣操作起來就很麻煩，用上mq之後，只需要管理mq的就顯得簡單的多 2.非同步 比如a系統呼叫b系統的介面，需要等到b系統的整個邏輯處理完之後，a系統才會繼續往下執行，響應變...