一、如何保證消息的順序性
啥？我該怎么保證從消息隊列里拿到的數據按順序執行。
這是MQ面試必問的問題之一。第一看看你了解不了解順序這個事，第二看看你有沒有辦法保證消息是有序的。這是生成環境中常見的問題。
mysql的binlog同步。在mysql里增刪改3條binlog。接着這三條binlog發送到MQ里面。到消費出來依次執行。起碼要保證人家是按照順序來的吧。不然本來是增加、修改、刪除。你愣是給更改了順序，換成了刪除、修改、增加。這就亂了。
1、RabbitMQ可能出現數據錯亂問題
1個生產者，多個消費者。生成的順序是數據1、數據2、數據3.消費的數據是數據2、數據1、數據3。沒有按之前的順序。
2、如何保證消息的順序性
搞3個Queue，每個消費者就消費其中的一個Queue。把需要保證順序的數據發到1個Queue里去。
二、如何解決消息積壓
如何解決消息隊列的延時以及過期失效問題？消息隊列滿了以后該怎么處理？有幾百分消息持續積壓幾個小時，說說怎么解決。
這些問法，本質上都是針對場景，都是說可能你的消息端出來問題，不消費了。或者消費的及其滿。接着就坑爹了。可能你的消息隊列集群的磁盤都快滿了。都沒人消費，這個時候怎么辦？或者是積壓了幾個小時，怎么辦？或者是積壓時間太長了，導致比如RabbitMQ設置了過期時間后就沒了。其實這事，線上挺常見的，一般不出，一出就是大case。舉個例子，消費端每次消費之后要寫mysql，結果mysql掛了，消費端不動了，或者是消費端出了什么叉子，導致消費速度灰常慢。
1、快速處理積壓的消息
（1）大量消息在MQ里積壓幾個小時，還沒解決
幾千萬條數據在MQ里，積壓了七八個小時。這個時候就是恢復consumer的問題。讓它恢復消費速度，然后傻傻地等待幾個小時消費完畢。這個肯定不能再面試的時候說。1個消費者1秒時1000條，1秒3個消費者是3000條。1分鍾是18萬條。1個小時是1000多萬條。如果積壓了上萬條數據，即使消費者恢復了，也大概需要1個多小時才能恢復過來。
原來3個消費者1個小時。現在30個消費者，需要10分鍾搞定。
一般情況下，這個時候只能做臨時擴容了。具體操作步驟和思路如下：
① 先修改consumer的問題，確保其恢復消費速度，然后將現有consumer都停掉。
② 新建1個topic，partition是原來的10倍，臨時建立好原來10倍或者20倍的Queue。
③ 然后寫一個臨時的分發數據的consumer程序，這個程序部署上去，消費積壓的數據。消費之后，不做耗時的處理。直接均勻輪訓寫入臨時建立好的10倍數量的Queue。
④ 接着征用10倍的機器來部署consume。每一批consumer消費1個臨時的queue。
⑤ 這種做法，相當於將queue資源和consume資源擴大10倍，以10倍的速度來消費數據。
⑥ 等快速消費完積壓數據之后，恢復原來的部署架構，重新用原先的consumer來消費消息。
（2）過期失效了怎么辦
過期失效就是TTL。如果消息在Queue中積壓超過一定的時間就會被RabbitMQ給清理掉。這個數據就沒了。這就不是數據積壓MQ中了，而是大量的數據會直接搞丟。
在這種情況下，增加consume消費積壓就不起作用了。此時，只能將丟失的那批數據，寫個臨時的程序，一點一點查出來，然后再灌入MQ中，把白天丟失的數據補回來。
三、設計消息隊列中間件
如何讓你來設計消息隊列中間件，如何設計？
主要考察兩塊。
①是有沒有對某個消息隊列做過較為深入的原理的了解。或者從整體把握一個mq的架構原理。
②是看看你的設計能力，給你一個常見的系統，就是消息隊列系統，看能夠從全局把握一下整體架構設計的關鍵點。
比如說，這個消息隊列，我們從以下幾個方面來了解下：
1、首先MQ得支持可伸縮性吧。就是需要的時候增加吞吐量和容量？
2、其次，需要考慮一下MQ的數據是不是要持久化到磁盤
3、再次，考慮一下MQ的可用性。
4、最后，考慮一下能不能支持數據零丟失
原文鏈接：https://blog.csdn.net/qq_26545305/article/details/108203087