參考：https://github.com/shishan100/Java-Interview-Advanced
爲什麼使用消息隊列？消息隊列有什麼優點和缺點？Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什麼優點和缺點？
- 爲什麼使用消息隊列？
使用消息隊列具有解耦，異步，消峯的作用。
- 消息隊列有什麼優點和缺點？
優點： 使用消息隊列具有解耦，異步，消峯的作用，
缺點：提高了系統的複雜性，需要考慮更多新的問題，
列如需要考慮MQ集羣的高可用性，消息丟失，消息重複消費，消息 有順序的的問題。
-
Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什麼區別，以及適合哪些場景？
ActiveMQ 現在社區活躍性低，大部分公司很少使用了，如果使用ActiveMQ中遇到一些BUG問題，很難很快修復。
RabbitMQ 現在社區活躍性高，遇到問題也能很快反饋修復，一般小中型公司使用，但是其使用的是erlang語言開發，國內進行二次開發會相對比較困難。
RocketMQ是阿里開源的一個消息中間件，使用Java編寫，如果進行二次開發相對來說會容易些。而且經受了阿里大數量的考驗，所以一般大的公司會會考慮使用RocketMQ。
kafka 是一個是使用與大數據裏的消息中間件，社區活躍性高。
在我們公司當時是使用的的是ActiveMQ，主要用於不同系統之家的協調同步，列如 數據發送端 發生消息通知接收端去採集數據。知道什麼時候有數據可以及時的去採集數據。
如何保證消息隊列的高可用？
kafka 高可用
Kafka 一個最基本的架構認識：由多個 broker 組成，每個 broker 是一個節點；你創建一個 topic，這個 topic 可以劃分爲多個 partition，每個 partition 可以存在於不同的 broker 上，每個 partition 就放一部分數據。
這就是天然的分佈式消息隊列，就是說一個 topic 的數據，是分散放在多個機器上的，每個機器就放一部分數據。
實際上 RabbmitMQ 之類的，並不是分佈式消息隊列，它就是傳統的消息隊列，只不過提供了一些集羣、HA(High Availability, 高可用性) 的機制而已，因爲無論怎麼玩兒，RabbitMQ 一個 queue 的數據都是放在一個節點裏的，鏡像集羣下，也是每個節點都放這個 queue 的完整數據。
Kafka 0.8 以前，是沒有 HA 機制的，就是任何一個 broker 宕機了，那個 broker 上的 partition 就廢了，沒法寫也沒法讀，沒有什麼高可用性可言。
比如說，我們假設創建了一個 topic，指定其 partition 數量是 3 個，分別在三臺機器上。但是，如果第二臺機器宕機了，會導致這個 topic 的 1/3 的數據就丟了，因此這個是做不到高可用的。
Kafka 0.8 以後，提供了 HA 機制，就是 replica（複製品） 副本機制。每個 partition 的數據都會同步到其它機器上，形成自己的多個 replica 副本。所有 replica 會選舉一個 leader 出來，那麼生產和消費都跟這個 leader 打交道，然後其他 replica 就是 follower。寫的時候，leader 會負責把數據同步到所有 follower 上去，讀的時候就直接讀 leader 上的數據即可。只能讀寫 leader？很簡單，要是你可以隨意讀寫每個 follower，那麼就要 care 數據一致性的問題，系統複雜度太高，很容易出問題。Kafka 會均勻地將一個 partition 的所有 replica 分佈在不同的機器上，這樣纔可以提高容錯性。
這麼搞，就有所謂的高可用性了，因爲如果某個 broker 宕機了，沒事兒，那個 broker上面的 partition 在其他機器上都有副本的。如果這個宕機的 broker 上面有某個 partition 的 leader，那麼此時會從 follower 中重新選舉一個新的 leader 出來，大家繼續讀寫那個新的 leader 即可。這就有所謂的高可用性了。
寫數據的時候，生產者就寫 leader，然後 leader 將數據落地寫本地磁盤，接着其他 follower 自己主動從 leader 來 pull 數據。一旦所有 follower 同步好數據了，就會發送 ack 給 leader，leader 收到所有 follower 的 ack 之後，就會返回寫成功的消息給生產者。（當然，這只是其中一種模式，還可以適當調整這個行爲）
消費的時候，只會從 leader 去讀，但是隻有當一個消息已經被所有 follower 都同步成功返回 ack 的時候，這個消息纔會被消費者讀到。
如何保證消息不被重複消費？或者說，如何保證消息消費的冪等性？
回答這個問題，首先你別聽到重複消息這個事兒，就一無所知吧，你先大概說一說可能會有哪些重複消費的問題。
首先，比如 RabbitMQ、RocketMQ、Kafka，都有可能會出現消息重複消費的問題，正常。因爲這問題通常不是 MQ 自己保證的，是由我們開發來保證的。挑一個 Kafka 來舉個例子，說說怎麼重複消費吧。
Kafka 實際上有個 offset 的概念，就是每個消息寫進去，都有一個 offset，代表消息的序號，然後 consumer 消費了數據之後，每隔一段時間（定時定期），會把自己消費過的消息的 offset 提交一下，表示“我已經消費過了，下次我要是重啓啥的，你就讓我繼續從上次消費到的 offset 來繼續消費吧”。
但是凡事總有意外，比如我們之前生產經常遇到的，就是你有時候重啓系統，看你怎麼重啓了，如果碰到點着急的，直接 kill 進程了，再重啓。這會導致 consumer 有些消息處理了，但是沒來得及提交 offset，尷尬了。重啓之後，少數消息會再次消費一次。
舉個栗子。
有這麼個場景。數據 1/2/3 依次進入 kafka，kafka 會給這三條數據每條分配一個 offset，代表這條數據的序號，我們就假設分配的 offset 依次是 152/153/154。消費者從 kafka 去消費的時候，也是按照這個順序去消費。假如當消費者消費了 offset=153 的這條數據，剛準備去提交 offset 到 zookeeper，此時消費者進程被重啓了。那麼此時消費過的數據 1/2 的 offset 並沒有提交，kafka 也就不知道你已經消費了 offset=153 這條數據。那麼重啓之後，消費者會找 kafka 說，嘿，哥兒們，你給我接着把上次我消費到的那個地方後面的數據繼續給我傳遞過來。由於之前的 offset 沒有提交成功，那麼數據 1/2 會再次傳過來，如果此時消費者沒有去重的話，那麼就會導致重複消費。
如果消費者乾的事兒是拿一條數據就往數據庫裏寫一條，會導致說，你可能就把數據 1/2 在數據庫裏插入了 2 次，那麼數據就錯啦。
其實重複消費不可怕，可怕的是你沒考慮到重複消費之後，怎麼保證冪等性。
舉個例子吧。假設你有個系統，消費一條消息就往數據庫裏插入一條數據，要是你一個消息重複兩次，你不就插入了兩條，這數據不就錯了？但是你要是消費到第二次的時候，自己判斷一下是否已經消費過了，若是就直接扔了，這樣不就保留了一條數據，從而保證了數據的正確性。
一條數據重複出現兩次，數據庫裏就只有一條數據，這就保證了系統的冪等性。
冪等性，通俗點說，就一個數據，或者一個請求，給你重複來多次，你得確保對應的數據是不會改變的，不能出錯。
所以第二個問題來了，怎麼保證消息隊列消費的冪等性？
其實還是得結合業務來思考，我這裏給幾個思路：
- 比如你拿個數據要寫庫，你先根據主鍵查一下，如果這數據都有了，你就別插入了，update 一下好吧。
- 比如你是寫 Redis，那沒問題了，反正每次都是 set，天然冪等性。
- 比如你不是上面兩個場景，那做的稍微複雜一點，你需要讓生產者發送每條數據的時候，裏面加一個全局唯一的 id，類似訂單 id 之類的東西，然後你這裏消費到了之後，先根據這個 id 去比如 Redis 裏查一下，之前消費過嗎？如果沒有消費過，你就處理，然後這個 id 寫 Redis。如果消費過了，那你就別處理了，保證別重複處理相同的消息即可。
- 比如基於數據庫的唯一鍵來保證重複數據不會重複插入多條。因爲有唯一鍵約束了，重複數據插入只會報錯，不會導致數據庫中出現髒數據。
當然，如何保證 MQ 的消費是冪等性的，需要結合具體的業務來看。
如何保證消息的可靠性傳輸？或者說，如何處理消息丟失的問題？
Kafka
消費端弄丟了數據
唯一可能導致消費者弄丟數據的情況，就是說，你消費到了這個消息，然後消費者那邊自動提交了 offset，讓 Kafka 以爲你已經消費好了這個消息，但其實你纔剛準備處理這個消息，你還沒處理，你自己就掛了，此時這條消息就丟咯。
這不是跟 RabbitMQ 差不多嗎，大家都知道 Kafka 會自動提交 offset，那麼只要關閉自動提交 offset，在處理完之後自己手動提交 offset，就可以保證數據不會丟。但是此時確實還是可能會有重複消費，比如你剛處理完，還沒提交 offset，結果自己掛了，此時肯定會重複消費一次，自己保證冪等性就好了。
生產環境碰到的一個問題，就是說我們的 Kafka 消費者消費到了數據之後是寫到一個內存的 queue 裏先緩衝一下，結果有的時候，你剛把消息寫入內存 queue，然後消費者會自動提交 offset。然後此時我們重啓了系統，就會導致內存 queue 裏還沒來得及處理的數據就丟失了。
Kafka 弄丟了數據
這塊比較常見的一個場景，就是 Kafka 某個 broker 宕機，然後重新選舉 partition 的 leader。大家想想，要是此時其他的 follower 剛好還有些數據沒有同步，結果此時 leader 掛了，然後選舉某個 follower 成 leader 之後，不就少了一些數據？這就丟了一些數據啊。
生產環境也遇到過，我們也是，之前 Kafka 的 leader 機器宕機了，將 follower 切換爲 leader 之後，就會發現說這個數據就丟了。
所以此時一般是要求起碼設置如下 4 個參數：
- 給 topic 設置
replication.factor參數：這個值必須大於 1，要求每個 partition 必須有至少 2 個副本。 - 在 Kafka 服務端設置
min.insync.replicas參數：這個值必須大於 1，這個是要求一個 leader 至少感知到有至少一個 follower 還跟自己保持聯繫，沒掉隊，這樣才能確保 leader 掛了還有一個 follower 吧。 - 在 producer 端設置
acks=all：這個是要求每條數據，必須是寫入所有 replica 之後，才能認爲是寫成功了。 - 在 producer 端設置
retries=MAX（很大很大很大的一個值，無限次重試的意思）：這個是要求一旦寫入失敗，就無限重試，卡在這裏了。
我們生產環境就是按照上述要求配置的，這樣配置之後，至少在 Kafka broker 端就可以保證在 leader 所在 broker 發生故障，進行 leader 切換時，數據不會丟失。
生產者會不會弄丟數據？
如果按照上述的思路設置了 acks=all，一定不會丟，要求是，你的 leader 接收到消息，所有的 follower 都同步到了消息之後，才認爲本次寫成功了。如果沒滿足這個條件，生產者會自動不斷的重試，重試無限次。
如何保證消息的順序性？
- Kafka：比如說我們建了一個 topic，有三個 partition。生產者在寫的時候，其實可以指定一個 key，比如說我們指定了某個訂單 id 作爲 key，那麼這個訂單相關的數據，一定會被分發到同一個 partition 中去，而且這個 partition 中的數據一定是有順序的。
消費者從 partition 中取出來數據的時候，也一定是有順序的。到這裏，順序還是 ok 的，沒有錯亂。接着，我們在消費者裏可能會搞多個線程來併發處理消息。因爲如果消費者是單線程消費處理，而處理比較耗時的話，比如處理一條消息耗時幾十 ms，那麼 1 秒鐘只能處理幾十條消息，這吞吐量太低了。而多個線程併發跑的話，順序可能就亂掉了。
解決方案
Kafka
- 一個 topic，一個 partition，一個 consumer，內部單線程消費，單線程吞吐量太低，一般不會用這個。
- 寫 N 個內存 queue，具有相同 key 的數據都到同一個內存 queue；然後對於 N 個線程，每個線程分別消費一個內存 queue 即可，這樣就能保證順序性。
