RabbitMQ 面試題
1、什麼是 rabbitmq
2、為什麼要使用 rabbitmq
3、使用 rabbitmq 的場景
4、如何確定消息正确地發送至 RabbitMQ？ 如何確定消息接收方消費了消息？
5.如何避免消息重複投遞或重複消費？
6、消息基于什麼傳輸？
7、消息如何分發？
8、消息怎麼路由？
9、如何確定消息不丢失？
10、使用 RabbitMQ 有什麼好處？
11、RabbitMQ 的叢集
12、mq 的缺點
采用 AMQP 進階消息隊列協定的一種消息隊列技術,最大的特點就是消費并不需要確定提供方存在,實作了服務之間的高度解耦
（1）在分布式系統下具備異步,削峰,負載均衡等一系列進階功能;
（2）擁有持久化的機制，程序消息，隊列中的資訊也可以儲存下來。
（3）實作消費者和生産者之間的解耦。
（4）對于高并發場景下，利用消息隊列可以使得同步通路變為串行通路達到一定量的限流，利于資料庫的操作。
（5）可以使用消息隊列達到異步下單的效果，排隊中，背景進行邏輯下單。
（1）服務間異步通信
（2）順序消費
（3）定時任務
（4）請求削峰
發送方确認模式
将信道設定成 confirm 模式（發送方确認模式），則所有在信道上釋出的消息都會被指派一個唯一的 ID。
一旦消息被投遞到目的隊列後，或者消息被寫入磁盤後（可持久化的消息），信道會發送一個确認給生産者（包含消息唯一 ID）。
如果 RabbitMQ 發生内部錯誤進而導緻消息丢失，會發送一條 nack（notacknowledged，未确認）消息。
發送方确認模式是異步的，生産者應用程式在等待确認的同時，可以繼續發送消息。當确認消息到達生産者應用程式，生産者應用程式的回調方法就會被觸發來處理确認消息。
接收方确認機制
消費者接收每一條消息後都必須進行确認（消息接收和消息确認是兩個不同操作）。隻有消費者确認了消息，RabbitMQ 才能安全地把消息從隊列中删除。
這裡并沒有用到逾時機制，RabbitMQ 僅通過 Consumer 的連接配接中斷來确認是否需要重新發送消息。也就是說，隻要連接配接不中斷，RabbitMQ 給了 Consumer 足夠長的時間來處理消息。保證資料的最終一緻性；
下面羅列幾種特殊情況
（1）如果消費者接收到消息，在确認之前斷開了連接配接或取消訂閱，RabbitMQ 會認為消息沒有被分發，然後重新分發給下一個訂閱的消費者。（可能存在消息重複消費的隐患，需要去重）
（1）2如果消費者接收到消息卻沒有确認消息，連接配接也未斷開，則 RabbitMQ 認為該消費者繁忙，将不會給該消費者分發更多的消息。
在消息生産時，MQ 内部針對每條生産者發送的消息生成一個 inner-msg-id，作為去重的依據（消息投遞失敗并重傳），避免重複的消息進入隊列；在消息消費時，要求消息體中必須要有一個 bizId（對于同一業務全局唯一，如支付 ID、訂單 ID、文章 ID 等）作為去重的依據，避免同一條消息被重複消費。
由于 TCP 連接配接的建立和銷毀開銷較大，且并發數受系統資源限制，會造成性能瓶頸。RabbitMQ 使用信道的方式來傳輸資料。信道是建立在真實的 TCP 連接配接内的虛拟連接配接，且每條 TCP 連接配接上的信道數量沒有限制。
若該隊列至少有一個消費者訂閱，消息将以循環（round-robin）的方式發送給消費者。每條消息隻會分發給一個訂閱的消費者（前提是消費者能夠正常處理消息并進行确認）。通過路由可實作多消費的功能
消息提供方->路由->一至多個隊列消息釋出到交換器時，消息将擁有一個路由鍵（routing key），在消息建立時設定。通過隊列路由鍵，可以把隊列綁定到交換器上。消息到達交換器後，RabbitMQ 會将消息的路由鍵與隊列的路由鍵進行比對（針對不同的交換器有不同的路由規則）；
常用的交換器主要分為一下三種：
fanout：如果交換器收到消息，将會廣播到所有綁定的隊列上
direct：如果路由鍵完全比對，消息就被投遞到相應的隊列
topic：可以使來自不同源頭的消息能夠到達同一個隊列。 使用 topic 交換器時，可以使用通配符
消息持久化，當然前提是隊列必須持久化
RabbitMQ 確定持久性消息能從伺服器重新開機中恢複的方式是，将它們寫入磁盤上的一個持久化日志檔案，當釋出一條持久性消息到持久交換器上時，Rabbit 會在消息送出到日志檔案後才發送響應。一旦消費者從持久隊列中消費了一條持久化消息，RabbitMQ 會在持久化日志中把這條消息标記為等待垃圾收集。如果持久化消息在被消費之前 RabbitMQ 重新開機，那麼 Rabbit 會自動重建交換器和隊列（以及綁定），并重新釋出持久化日志檔案中的消息到合适的隊列。
（1）服務間高度解耦
（2）異步通信性能高
（3）流量削峰
鏡像叢集模式
你建立的 queue，無論中繼資料還是 queue 裡的消息都會存在于多個執行個體上，然後每次你寫消息到 queue 的時候，都會自動把消息到多個執行個體的 queue 裡進行消息同步。
好處在于，你任何一個機器當機了，沒事兒，别的機器都可以用。壞處在于，第一，這個性能開銷也太大了吧，消息同步所有機器，導緻網絡帶寬壓力和消耗很重！第二，這麼玩兒，就沒有擴充性可言了，如果某個 queue 負載很重，你加機器，新增的機器也包含了這個 queue 的所有資料，并沒有辦法線性擴充你的 queue
（1）系統可用性降低
系統引入的外部依賴越多，越容易挂掉，本來你就是 A 系統調用 BCD 三個系統的接口就好了，人 ABCD 四個系統好好的，沒啥問題，你偏加個 MQ 進來，萬一MQ 挂了咋整？MQ 挂了，整套系統崩潰了，你不就完了麼。
（2）系統複雜性提高
硬生生加個 MQ 進來，你怎麼保證消息沒有重複消費？怎麼處理消息丢失的情況？怎麼保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已
（3）一緻性問題
A 系統處理完了直接傳回成功了，人都以為你這個請求就成功了；但是問題是，要是 BCD 三個系統那裡，BD 兩個系統寫庫成功了，結果 C 系統寫庫失敗了，咋整？你這資料就不一緻了。
是以消息隊列實際是一種非常複雜的架構，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術方案和架構來規避掉，最好之後，你會發現，媽呀，系統複雜度提升了一個數量級，也許是複雜了 10 倍。但是關鍵時刻，用，還是得用的。歡迎大家關注我的公種浩【程式員追風】，2019年多家公司java面試題整理了1000多道400多頁pdf文檔，文章都會在裡面更新，整理的資料也會放在裡面。
最後
歡迎大家一起交流，喜歡文章記得關注我點個贊喲，感謝支援！