MQ面試題
為什么使用消息隊列
解耦
看這么個場景。A 系統發送數據到 BCD 三個系統，通過接口調用發送。如果 E 系統也要這個數據呢？那如果 C 系統現在不需要了呢？A 系統負責人幾乎崩潰......
在這個場景中，A 系統跟其它各種亂七八糟的系統嚴重耦合，A 系統產生一條比較關鍵的數據，很多系統都需要 A 系統將這個數據發送過來。A 系統要時時刻刻考慮 BCDE 四個系統如果掛了該咋辦？要不要重發，要不要把消息存起來？頭發都白了啊！
如果使用 MQ，A 系統產生一條數據，發送到 MQ 里面去，哪個系統需要數據自己去 MQ 里面消費。如果新系統需要數據，直接從 MQ 里消費即可；如果某個系統不需要這條數據了，就取消對 MQ 消息的消費即可。這樣下來，A 系統壓根兒不需要去考慮要給誰發送數據，不需要維護這個代碼，也不需要考慮人家是否調用成功、失敗超時等情況。
總結：通過一個 MQ，Pub/Sub 發布訂閱消息這么一個模型，A 系統就跟其它系統徹底解耦了。你需要去考慮一下你負責的系統中是否有類似的場景，就是一個系統或者一個模塊，調用了多個系統或者模塊，互相之間的調用很復雜，維護起來很麻煩。但是其實這個調用是不需要直接同步調用接口的，如果用 MQ 給它異步化解耦，也是可以的，你就需要去考慮在你的項目里，是不是可以運用這個 MQ 去進行系統的解耦。在簡歷中體現出來這塊東西，用 MQ 作解耦。
異步
再來看一個場景，A 系統接收一個請求，需要在自己本地寫庫，還需要在 BCD 三個系統寫庫，自己本地寫庫要 3ms，BCD 三個系統分別寫庫要 300ms、450ms、200ms。最終請求總延時是 3 + 300 + 450 + 200 = 953ms，接近 1s，用戶感覺搞個什么東西，慢死了慢死了。用戶通過瀏覽器發起請求，等待個 1s，這幾乎是不可接受的。
一般互聯網類的企業，對於用戶直接的操作，一般要求是每個請求都必須在 200 ms 以內完成，對用戶幾乎是無感知的。
如果使用 MQ，那么 A 系統連續發送 3 條消息到 MQ 隊列中，假如耗時 5ms，A 系統從接受一個請求到返回響應給用戶，總時長是 3 + 5 = 8ms，對於用戶而言，其實感覺上就是點個按鈕，8ms 以后就直接返回了，爽！網站做得真好，真快！
削峰
每天 0:00 到 12:00，A 系統風平浪靜，每秒並發請求數量就 50 個。結果每次一到 12:00 ~ 13:00 ，每秒並發請求數量突然會暴增到 5k+ 條。但是系統是直接基於 MySQL 的，大量的請求涌入 MySQL，每秒鍾對 MySQL 執行約 5k 條 SQL。
一般的 MySQL，扛到每秒 2k 個請求就差不多了，如果每秒請求到 5k 的話，可能就直接把 MySQL 給打死了，導致系統崩潰，用戶也就沒法再使用系統了。
但是高峰期一過，到了下午的時候，就成了低峰期，可能也就 1w 的用戶同時在網站上操作，每秒中的請求數量可能也就 50 個請求，對整個系統幾乎沒有任何的壓力。
如果使用 MQ，每秒 5k 個請求寫入 MQ，A 系統每秒鍾最多處理 2k 個請求，因為 MySQL 每秒鍾最多處理 2k 個。A 系統從 MQ 中慢慢拉取請求，每秒鍾就拉取 2k 個請求，不要超過自己每秒能處理的最大請求數量就 ok，這樣下來，哪怕是高峰期的時候，A 系統也絕對不會掛掉。而 MQ 每秒鍾 5k 個請求進來，就 2k 個請求出去，結果就導致在中午高峰期（1 個小時），可能有幾十萬甚至幾百萬的請求積壓在 MQ 中。
這個短暫的高峰期積壓是 ok 的，因為高峰期過了之后，每秒鍾就 50 個請求進 MQ，但是 A 系統依然會按照每秒 2k 個請求的速度在處理。所以說，只要高峰期一過，A 系統就會快速將積壓的消息給解決掉。
消息隊列的缺點
系統可用性降低
系統引入的外部依賴越多，越容易掛掉。本來你就是 A 系統調用 BCD 三個系統的接口就好了，ABCD 四個系統還好好的，沒啥問題，你偏加個 MQ 進來，萬一 MQ 掛了咋整？MQ 一掛，整套系統崩潰，你不就完了？
系統復雜度提高
硬生生加個 MQ 進來，你怎么保證消息沒有重復消費？怎么處理消息丟失的情況？怎么保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已。
一致性問題
A 系統處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是 BCD 三個系統那里，BD 兩個系統寫庫成功了，結果 C 系統寫庫失敗了，咋整？你這數據就不一致了。
ActiveMQ，RabbitMQ，RocketMQ，Kafka有什么異同
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 開發語言 | java | erlang | java | scala |
| 單機吞吐量 | 萬級，比 RocketMQ、Kafka 低一個數量級 | 同 ActiveMQ | 10 萬級，支撐高吞吐 | 10 萬級，高吞吐，一般配合大數據類的系統來進行實時數據計算、日志采集等場景 |
| topic 數量對吞吐量的影響 | topic 可以達到幾百/幾千的級別，吞吐量會有較小幅度的下降，這是 RocketMQ 的一大優勢，在同等機器下，可以支撐大量的 topic | topic 從幾十到幾百個時候，吞吐量會大幅度下降，在同等機器下，Kafka 盡量保證 topic 數量不要過多，如果要支撐大規模的 topic，需要增加更多的機器資源 | ||
| 時效性 | ms 級 | 微秒級，這是 RabbitMQ 的一大特點，延遲最低 | ms 級 | 延遲在 ms 級以內 |
| 可用性 | 高，基於主從架構實現高可用 | 同 ActiveMQ | 非常高，分布式架構 | 非常高，分布式，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用 |
| 消息可靠性 | 有較低的概率丟失數據 | 基本不丟 | 經過參數優化配置，可以做到 0 丟失 | 同 RocketMQ |
| 功能支持 | MQ 領域的功能極其完備 | 基於 erlang 開發，並發能力很強，性能極好，延時很低 | MQ 功能較為完善，還是分布式的，擴展性好 | 功能較為簡單，主要支持簡單的 MQ 功能，在大數據領域的實時計算以及日志采集被大規模使用 |
| 社區活躍度 | 低 | 很高 | 一般 | 很高 |
- 中小型公司，技術實力較為一般，技術挑戰不是特別高，用 RabbitMQ 是不錯的選擇；
- 大型公司，基礎架構研發實力較強，用 RocketMQ 是很好的選擇。
- 大數據領域的實時計算、日志采集等場景，用 Kafka 是業內標准的，幾乎是全世界這個領域的事實性規范。
如何保證消息隊列的高可用？
RabbitMQ 的高可用性
RabbitMQ 是比較有代表性的，因為是基於主從（非分布式）做高可用性的，我們就以 RabbitMQ 為例子講解第一種 MQ 的高可用性怎么實現。
RabbitMQ 有三種模式：單機模式、普通集群模式、鏡像集群模式。
單機模式
單機模式，就是 Demo 級別的，一般就是你本地啟動了玩玩兒的😄，沒人生產用單機模式。
普通集群模式（無高可用性）
普通集群模式，意思就是在多台機器上啟動多個 RabbitMQ 實例，每個機器啟動一個。你創建的 queue，只會放在一個 RabbitMQ 實例上，但是每個實例都同步 queue 的元數據（元數據可以認為是 queue 的一些配置信息，通過元數據，可以找到 queue 所在實例）。你消費的時候，實際上如果連接到了另外一個實例，那么那個實例會從 queue 所在實例上拉取數據過來。
這種方式確實很麻煩，也不怎么好，沒做到所謂的分布式，就是個普通集群。因為這導致你要么消費者每次隨機連接一個實例然后拉取數據，要么固定連接那個 queue 所在實例消費數據，前者有數據拉取的開銷，后者導致單實例性能瓶頸。
而且如果那個放 queue 的實例宕機了，會導致接下來其他實例就無法從那個實例拉取，如果你開啟了消息持久化，讓 RabbitMQ 落地存儲消息的話，消息不一定會丟，得等這個實例恢復了，然后才可以繼續從這個 queue 拉取數據。
所以這個事兒就比較尷尬了，這就沒有什么所謂的高可用性，這方案主要是提高吞吐量的，就是說讓集群中多個節點來服務某個 queue 的讀寫操作。
鏡像集群模式（高可用性）
這種模式，才是所謂的 RabbitMQ 的高可用模式。跟普通集群模式不一樣的是，在鏡像集群模式下，你創建的 queue，無論元數據還是 queue 里的消息都會存在於多個實例上，就是說，每個 RabbitMQ 節點都有這個 queue 的一個完整鏡像，包含 queue 的全部數據的意思。然后每次你寫消息到 queue 的時候，都會自動把消息同步到多個實例的 queue 上。
那么如何開啟這個鏡像集群模式呢？其實很簡單，RabbitMQ 有很好的管理控制台，就是在后台新增一個策略，這個策略是鏡像集群模式的策略，指定的時候是可以要求數據同步到所有節點的，也可以要求同步到指定數量的節點，再次創建 queue 的時候，應用這個策略，就會自動將數據同步到其他的節點上去了。
這樣的話，好處在於，你任何一個機器宕機了，沒事兒，其它機器（節點）還包含了這個 queue 的完整數據，別的 consumer 都可以到其它節點上去消費數據。壞處在於，第一，這個性能開銷也太大了吧，消息需要同步到所有機器上，導致網絡帶寬壓力和消耗很重！第二，這么玩兒，不是分布式的，就沒有擴展性可言了，如果某個 queue 負載很重，你加機器，新增的機器也包含了這個 queue 的所有數據，並沒有辦法線性擴展你的 queue。你想，如果這個 queue 的數據量很大，大到這個機器上的容量無法容納了，此時該怎么辦呢？
RocketMQ 的高可用性
RcoketMQ的集群有：多master 模式、多master多slave異步復制模式、多 master多slave同步雙寫模式。
多master多slave模式部署架構圖：
通信過程如下：Producer 與 NameServer集群中的其中一個節點（隨機選擇）建立長連接，定期從 NameServer 獲取 Topic 路由信息，並向提供 Topic 服務的 Broker Master 建立長連接，且定時向 Broker 發送心跳。Producer 只能將消息發送到 Broker master，但是 Consumer 則不一樣，它同時和提供 Topic 服務的 Master 和 Slave建立長連接，既可以從 Broker Master 訂閱消息，也可以從 Broker Slave 訂閱消息。
Kafka 的高可用性
Kafka 一個最基本的架構認識：由多個 broker 組成，每個 broker 是一個節點；你創建一個 topic，這個 topic 可以划分為多個 partition，每個 partition 可以存在於不同的 broker 上，每個 partition 就放一部分數據。
這就是天然的分布式消息隊列，就是說一個 topic 的數據，是分散放在多個機器上的，每個機器就放一部分數據。
實際上 RabbitMQ 之類的，並不是分布式消息隊列，它就是傳統的消息隊列，只不過提供了一些集群、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 的消費是冪等性的，需要結合具體的業務來看。
如何保證消息的可靠傳輸（處理消息丟失）？
RabbitMQ
生產者弄丟數據
生產者將數據發送到 RabbitMQ 的時候，可能數據就在半路給搞丟了，因為網絡問題啥的，都有可能。
此時可以選擇用 RabbitMQ 提供的事務功能，就是生產者發送數據之前開啟 RabbitMQ 事務channel.txSelect，然后發送消息，如果消息沒有成功被 RabbitMQ 接收到，那么生產者會收到異常報錯，此時就可以回滾事務channel.txRollback，然后重試發送消息；如果收到了消息，那么可以提交事務channel.txCommit。
// 開啟事務 channel.txSelect try { // 這里發送消息 } catch (Exception e) { channel.txRollback // 這里再次重發這條消息 } // 提交事務 channel.txCommit
但是問題是，RabbitMQ 事務機制（同步）一搞，基本上吞吐量會下來，因為太耗性能。
所以一般來說，如果你要確保說寫 RabbitMQ 的消息別丟，可以開啟 confirm 模式，在生產者那里設置開啟 confirm 模式之后，你每次寫的消息都會分配一個唯一的 id，然后如果寫入了 RabbitMQ 中，RabbitMQ 會給你回傳一個 ack 消息，告訴你說這個消息 ok 了。如果 RabbitMQ 沒能處理這個消息，會回調你的一個 nack 接口，告訴你這個消息接收失敗，你可以重試。而且你可以結合這個機制自己在內存里維護每個消息 id 的狀態，如果超過一定時間還沒接收到這個消息的回調，那么你可以重發。
事務機制和 confirm 機制最大的不同在於，事務機制是同步的，你提交一個事務之后會阻塞在那兒，但是 confirm 機制是異步的，你發送個消息之后就可以發送下一個消息，然后那個消息 RabbitMQ 接收了之后會異步回調你的一個接口通知你這個消息接收到了。
所以一般在生產者這塊避免數據丟失，都是用 confirm 機制的。
RabbitMQ弄丟數據
就是 RabbitMQ 自己弄丟了數據，這個你必須開啟 RabbitMQ 的持久化，就是消息寫入之后會持久化到磁盤，哪怕是 RabbitMQ 自己掛了，恢復之后會自動讀取之前存儲的數據，一般數據不會丟。除非極其罕見的是，RabbitMQ 還沒持久化，自己就掛了，可能導致少量數據丟失，但是這個概率較小。
設置持久化有兩個步驟：
- 創建 queue 的時候將其設置為持久化
這樣就可以保證 RabbitMQ 持久化 queue 的元數據，但是它是不會持久化 queue 里的數據的。 - 第二個是發送消息的時候將消息的
deliveryMode設置為 2
就是將消息設置為持久化的，此時 RabbitMQ 就會將消息持久化到磁盤上去。
必須要同時設置這兩個持久化才行，RabbitMQ 哪怕是掛了，再次重啟，也會從磁盤上重啟恢復 queue，恢復這個 queue 里的數據。
注意，哪怕是你給 RabbitMQ 開啟了持久化機制，也有一種可能，就是這個消息寫到了 RabbitMQ 中，但是還沒來得及持久化到磁盤上，結果不巧，此時 RabbitMQ 掛了，就會導致內存里的一點點數據丟失。
所以，持久化可以跟生產者那邊的 confirm 機制配合起來，只有消息被持久化到磁盤之后，才會通知生產者 ack 了，所以哪怕是在持久化到磁盤之前，RabbitMQ 掛了，數據丟了，生產者收不到 ack，你也是可以自己重發的。
消費端弄丟數據
RabbitMQ 如果丟失了數據，主要是因為你消費的時候，剛消費到，還沒處理，結果進程掛了，比如重啟了，那么就尷尬了，RabbitMQ 認為你都消費了，這數據就丟了。
這個時候得用 RabbitMQ 提供的 ack 機制，簡單來說，就是你必須關閉 RabbitMQ 的自動 ack，可以通過一個 api 來調用就行，然后每次你自己代碼里確保處理完的時候，再在程序里 ack 一把。這樣的話，如果你還沒處理完，不就沒有 ack 了？那 RabbitMQ 就認為你還沒處理完，這個時候 RabbitMQ 會把這個消費分配給別的 consumer 去處理，消息是不會丟的。
Kafka
先引一張Kafka Replication數據流向圖
消費端弄丟數據
唯一可能導致消費者弄丟數據的情況，就是說，你消費到了這個消息，然后消費者那邊自動提交了 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 都同步到了消息之后，才認為本次寫成功了。如果沒滿足這個條件，生產者會自動不斷的重試，重試無限次。
如何保證消息的順序？
我舉個例子，我們以前做過一個 mysql binlog 同步的系統，壓力還是非常大的，日同步數據要達到上億，就是說數據從一個 mysql 庫原封不動地同步到另一個 mysql 庫里面去（mysql -> mysql）。常見的一點在於說比如大數據 team，就需要同步一個 mysql 庫過來，對公司的業務系統的數據做各種復雜的操作。
你在 mysql 里增刪改一條數據，對應出來了增刪改 3 條 binlog 日志，接着這三條 binlog 發送到 MQ 里面，再消費出來依次執行，起碼得保證人家是按照順序來的吧？不然本來是：增加、修改、刪除；你愣是換了順序給執行成刪除、修改、增加，不全錯了么。
本來這個數據同步過來，應該最后這個數據被刪除了；結果你搞錯了這個順序，最后這個數據保留下來了，數據同步就出錯了。
先看看順序會錯亂的倆場景：
RabbitMQ：一個 queue，多個 consumer。比如，生產者向 RabbitMQ 里發送了三條數據，順序依次是 data1/data2/data3，壓入的是 RabbitMQ 的一個內存隊列。有三個消費者分別從 MQ 中消費這三條數據中的一條，結果消費者2先執行完操作，把 data2 存入數據庫，然后是 data1/data3。這不明顯亂了。
Kafka：比如說我們建了一個 topic，有三個 partition。生產者在寫的時候，其實可以指定一個 key，比如說我們指定了某個訂單 id 作為 key，那么這個訂單相關的數據，一定會被分發到同一個 partition 中去，而且這個 partition 中的數據一定是有順序的。
消費者從 partition 中取出來數據的時候，也一定是有順序的。到這里，順序還是 ok 的，沒有錯亂。接着，我們在消費者里可能會搞多個線程來並發處理消息。因為如果消費者是單線程消費處理，而處理比較耗時的話，比如處理一條消息耗時幾十 ms，那么 1 秒鍾只能處理幾十條消息，這吞吐量太低了。而多個線程並發跑的話，順序可能就亂掉了。
解決方案
RabbitMQ
拆分多個 queue，每個 queue 一個 consumer，就是多一些 queue 而已，確實是麻煩點；或者就一個 queue 但是對應一個 consumer，然后這個 consumer 內部用內存隊列做排隊，然后分發給底層不同的 worker 來處理。
Kafka
- 一個 topic，一個 partition，一個 consumer，內部單線程消費，單線程吞吐量太低，一般不會用這個。
- 寫 N 個內存 queue，具有相同 key 的數據都到同一個內存 queue；然后對於 N 個線程，每個線程分別消費一個內存 queue 即可，這樣就能保證順序性。
如何解決消息隊列的延時以及過期失效問題？消息隊列滿了以后該怎么處理？有幾百萬消息持續積壓幾小時，說說怎么解決？
你看這問法，其實本質針對的場景，都是說，可能你的消費端出了問題，不消費了；或者消費的速度極其慢。接着就坑爹了，可能你的消息隊列集群的磁盤都快寫滿了，都沒人消費，這個時候怎么辦？或者是這整個就積壓了幾個小時，你這個時候怎么辦？或者是你積壓的時間太長了，導致比如 RabbitMQ 設置了消息過期時間后就沒了怎么辦？
所以就這事兒，其實線上挺常見的，一般不出，一出就是大 case。一般常見於，舉個例子，消費端每次消費之后要寫 mysql，結果 mysql 掛了，消費端 hang 那兒了，不動了；或者是消費端出了個什么岔子，導致消費速度極其慢。
大量消息在 mq 里積壓了幾個小時了還沒解決
幾千萬條數據在 MQ 里積壓了七八個小時，從下午 4 點多，積壓到了晚上 11 點多。這個是我們真實遇到過的一個場景，確實是線上故障了，這個時候要不然就是修復 consumer 的問題，讓它恢復消費速度，然后傻傻的等待幾個小時消費完畢。這個肯定不能在面試的時候說吧。
一個消費者一秒是 1000 條，一秒 3 個消費者是 3000 條，一分鍾就是 18 萬條。所以如果你積壓了幾百萬到上千萬的數據，即使消費者恢復了，也需要大概 1 小時的時間才能恢復過來。
一般這個時候，只能臨時緊急擴容了，具體操作步驟和思路如下：
- 先修復 consumer 的問題，確保其恢復消費速度，然后將現有 consumer 都停掉。
- 新建一個 topic，partition 是原來的 10 倍，臨時建立好原先 10 倍的 queue 數量。
- 然后寫一個臨時的分發數據的 consumer 程序，這個程序部署上去消費積壓的數據，消費之后不做耗時的處理，直接均勻輪詢寫入臨時建立好的 10 倍數量的 queue。
- 接着臨時征用 10 倍的機器來部署 consumer，每一批 consumer 消費一個臨時 queue 的數據。這種做法相當於是臨時將 queue 資源和 consumer 資源擴大 10 倍，以正常的 10 倍速度來消費數據。
- 等快速消費完積壓數據之后，得恢復原先部署的架構，重新用原先的 consumer 機器來消費消息。
mq 中的消息過期失效了
假設你用的是 RabbitMQ，RabbtiMQ 是可以設置過期時間的，也就是 TTL。如果消息在 queue 中積壓超過一定的時間就會被 RabbitMQ 給清理掉，這個數據就沒了。那這就是第二個坑了。這就不是說數據會大量積壓在 mq 里，而是大量的數據會直接搞丟。
這個情況下，就不是說要增加 consumer 消費積壓的消息，因為實際上沒啥積壓，而是丟了大量的消息。我們可以采取一個方案，就是批量重導，這個我們之前線上也有類似的場景干過。就是大量積壓的時候，我們當時就直接丟棄數據了，然后等過了高峰期以后，比如大家一起喝咖啡熬夜到晚上12點以后，用戶都睡覺了。這個時候我們就開始寫程序，將丟失的那批數據，寫個臨時程序，一點一點的查出來，然后重新灌入 mq 里面去，把白天丟的數據給他補回來。也只能是這樣了。
假設 1 萬個訂單積壓在 mq 里面，沒有處理，其中 1000 個訂單都丟了，你只能手動寫程序把那 1000 個訂單給查出來，手動發到 mq 里去再補一次。
mq 都快寫滿了
如果消息積壓在 mq 里，你很長時間都沒有處理掉，此時導致 mq 都快寫滿了，咋辦？這個還有別的辦法嗎？沒有，誰讓你第一個方案執行的太慢了，你臨時寫程序，接入數據來消費，消費一個丟棄一個，都不要了，快速消費掉所有的消息。然后走第二個方案，到了晚上再補數據吧。
如果讓你寫一個消息隊列，該如何進行架構設計？說一下你的思路。
其實聊到這個問題，一般面試官要考察兩塊：
- 你有沒有對某一個消息隊列做過較為深入的原理的了解，或者從整體了解把握住一個消息隊列的架構原理。
- 看看你的設計能力，給你一個常見的系統，就是消息隊列系統，看看你能不能從全局把握一下整體架構設計，給出一些關鍵點出來。
說實話，問類似問題的時候，大部分人基本都會蒙，因為平時從來沒有思考過類似的問題，大多數人就是平時埋頭用，從來不去思考背后的一些東西。類似的問題，比如，如果讓你來設計一個 Spring 框架你會怎么做？如果讓你來設計一個 Dubbo 框架你會怎么做？如果讓你來設計一個 MyBatis 框架你會怎么做？
其實回答這類問題，說白了，不求你看過那技術的源碼，起碼你要大概知道那個技術的基本原理、核心組成部分、基本架構構成，然后參照一些開源的技術把一個系統設計出來的思路說一下就好。
比如說這個消息隊列系統，我們從以下幾個角度來考慮一下：
-
首先這個 mq 得支持可伸縮性吧，就是需要的時候快速擴容，就可以增加吞吐量和容量，那怎么搞？設計個分布式的系統唄，參照一下 kafka 的設計理念，broker -> topic -> partition，每個 partition 放一個機器，就存一部分數據。如果現在資源不夠了，簡單啊，給 topic 增加 partition，然后做數據遷移，增加機器，不就可以存放更多數據，提供更高的吞吐量了？
-
其次你得考慮一下這個 mq 的數據要不要落地磁盤吧？那肯定要了，落磁盤才能保證別進程掛了數據就丟了。那落磁盤的時候怎么落啊？順序寫，這樣就沒有磁盤隨機讀寫的尋址開銷，磁盤順序讀寫的性能是很高的，這就是 kafka 的思路。
-
其次你考慮一下你的 mq 的可用性啊？這個事兒，具體參考之前可用性那個環節講解的 kafka 的高可用保障機制。多副本 -> leader & follower -> broker 掛了重新選舉 leader 即可對外服務。
-
能不能支持數據 0 丟失啊？可以的，參考我們之前說的那個 kafka 數據零丟失方案。
mq 肯定是很復雜的，面試官問你這個問題，其實是個開放題，他就是看看你有沒有從架構角度整體構思和設計的思維以及能力。確實這個問題可以刷掉一大批人，因為大部分人平時不思考這些東西。
Redis做消息隊列與其他消息隊列相比有什么不同
Redis作為消息隊列：
- 如果你的需求是快產快消的即時消費場景，並且生產的消息立即被消費者消費掉。
- 如果速度是你十分看重的，比如慢了一秒好幾千萬這種。
- 如果允許出現消息丟失的場景。
- 如果你不需要系統保存你發送過的消息。
- 如果需要處理的數據量並不是那么巨大。
其他消息隊列：
- 如果你想要穩定的消息隊列。
- 如果你想要你發送過的消息可以保留一定的時間，並不是無跡可尋的時候。
- 如果你無法忍受數據的丟失。
- 如果速度不需要那么的快。
- 如果需要處理數據量巨大的時候。
應用場景分析
Redis：輕量級，高並發，延遲敏感
即時數據分析、秒殺計數器、緩存等。
其他MQ：重量級，高並發，異步
批量數據異步處理、並行任務串行化，高負載任務的負載均衡等。