135.rabbitmq 的使用場景有哪些？
單反單收，單發多收，發布訂閱，按路由發送，按主題發送
136.rabbitmq 有哪些重要的角色？
Server,Consumer,Producer
137.rabbitmq 有哪些重要的組件？
1.Server(broker): 接受客戶端連接，實現AMQP消息隊列和路由功能的進程。 2.Virtual Host:其實是一個虛擬概念，類似於權限控制組，一個Virtual Host里面可以有若干個Exchange和Queue，但是權限控制的最小粒度是Virtual Host 3.Exchange:接受生產者發送的消息，並根據Binding規則將消息路由給服務器中的隊列。ExchangeType決定了Exchange路由消息的行為，例如，在RabbitMQ中，ExchangeType有direct、Fanout和Topic三種，不同類型的Exchange路由的行為是不一樣的。 4.Message Queue：消息隊列，用於存儲還未被消費者消費的消息。 5.Message: 由Header和Body組成，Header是由生產者添加的各種屬性的集合，包括Message是否被持久化、由哪個Message Queue接受、優先級是多少等。而Body是真正需要傳輸的APP數據。 6.Binding:Binding聯系了Exchange與Message Queue。Exchange在與多個Message Queue發生Binding后會生成一張路由表，路由表中存儲着Message Queue所需消息的限制條件即Binding Key。當Exchange收到Message時會解析其Header得到Routing Key，Exchange根據Routing Key與Exchange Type將Message路由到Message Queue。Binding Key由Consumer在Binding Exchange與Message Queue時指定，而Routing Key由Producer發送Message時指定，兩者的匹配方式由Exchange Type決定。 7.Connection:連接，對於RabbitMQ而言，其實就是一個位於客戶端和Broker之間的TCP連接。 8.Channel:信道，僅僅創建了客戶端到Broker之間的連接后，客戶端還是不能發送消息的。需要為每一個Connection創建Channel，AMQP協議規定只有通過Channel才能執行AMQP的命令。一個Connection可以包含多個Channel。之所以需要Channel，是因為TCP連接的建立和釋放都是十分昂貴的，如果一個客戶端每一個線程都需要與Broker交互，如果每一個線程都建立一個TCP連接，暫且不考慮TCP連接是否浪費，就算操作系統也無法承受每秒建立如此多的TCP連接。RabbitMQ建議客戶端線程之間不要共用Channel，至少要保證共用Channel的線程發送消息必須是串行的，但是建議盡量共用Connection。 9.Command:AMQP的命令，客戶端通過Command完成與AMQP服務器的交互來實現自身的邏輯。例如在RabbitMQ中，客戶端可以通過publish命令發送消息，txSelect開啟一個事務，txCommit提交一個事務。
138.rabbitmq 中 vhost 的作用是什么？
虛擬主機，一個broker里可以開設多個vhost，用作不同用戶的權限分離。
139.rabbitmq 的消息是怎么發送的？
（1）客戶端連接到消息隊列服務器，打開一個channel。 （2）客戶端聲明一個exchange，並設置相關屬性。 （3）客戶端聲明一個queue，並設置相關屬性。 （4）客戶端使用routing key，在exchange和queue之間建立好綁定關系。 （5）客戶端投遞消息到exchange。
140.rabbitmq 怎么保證消息的穩定性？
費者在消費完消息后發送一個回執給RabbitMQ，RabbitMQ收到消息回執（Message acknowledgment）后才將該消息從Queue中移除；如果RabbitMQ沒有收到回執並檢測到消費者的RabbitMQ連接斷開，則RabbitMQ會將該消息發送給其他消費者（如果存在多個消費者）進行處理。這里不存在timeout概念，一個消費者處理消息時間再長也不會導致該消息被發送給其他消費者，除非它的RabbitMQ連接斷開。
141.rabbitmq 怎么避免消息丟失？
將Queue與Message都設置為可持久化的（durable），這樣可以保證絕大部分情況下我們的RabbitMQ消息不會丟失。但依然解決不了小概率丟失事件的發生（比如RabbitMQ服務器已經接收到生產者的消息，但還沒來得及持久化該消息時RabbitMQ服務器就斷電了），如果我們需要對這種小概率事件也要管理起來，那么我們要用到事務。
142.要保證消息持久化成功的條件有哪些？
queue，exchange和Message都持久化；
引入RabbitMQ的mirrored-queue即鏡像隊列，這個相當於配置了副本，當master在此特殊時間內crash掉，可以自動切換到slave，這樣有效的保障了HA,；
要在producer引入事務機制或者Confirm機制來確保消息已經正確的發送至broker端
143.rabbitmq 持久化有什么缺點？
一、如果消息的自動確認為true，那么在消息被接收以后，RabbitMQ就會刪除該消息，假如消費端此時宕機，那么消息就會丟失。因此需要將消息設置為手動確認。
二、設置手動確認會出現另一個問題，如果消息已被成功處理，但在消息確認過程中出現問題，那么在消費端重啟后，消息會重新被消費。
三、發送端為了保證消息會成功投遞，一般會設定重試。如果消息發送至RabbitMQ之后，在RabbitMQ回復已成功接收消息過程中出現異常，那么發送端會重新發送該消息，從而造成消息重復發送。
四、RabbitMQ的消息磁盤寫入，如果出現問題，也會造成消息丟失。
144.rabbitmq 有幾種廣播類型？
fanout: 所有bind到此exchange的queue都可以接收消息（純廣播，綁定到RabbitMQ的接受者都能收到消息）；
direct: 通過routingKey和exchange決定的那個唯一的queue可以接收消息；
topic:所有符合routingKey(此時可以是一個表達式)的routingKey所bind的queue可以接收消息；
145.rabbitmq 怎么實現延遲消息隊列？
第一步：給隊列或者指定消息設置過期時間（TTL），過期后變成 死信
第二部：設置死信的轉發規則（如果沒有任何規則，則直接丟棄死信） ，從新消費
146.rabbitmq 集群有什么用？
- 允許消費者和生產者在Rabbit節點崩潰的情況下繼續運行；
- 通過增加節點來擴展Rabbit處理更多的消息，承載更多的業務量；
147.rabbitmq 節點的類型有哪些？
內存節點、磁盤節點。顧名思義內存節點就是將所有數據放在內存，磁盤節點將數據放在磁盤
148.rabbitmq 集群搭建需要注意哪些問題？
每個節點Cookie的同步；主機之間 必須可以相互識別並可達，/etc/hosts文件配置必須准確
149.rabbitmq 每個節點是其他節點的完整拷貝嗎？為什么？
不是，隊列的完整信息只放在一個節點，其他節點存放的是該隊列的指針
150.rabbitmq 集群中唯一一個磁盤節點崩潰了會發生什么情況？
如果唯一的磁盤節點崩潰，集群是可以保持運行的，但不能更改任何東西。
- 不能創建隊列
- 不能創建交換器
- 不能創建綁定
- 不能添加用戶
- 不能更改權限
- 不能添加和刪除集群幾點
151.rabbitmq 對集群節點停止順序有要求嗎？
- 啟動順序：磁盤節點 => 內存節點
- 關閉順序：內存節點 => 磁盤節點