一酥馍、MQ的基本概念
1 .1MQ概述
MQ全稱(chēng) Message Queue（消息隊(duì)列）衡创，是在消息的傳輸過(guò)程中保存消息的容器俄烁。多用于分布式系統(tǒng)之間進(jìn)行通信它呀。
1.2MQ的優(yōu)勢(shì)和劣勢(shì)
-
應(yīng)用解耦
image.png -
異步提速
image.png -
削峰填谷
image.png
image.png
1.3常見(jiàn)MQ產(chǎn)品
1.4 RabbitMQ 簡(jiǎn)介
AMQP，即 Advanced Message Queuing Protocol（高級(jí)消息隊(duì)列協(xié)議）洛勉，是一個(gè)網(wǎng)絡(luò)協(xié)議，是應(yīng)用層協(xié)議的一個(gè)開(kāi)放標(biāo)準(zhǔn)如迟，為面向消息的中間件設(shè)計(jì)收毫。基于此協(xié)議的客戶端與消息中間件可傳遞消息殷勘，并不受客戶端/中間件不同產(chǎn)品此再，不同的開(kāi)發(fā)語(yǔ)言等條件的限制。2006年玲销，AMQP 規(guī)范發(fā)布输拇。類(lèi)比HTTP。
RabbitMQ 基礎(chǔ)架構(gòu)如下圖：
? Broker：接收和分發(fā)消息的應(yīng)用贤斜，RabbitMQ Server就是 Message Broker
? Virtual host：出于多租戶和安全因素設(shè)計(jì)的策吠，把 AMQP 的基本組件劃分到一個(gè)虛擬的分組中，類(lèi)似于網(wǎng)
絡(luò)中的 namespace 概念瘩绒。當(dāng)多個(gè)不同的用戶使用同一個(gè) RabbitMQ server 提供的服務(wù)時(shí)猴抹，可以劃分出多
個(gè)vhost，每個(gè)用戶在自己的 vhost 創(chuàng)建 exchange／queue 等
? Connection：publisher／consumer 和 broker 之間的 TCP 連接
? Channel：如果每一次訪問(wèn) RabbitMQ 都建立一個(gè) Connection锁荔，在消息量大的時(shí)候建立 TCP Connection的開(kāi)銷(xiāo)將是巨大的蟀给，效率也較低。Channel 是在 connection 內(nèi)部建立的邏輯連接阳堕，如果應(yīng)用程序支持多線程跋理，通常每個(gè)thread創(chuàng)建單獨(dú)的 channel 進(jìn)行通訊，AMQP method 包含了channel id 幫助客戶端和message broker 識(shí)別 channel恬总，所以 channel 之間是完全隔離的前普。Channel 作為輕量級(jí)的 Connection極大減少了操作系統(tǒng)建立 TCP connection 的開(kāi)銷(xiāo)
? Exchange：message 到達(dá) broker 的第一站，根據(jù)分發(fā)規(guī)則越驻，匹配查詢表中的 routing key汁政，分發(fā)消息到queue 中去道偷。常用的類(lèi)型有：direct (point-to-point), topic (publish-subscribe) and fanout (multicast)
? Queue：消息最終被送到這里等待 consumer 取走
? Binding：exchange 和 queue 之間的虛擬連接，binding 中可以包含 routing key记劈。Binding 信息被保存
到 exchange 中的查詢表中勺鸦，用于 message 的分發(fā)依據(jù)
RabbitMQ 提供了 6 種工作模式：
簡(jiǎn)單模式、work queues目木、Publish/Subscribe 發(fā)布與訂閱模式换途、Routing路由模式、Topics 主題模式刽射、RPC 遠(yuǎn)程調(diào)用模式（遠(yuǎn)程調(diào)用军拟，不太算 MQ；暫不作介紹）誓禁。
1.5 JMS
? JMS 即 Java 消息服務(wù)（JavaMessage Service）應(yīng)用程序接口懈息，是一個(gè) Java 平臺(tái)中關(guān)于面向消息中間件的API
? JMS 是 JavaEE 規(guī)范中的一種，類(lèi)比JDBC
? 很多消息中間件都實(shí)現(xiàn)了JMS規(guī)范摹恰，例如：ActiveMQ辫继。RabbitMQ 官方?jīng)]有提供 JMS 的實(shí)現(xiàn)包，但是開(kāi)源社區(qū)有
二俗慈、RabbitMQ的安裝和配置
- 安裝依賴環(huán)境
- 安裝Erlang
- 安裝RabbitMQ
- 開(kāi)啟管理界面及配置
- 啟動(dòng)
- 配置虛擬主機(jī)及用戶
三姑宽、RabbitMQ 的工作模式
3.1 Work queues工作隊(duì)列模式
應(yīng)用場(chǎng)景：對(duì)于任務(wù)過(guò)重或任務(wù)較多情況使用工作隊(duì)列可以提高任務(wù)處理的速度。
3.2 Pub/Sub 訂閱模式
在訂閱模型中闺阱，多了一個(gè) Exchange 角色炮车，而且過(guò)程略有變化：
Exchange有常見(jiàn)以下3種類(lèi)型：
? Fanout：廣播，將消息交給所有綁定到交換機(jī)的隊(duì)列
? Direct：定向酣溃，把消息交給符合指定routing key 的隊(duì)列
? Topic：通配符瘦穆，把消息交給符合routing pattern（路由模式） 的隊(duì)列
Exchange（交換機(jī)）只負(fù)責(zé)轉(zhuǎn)發(fā)消息，不具備存儲(chǔ)消息的能力救拉，因此如果沒(méi)有任何隊(duì)列與Exchange 綁定难审，或者沒(méi)有符合路由規(guī)則的隊(duì)列，那么消息會(huì)丟失亿絮！
3.3 Routing 路由模式
? 隊(duì)列與交換機(jī)的綁定告喊，不能是任意綁定了，而是要指定一個(gè) RoutingKey（路由key）
? 消息的發(fā)送方在向 Exchange 發(fā)送消息時(shí)派昧，也必須指定消息的 RoutingKey
? Exchange 不再把消息交給每一個(gè)綁定的隊(duì)列黔姜，而是根據(jù)消息的 Routing Key 進(jìn)行判斷，只有隊(duì)列的Routingkey 與消息的 Routing key 完全一致蒂萎，才會(huì)接收到消息
3.4 Topics 通配符模式
? Topic 類(lèi)型與 Direct 相比秆吵，都是可以根據(jù) RoutingKey 把消息路由到不同的隊(duì)列。只不過(guò) Topic 類(lèi)型Exchange 可以讓隊(duì)列在綁定 Routing key 的時(shí)候使用通配符五慈！
? Routingkey 一般都是有一個(gè)或多個(gè)單詞組成纳寂，多個(gè)單詞之間以”.”分割主穗，例如： item.insert
? 通配符規(guī)則：# 匹配一個(gè)或多個(gè)詞，* 匹配不多不少恰好1個(gè)詞毙芜，例如：item.# 能夠匹配 item.insert.abc 或者 item.insert忽媒，item.* 只能匹配 item.insert
3.5 簡(jiǎn)單模式 HelloWorld
一個(gè)生產(chǎn)者、一個(gè)消費(fèi)者腋粥，不需要設(shè)置交換機(jī)（使用默認(rèn)的交換機(jī)）晦雨。
四、Spring整合RabbitMQ
五隘冲、RabbitMQ高級(jí)特性
5.1 消息的可靠投遞
RabbitMQ 為我們提供了兩種方式用來(lái)控制消息的投遞可靠性模式闹瞧。
? confirm 確認(rèn)模式
? return 退回模式
rabbitmq 整個(gè)消息投遞的路徑為：
producer--->rabbitmq broker--->exchange--->queue--->consumer
? 消息從 producer 到 exchange 則會(huì)返回一個(gè) confirmCallback 。
? 消息從 exchange-->queue 投遞失敗則會(huì)返回一個(gè) returnCallback 展辞。
我們將利用這兩個(gè) callback 控制消息的可靠性投遞
5.2 Consumer Ack
ack指Acknowledge澈圈，確認(rèn)金吗。 表示消費(fèi)端收到消息后的確認(rèn)方式敷存。
有三種確認(rèn)方式：
? 自動(dòng)確認(rèn)：acknowledge="none"
? 手動(dòng)確認(rèn)：acknowledge="manual"
? 根據(jù)異常情況確認(rèn)：acknowledge="auto"腔剂，（這種方式使用麻煩，不作講解）
其中自動(dòng)確認(rèn)是指靡砌，當(dāng)消息一旦被Consumer接收到，則自動(dòng)確認(rèn)收到珊楼，并將相應(yīng) message 從 RabbitMQ 的消息緩存中移除通殃。但是在實(shí)際業(yè)務(wù)處理中，很可能消息接收到厕宗，業(yè)務(wù)處理出現(xiàn)異常画舌，那么該消息就會(huì)丟失。如果設(shè)置了手動(dòng)確認(rèn)方式已慢，則需要在業(yè)務(wù)處理成功后曲聂，調(diào)用channel.basicAck()，手動(dòng)簽收佑惠，如果出現(xiàn)異常朋腋，則調(diào)用channel.basicNack()方法，讓其自動(dòng)重新發(fā)送消息膜楷。
5.3 消費(fèi)端限流
? 在<rabbit:listener-container> 中配置 prefetch屬性設(shè)置消費(fèi)端一次拉取多少消息
? 消費(fèi)端的確認(rèn)模式一定為手動(dòng)確認(rèn)旭咽。acknowledge="manual"
5.4 TTL
? TTL 全稱(chēng) Time To Live（存活時(shí)間/過(guò)期時(shí)間）。
? 當(dāng)消息到達(dá)存活時(shí)間后赌厅，還沒(méi)有被消費(fèi)穷绵，會(huì)被自動(dòng)清除。
? RabbitMQ可以對(duì)消息設(shè)置過(guò)期時(shí)間特愿，也可以對(duì)整個(gè)隊(duì)列（Queue）設(shè)置過(guò)期時(shí)間仲墨。
5.5 死信隊(duì)列
死信隊(duì)列勾缭，英文縮寫(xiě)：DLX 。Dead Letter Exchange（死信交換機(jī)）目养，當(dāng)消息成為Dead message后俩由，可以被重新發(fā)送到另一個(gè)交換機(jī)，這個(gè)交換機(jī)就是DLX混稽。
消息成為死信的三種情況：
- 隊(duì)列消息長(zhǎng)度到達(dá)限制采驻；
- 消費(fèi)者拒接消費(fèi)消息，basicNack/basicReject,并且不把消息重新放入原目標(biāo)隊(duì)列,requeue=false匈勋；
- 原隊(duì)列存在消息過(guò)期設(shè)置礼旅，消息到達(dá)超時(shí)時(shí)間未被消費(fèi)；
隊(duì)列綁定死信交換機(jī)：
給隊(duì)列設(shè)置參數(shù)： x-dead-letter-exchange 和 x-dead-letter-routing-key
5.6 延遲隊(duì)列
延遲隊(duì)列洽洁，即消息進(jìn)入隊(duì)列后不會(huì)立即被消費(fèi)痘系，只有到達(dá)指定時(shí)間后，才會(huì)被消費(fèi)饿自。
很可惜汰翠，在RabbitMQ中并未提供延遲隊(duì)列功能。
但是可以使用：TTL+死信隊(duì)列 組合實(shí)現(xiàn)延遲隊(duì)列的效果昭雌。
5.7 日志與監(jiān)控
RabbitMQ日志
RabbitMQ默認(rèn)日志存放路徑： /var/log/rabbitmq/rabbit@xxx.log
日志包含了RabbitMQ的版本號(hào)复唤、Erlang的版本號(hào)、RabbitMQ服務(wù)節(jié)點(diǎn)名稱(chēng)烛卧、cookie的hash值佛纫、RabbitMQ配置文件地址、內(nèi)存限制总放、磁盤(pán)限制呈宇、默認(rèn)賬戶guest的創(chuàng)建以及權(quán)限配置等等。web管控臺(tái)監(jiān)控
-
rabbitmqctl管理和監(jiān)控
image.png
5.8 消息追蹤
在使用任何消息中間件的過(guò)程中局雄，難免會(huì)出現(xiàn)某條消息異常丟失的情況甥啄，這個(gè)時(shí)候就需要有一個(gè)較好的機(jī)制跟蹤記錄消息的投遞過(guò)程，以此協(xié)助開(kāi)發(fā)和運(yùn)維人員進(jìn)行問(wèn)題的定位炬搭。
在RabbitMQ中可以使用Firehose和rabbitmq_tracing插件功能來(lái)實(shí)現(xiàn)消息追蹤蜈漓。
- forehose
firehose的機(jī)制是將生產(chǎn)者投遞給rabbitmq的消息，rabbitmq投遞給消費(fèi)者的消息按照指定的格式發(fā)送到默認(rèn)的exchange上尚蝌。這個(gè)默認(rèn)的exchange的名稱(chēng)為amq.rabbitmq.trace迎变，它是一個(gè)topic類(lèi)型的exchange。發(fā)送到這個(gè)exchange上的消息的routing key為 publish.exchangename 和deliver.queuename飘言。其中exchangename和queuename為實(shí)際exchange和queue的名稱(chēng)衣形，分別對(duì)應(yīng)生產(chǎn)者投遞到exchange的消息，和消費(fèi)者從queue上獲取的消息。
rabbitmqctl trace_on：開(kāi)啟Firehose命令
rabbitmqctl trace_off：關(guān)閉Firehose命令 - rabbitmq_tracing
rabbitmq_tracing和Firehose在實(shí)現(xiàn)上如出一轍谆吴，只不過(guò)rabbitmq_tracing的方式比Firehose多了一
層GUI的包裝倒源，更容易使用和管理。
啟用插件：rabbitmq-plugins enable rabbitmq_tracing
六句狼、應(yīng)用問(wèn)題
6.1 消息可靠性保障
6.2消息冪等性保障
冪等性指一次和多次請(qǐng)求某一個(gè)資源笋熬，對(duì)于資源本身應(yīng)該具有同樣的結(jié)果。也就是說(shuō)腻菇，其任意多次執(zhí)行對(duì)資源本身所產(chǎn)生的影響均與一次執(zhí)行的影響相同胳螟。
在MQ中指，消費(fèi)多條相同的消息筹吐，得到與消費(fèi)該消息一次相同的結(jié)果糖耸。
七、RabbitMQ集群搭建
實(shí)際生產(chǎn)應(yīng)用中都會(huì)采用消息隊(duì)列的集群方案丘薛，如果選擇RabbitMQ那么有必要了解下它的集群方案原理
7.1集群方案的原理
RabbitMQ這款消息隊(duì)列中間件產(chǎn)品本身是基于Erlang編寫(xiě)嘉竟，Erlang語(yǔ)言天生具備分布式特性（通過(guò)同步Erlang集群各節(jié)點(diǎn)的magic cookie來(lái)實(shí)現(xiàn)）。因此洋侨，RabbitMQ天然支持Clustering舍扰。這使得RabbitMQ本身不需要像ActiveMQ、Kafka那樣通過(guò)ZooKeeper分別來(lái)實(shí)現(xiàn)HA方案和保存集群的元數(shù)據(jù)希坚。集群是保證可靠性的一種方式边苹，同時(shí)可以通過(guò)水平擴(kuò)展以達(dá)到增加消息吞吐量能力的目的。
7.2 集群管理
rabbitmqctl join_cluster {cluster_node} [–ram]
將節(jié)點(diǎn)加入指定集群中裁僧。在這個(gè)命令執(zhí)行前需要停止RabbitMQ應(yīng)用并重置節(jié)點(diǎn)勾给。
rabbitmqctl cluster_status
顯示集群的狀態(tài)。
rabbitmqctl change_cluster_node_type {disc|ram}
修改集群節(jié)點(diǎn)的類(lèi)型锅知。在這個(gè)命令執(zhí)行前需要停止RabbitMQ應(yīng)用。
rabbitmqctl forget_cluster_node [–offline]
將節(jié)點(diǎn)從集群中刪除脓钾，允許離線執(zhí)行售睹。
rabbitmqctl update_cluster_nodes {clusternode}
在集群中的節(jié)點(diǎn)應(yīng)用啟動(dòng)前咨詢clusternode節(jié)點(diǎn)的最新信息，并更新相應(yīng)的集群信息可训。這個(gè)和join_cluster不同昌妹，它不加入集群∥战兀考慮這樣一種情況飞崖，節(jié)點(diǎn)A和節(jié)點(diǎn)B都在集群中，當(dāng)節(jié)點(diǎn)A離線了谨胞，節(jié)點(diǎn)C又和節(jié)點(diǎn)B組成了一個(gè)集群固歪，然后節(jié)點(diǎn)B又離開(kāi)了集群，當(dāng)A醒來(lái)的時(shí)候，它會(huì)嘗試聯(lián)系節(jié)點(diǎn)B牢裳，但是這樣會(huì)失敗逢防，因?yàn)楣?jié)點(diǎn)B已經(jīng)不在集群中了。
rabbitmqctl cancel_sync_queue [-p vhost] {queue}
取消隊(duì)列queue同步鏡像的操作蒲讯。
rabbitmqctl set_cluster_name {name}
設(shè)置集群名稱(chēng)忘朝。集群名稱(chēng)在客戶端連接時(shí)會(huì)通報(bào)給客戶端。Federation和Shovel插件也會(huì)有用到集群名稱(chēng)的地方判帮。集群名稱(chēng)默認(rèn)是集群中第一個(gè)節(jié)點(diǎn)的名稱(chēng)局嘁，通過(guò)這個(gè)命令可以重新設(shè)置。
3.4 RabbitMQ鏡像集群配置
保證隊(duì)列的高可用性
設(shè)置的鏡像隊(duì)列可以通過(guò)開(kāi)啟的網(wǎng)頁(yè)的管理端Admin->Policies晦墙，也可以通過(guò)命令悦昵。
3.5 負(fù)載均衡-HAProxy
HAProxy提供高可用性、負(fù)載均衡以及基于TCP和HTTP應(yīng)用的代理偎痛，支持虛擬主機(jī)旱捧，它是免費(fèi)、快速并且可靠的一種解決方案,包括Twitter踩麦，Reddit枚赡，StackOverflow，GitHub在內(nèi)的多家知名互聯(lián)網(wǎng)公司在使用谓谦。HAProxy實(shí)現(xiàn)了一種事件驅(qū)動(dòng)贫橙、單一進(jìn)程模型，此模型支持非常大的并發(fā)連接數(shù)反粥。
