rabbitMQ是基於AMQP協議的，經過使用通用協議就能夠作到在不一樣語言之間傳遞。web
核心概念面試
很是強悍的 RabbitMQ 總結，看完別再說你不會RabbitMQ數據庫
交換機的類型，direct、topic、fanout、headers，durability（是否須要持久化true須要）auto delete當最後一個綁定Exchange上的隊列被刪除Exchange也刪除。安全
The default exchange is implicitly bound to every queue, with a routing key equal to the queue name. It is not possible to explicitly bind to, or unbind from the default exchange. It also cannot be deleted.服務器
很是強悍的 RabbitMQ 總結，看完別再說你不會RabbitMQ網絡
在高併發場景下，每次進行db的操做都是很是消耗性能的。咱們使用延遲隊列來減小一次數據庫的操做。架構
冪等性是什麼？併發
我對一個動做進行操做，咱們肯能要執行100次1000次，對於這1000次執行的結果都必須同樣的。好比單線程方式下執行update count-1的操做執行一千次結果都是同樣的，因此這個更新操做就是一個冪等的，若是是在併發不作線程安全的處理的狀況下update一千次操做結果可能就不是同樣的，因此併發狀況下的update操做就不是一個冪等的操做。對應到消息隊列上來，就是咱們即便收到了多條同樣的消息，也和消費一條消息效果是同樣的。負載均衡
理解confirm消息確認機制高併發
Return消息機制處理一些不可路由的消息，咱們的生產者經過指定一個Exchange和Routinkey，把消息送達到某一個隊列中去，而後咱們消費者監聽隊列進行消費處理！在某些狀況下，若是咱們在發送消息的時候當Exchange不存在或者指定的路由key路由找不到，這個時候若是咱們須要監聽這種不可到達的消息，就要使用Return Listener！
Mandatory 設置爲true則會監聽器會接受到路由不可達的消息，而後處理。若是設置爲false，broker將會自動刪除該消息。
什麼是消費端的限流？
假設咱們有個場景，首先，咱們有個rabbitMQ服務器上有上萬條消息未消費，而後咱們隨便打開一個消費者客戶端，會出現：巨量的消息瞬間推送過來，可是咱們的消費端沒法同時處理這麼多數據。這時就會致使你的服務崩潰。 其餘狀況也會出現問題，好比你的生產者與消費者能力不匹配，在高併發的狀況下生產端產生大量消息，消費端沒法消費那麼多消息。
void basicQOS(unit prefetchSize,ushort prefetchCount,Boolean global)方法。
TTL time to live 生存時間。
死信隊列：DLX，Dead-Letter-Exchange
利用DLX，當消息在一個隊列中變成死信（dead message，就是沒有任何消費者消費）以後，他能被從新publish到另外一個Exchange，這個Exchange就是DLX。
消息變爲死信的幾種狀況：
DLX也是一個正常的Exchange，和通常的Exchange沒有任何的區別，他能在任何的隊列上被指定，實際上就是設置某個隊列的屬性。當這個隊列出現死信的時候，RabbitMQ就會自動將這條消息從新發布到Exchange上去，進而被路由到另外一個隊列。能夠監聽這個隊列中的消息做相應的處理，這個特性能夠彌補rabbitMQ之前支持的immediate參數的功能。
死信隊列的設置
很是強悍的 RabbitMQ 總結，看完別再說你不會RabbitMQ
很是強悍的 RabbitMQ 總結，看完別再說你不會RabbitMQ
federation插件是一個不須要構建Cluster，而在Brokers之間傳輸消息的高性能插件，federation能夠在brokers或者cluster之間傳輸消息，鏈接的雙方可使用不一樣的users或者virtual host雙方也可使用不一樣版本的erlang或者rabbitMQ版本。federation插件可使用AMQP協議做爲通信協議，能夠接受不連續的傳輸。
很是強悍的 RabbitMQ 總結，看完別再說你不會RabbitMQ
Federation Exchanges,能夠當作Downstream從Upstream主動拉取消息，但並非拉取全部消息，必須是在Downstream.上已經明肯定義Bindings關係的Exchange,也就是有實際的物理Queue來接收消息，纔會從Upstream拉取消息到Downstream。使用AMQP協議實施代理間通訊，Downstream 會將綁定關係組合在一塊兒， 綁定/解除綁定命令將發送到Upstream交換機。所以，FederationExchange只接收具備訂閱的消息.
HAProxy是一款提供高可用性、負載均衡以及基於TCP (第四層)和HTTP(第七層)應用的代理軟件,支持虛擬主機，它是免費、快速而且可靠的一種解決方案。 HAProxy特別適用於那些負載特大的web站點，這些站點一般又須要會話保持或七層處理。HAProxy運行在時下的硬件上，徹底能夠支持數以萬計的併發鏈接。而且它的運行模式使得它能夠很簡單安全的整合進您當前的架構中同時能夠保護你的web服務器不被暴露到網絡上。
數據的方式完成讀寫操做，這會節約大量的CPU時鐘週期及內存帶寬
零複製轉發(Zero-copy forwarding),在Linux 3.5及以上的OS中還能夠實現心零複製啓動(zero-starting)
建一個會話的時長
的低開銷來保持計時器命令、保持運行隊列命令及管理輪詢及最少鏈接隊列
KeepAlived軟件主要是經過VRRP協議實現高可用功能的。VRRP是Virtual Router RedundancyProtocol(虛擬路由器冗餘協議)的縮寫,VRRP出現的目的就是爲了解決靜態路由單點故障問題的，它可以保證當個別節點宕機時，整個網絡能夠不間斷地運行因此，Keepalived - -方面具備配置管理LVS的功能，同時還具備對LVS下面節點進行健康檢查的功能，另外一方面也可實現系統網絡服務的高可用功能
Keepalived高可用服務對之間的故障切換轉移，是經過VRRP (Virtual RouterRedundancy Protocol ,虛擬路由器冗餘協議)來實現的。在Keepalived服務正常工做時，主Master節點會不斷地向備節點發送( 多播的方式)心跳消息，用以告訴備Backup節點本身還活看，當主Master節點發生故障時，就沒法發送心跳消息，備節點也就所以沒法繼續檢測到來自主Master節點的心跳了，因而調用自身的接管程序，接管主Master節點的IP資源及服務。而當主Master節點恢復時備Backup節點又會釋放主節點故障時自身接管的IP資源及服務，恢復到原來的備用角色
領取更多Java核心技術主流資料和大廠面試題，轉發+關注私信我