• AMQP協(xié)議
• Exchange
• 消息如何保證100％投遞
• 什么是生產端的可靠性投遞？
• 消息冪等性
• 高并發(fā)的情況下如何避免消息重復消費
• confirm 確認消息、Return返回消息
• return消息機制
• 消費端自定義監(jiān)聽
• 消費端限流
• 消費端ack與重回隊列
• TTL隊列/消息
• 死信隊列
• rabbitMQ集群模式
• HAProxy性能為何這么好？
• keepAlive
• Keepalived如何實現(xiàn)高可用

RabbitMQ是基于AMQP協(xié)議的，通過使用通用協(xié)議就可以做到在不同語言之間傳遞。

AMQP協(xié)議

核心概念

1. server：又稱broker，接受客戶端連接，實現(xiàn)AMQP實體服務。
2. connection：連接和具體broker網絡連接。
3. channel：網絡信道，幾乎所有操作都在channel中進行，channel是消息讀寫的通道?？蛻舳丝梢越⒍鄠€channel，每個channel表示一個會話任務。
4. message：消息，服務器和應用程序之間傳遞的數(shù)據，由properties和body組成。properties可以對消息進行修飾，比如消息的優(yōu)先級，延遲等高級特性；body是消息實體內容。
5. Virtual host：虛擬主機，用于邏輯隔離，最上層消息的路由。一個Virtual host可以若干個Exchange和Queue，同一個Virtual host不能有同名的Exchange或Queue。
6. Exchange：交換機，接受消息，根據路由鍵轉發(fā)消息到綁定的隊列上。
7. banding：Exchange和Queue之間的虛擬連接，binding中可以包括routing key
8. routing key：一個路由規(guī)則，虛擬機根據他來確定如何路由 一條消息。
9. Queue：消息隊列，用來存放消息的隊列。

Exchange

交換機的類型，direct、topic、fanout、headers，durability（是否需要持久化true需要）auto delete當最后一個綁定Exchange上的隊列被刪除Exchange也刪除。

1. Direct Exchange,所有發(fā)送到Direct Exchange的消息被轉發(fā)到RouteKey 中指定的Queue,Direct Exchange可以使用默認的默認的Exchange （default Exchange），默認的Exchange會綁定所有的隊列，所以Direct可以直接使用Queue名（作為routing key ）綁定。或者消費者和生產者的routing key完全匹配。
2. Toptic Exchange,是指發(fā)送到Topic Exchange的消息被轉發(fā)到所有關心的Routing key中指定topic的Queue上。Exchange 將routing key和某Topic進行模糊匹配，此時隊列需要綁定一個topic。所謂模糊匹配就是可以使用通配符，“#”可以匹配一個或多個詞，“”只匹配一個詞比如“l(fā)og.#”可以匹配“l(fā)og.info.test” "log. "就只能匹配log.error。
3. Fanout Exchange:不處理路由鍵，只需簡單的將隊列綁定到交換機上。發(fā)送到改交換機上的消息都會被發(fā)送到與該交換機綁定的隊列上。Fanout轉發(fā)是最快的。

消息如何保證100％投遞

什么是生產端的可靠性投遞？

1. 保證消息的成功發(fā)出
2. 保證MQ節(jié)點節(jié)點的成功接收
3. 發(fā)送端MQ節(jié)點（broker）收到消息確認應答
4. 完善消息進行補償機制

可靠性投遞保障方案

消息落庫，對消息進行打標

消息的延遲投遞

在高并發(fā)場景下，每次進行db的操作都是每場消耗性能的。我們使用延遲隊列來減少一次數(shù)據庫的操作。

消息冪等性

我對一個動作進行操作，我們肯能要執(zhí)行100次1000次，對于這1000次執(zhí)行的結果都必須一樣的。比如單線程方式下執(zhí)行update count-1的操作執(zhí)行一千次結果都是一樣的，所以這個更新操作就是一個冪等的，如果是在并發(fā)不做線程安全的處理的情況下update一千次操作結果可能就不是一樣的，所以并發(fā)情況下的update操作就不是一個冪等的操作。對應到消息隊列上來，就是我們即使受到了多條一樣的消息，也和消費一條消息效果是一樣的。

高并發(fā)的情況下如何避免消息重復消費

1. 唯一id+加指紋碼，利用數(shù)據庫主鍵去重。

   優(yōu)點：實現(xiàn)簡單

   缺點：高并發(fā)下有數(shù)據寫入瓶頸。

2. 利用Redis的原子性來實習。

   使用Redis進行冪等是需要考慮的問題

• 是否進行數(shù)據庫落庫，落庫后數(shù)據和緩存如何做到保證冪等（Redis  和數(shù)據庫如何同時成功同時失敗）？
• 如果不進行落庫，都放在Redis中如何這是Redis和數(shù)據庫的同步策略？還有放在緩存中就能百分之百的成功嗎？

confirm 確認消息、Return返回消息

理解confirm消息確認機制

• 消息的確認，指生產者收到投遞消息后，如果Broker收到消息就會給我們  的生產者一個應答，生產者接受應答來確認broker是否收到消息。

如何實現(xiàn)confirm確認消息。

• 在Channel上開啟確認模式：channel.confirmSelect()
• 在channel上添加監(jiān)聽：addConfirmListener，監(jiān)聽成功和失敗的結果，具體結果對消息進行重新發(fā)送或者記錄日志。

return消息機制

Return消息機制處理一些不可路由的消息，我們的生產者通過指定一個Exchange和Routinkey，把消息送達到某一個隊列中去，然后我們消費者監(jiān)聽隊列進行消費處理！

在某些情況下，如果我們在發(fā)送消息的時候當Exchange不存在或者指定的路由key路由找不到，這個時候如果我們需要監(jiān)聽這種不可到達的消息，就要使用Return Listener！

Mandatory 設置為true則會監(jiān)聽器會接受到路由不可達的消息，然后處理。如果設置為false，broker將會自動刪除該消息。

消費端自定義監(jiān)聽

消費端限流

假設我們有個場景，首先，我們有個rabbitMQ服務器上有上萬條消息未消費，然后我們隨便打開一個消費者客戶端，會出現(xiàn)：巨量的消息瞬間推送過來，但是我們的消費端無法同時處理這么多數(shù)據。

這時就會導致你的服務崩潰。其他情況也會出現(xiàn)問題，比如你的生產者與消費者能力不匹配，在高并發(fā)的情況下生產端產生大量消息，消費端無法消費那么多消息。

• rabbitMQ提供了一種qos（服務質量保證）的功能，即非自動確認消息的前提下，如果有一定數(shù)目的消息（通過consumer或者Channel設置qos）未被確認，不進行新的消費。

void basicQOS(unit prefetchSize,ushort prefetchCount,Boolean global)方法。

• prefetchSize:0 單條消息的大小限制。0就是不限制，一般都是不限制。
• prefetchCount: 設置一個固定的值，告訴rabbitMQ不要同時給一個消費者推送多余N個消息，即一旦有N個消息還沒有ack，則consumer將block掉，直到有消息ack
• global：truefalse 是否將上面的設置用于channel，也是就是說上面設置的限制是用于channel級別的還是consumer的級別的。

消費端ack與重回隊列

• 消費端進行消費的時候，如果由于業(yè)務異常我們可以進行日志的記錄，然后進行補償！（也可以加上最大努力次數(shù)的嘗試）
• 如果由于服務器宕機等嚴重問題，那我們就需要手動進行ack保證消費端的消費成功！

消息重回隊列

• 重回隊列就是為了對沒有處理成功的消息，把消息重新投遞給broker！
• 實際應用中一般都不開啟重回隊列。

TTL隊列/消息

TTL time to live 生存時間。

• 支持消息的過期時間，在消息發(fā)送時可以指定。
• 支持隊列過期時間，在消息入隊列開始計算時間，只要超過了隊列的超時時間配置，那么消息就會自動的清除。

死信隊列

死信隊列：DLX，Dead-Letter-Exchange

利用DLX，當消息在一個隊列中變成死信（dead message，就是沒有任何消費者消費）之后，他能被重新publish到另一個Exchange，這個Exchange就是DLX。

消息變?yōu)樗佬诺膸追N情況：

1. 消息被拒絕（basic.reject/basic.nack）同時requeue=false（不重回隊列）
2. TTL過期
3. 隊列達到最大長度

DLX也是一個正常的Exchange，和一般的Exchange沒有任何的區(qū)別，他能在任何的隊列上被指定，實際上就是設置某個隊列的屬性。

當這個隊列出現(xiàn)死信的時候，RabbitMQ就會自動將這條消息重新發(fā)布到Exchange上去，進而被路由到另一個隊列?？梢员O(jiān)聽這個隊列中的消息作相應的處理，這個特性可以彌補rabbitMQ以前支持的immediate參數(shù)的功能。

死信隊列的設置

• 設置Exchange和Queue，然后進行綁定

Exchange: dlx.exchange(自定義的名字)

queue: dlx.queue（自定義的名字）

routingkey: #（#表示任何routingkey出現(xiàn)死信都會被路由過來）

然后正常的聲明交換機、隊列、綁定，只是我們在隊列上加上一個參數(shù)：

arguments.put("x-dead-letter-exchange","dlx.exchange");

rabbitMQ集群模式

1. 主備模式：實現(xiàn)rabbitMQ高可用集群，一般在并發(fā)量和數(shù)據不大的情況下，這種模式好用簡單。又稱warren模式。（區(qū)別于主從模式，主從模式主節(jié)點提供寫操作，從節(jié)點提供讀操作，主備模式從節(jié)點不提供任何讀寫操作，只做備份）如果主節(jié)點宕機備份從節(jié)點會自動切換成主節(jié)點，提供服務。
2. 集群模式：經典方式就是Mirror模式，保證100%數(shù)據不丟失，實現(xiàn)起來也是比較簡單。

• 鏡像隊列，是rabbitMQ數(shù)據高可用的解決方案，主要是實現(xiàn)數(shù)據同步，一般來說是由2-3節(jié)點實現(xiàn)數(shù)據同步，（對于100%消息可靠性解決方案一般是3個節(jié)點）

多活模式：這種模式也是實現(xiàn)異地數(shù)據復制的主流模式，因為shovel模式配置相對復雜，所以一般來說實現(xiàn)異地集群都是使用這種雙活，多活的模式，這種模式需要依賴rabbitMQ的federation插件，可以實現(xiàn)持續(xù)可靠的AMQP數(shù)據。

rabbitMQ部署架構采用雙中心模式（多中心）在兩套（或多套）數(shù)據中心個部署一套rabbitMQ集群，各中心的rabbitMQ服務需要為提供正常的消息業(yè)務外，中心之間還需要實現(xiàn)部分隊列消息共享。

多活架構如下：

federation插件是一個不需要構建Cluster，而在Brokers之間傳輸消息的高性能插件，federation可以在brokers或者cluster之間傳輸消息，連接的雙方可以使用不同的users或者virtual host雙方也可以使用不同版本的erlang或者rabbitMQ版本。federation插件可以使用AMQP協(xié)議作為通訊協(xié)議，可以接受不連續(xù)的傳輸。

Federation Exchanges,可以看成Downstream從Upstream主動拉取消息，但 并不是拉取所有消息，必須是在Downstream上已經明確定義Bindings關系的 Exchange,也就是有實際的物理Queue來接收消息，才會從Upstream拉取消息 到Downstream。

使用AMQP協(xié)議實施代理間通信，Downstream 會將綁定關系組合在一起， 綁定/解除綁定命令將發(fā)送到Upstream交換機。

因此，F(xiàn)ederation Exchange只接收具有訂閱的消息。

HAProxy是一款提供高可用性、負載均衡以及基于TCP (第四層)和HTTP (第七層)應用的代理軟件,支持虛擬主機，它是免費、快速并且可靠的一種解決 方案。

HAProxy特別適用于那些負載特大的web站點，這些站點通常又需要會 話保持或七層處理。HAProxy運行在時下的硬件上，完全可以支持數(shù)以萬計的 并發(fā)連接。

并且它的運行模式使得它可以很簡單安全的整合進您當前的架構中 同時可以保護你的web服務器不被暴露到網絡上。

HAProxy性能為何這么好？

1. 單進程、事件驅動模型顯著降低了.上下文切換的開銷及內存占用.
2. 在任何可用的情況下，單緩沖(single buffering)機制能以不復制任何數(shù)據的方式完成讀寫操作，這會節(jié)約大量的CPU時鐘周期及內存帶寬
3. 借助于Linux 2.6 (>= 2.6.27.19). 上的splice()系統(tǒng)調用，HAProxy可以實現(xiàn)零復制轉發(fā)(Zero-copy forwarding),在Linux 3.5及以上的OS中還可以實現(xiàn)心零復制啟動(zero-starting)
4. 內存分配器在固定大小的內存池中可實現(xiàn)即時內存分配，這能夠顯著減少創(chuàng)建一個會話的時長
5. 樹型存儲:側重于使用作者多年前開發(fā)的彈性二叉樹，實現(xiàn)了以O(log(N))的低開銷來保持計時器命令、保持運行隊列命令及管理輪詢及最少連接隊列

keepAlive

KeepAlived軟件主要是通過VRRP協(xié)議實現(xiàn)高可用功能的。VRRP是 Virtual Router RedundancyProtocol(虛擬路由器冗余協(xié)議)的縮寫, VRRP出現(xiàn)的目的就是為了解決靜態(tài)路由單點故障問題的，它能夠保證當 個別節(jié)點宕機時，整個網絡可以不間斷地運行所以，Keepalived - -方面 具有配置管理LVS的功能，同時還具有對LVS下面節(jié)點進行健康檢查的功 能，另一方面也可實現(xiàn)系統(tǒng)網絡服務的高可用功能

keepAlive的作用

1. 管理LVS負載均衡軟件
2. 實現(xiàn)LVS集群節(jié)點的健康檢查中
3. 作為系統(tǒng)網絡服務的高可用性(failover)

Keepalived如何實現(xiàn)高可用

Keepalived高可用服務對之間的故障切換轉移，是通過VRRP (Virtual Router Redundancy Protocol ,虛擬路由器冗余協(xié)議)來實現(xiàn)的。

在Keepalived服務正常工作時，主Master節(jié)點會不斷地向備節(jié)點發(fā)送( 多播的方式)心跳消息，用以告訴備Backup節(jié)點自己還活看，當主Master節(jié)點發(fā)生故障時，就無法發(fā)送心跳消息，備節(jié)點也就因此無法繼續(xù)檢測到來自主Master節(jié)點的心跳了，于是調用自身的接管程序，接管主Master節(jié)點的IP資源及服務。

而當主Master節(jié)點恢復時備Backup節(jié)點又會釋放主節(jié)點故障時自身接管的IP資源及服務，恢復到原來的備用角色。