一,、什么是中間件

我國企業(yè)從20世紀(jì)80年代開始就逐漸進(jìn)行信息化建設(shè),，由于方法和體系的不成熟，以及企業(yè)業(yè)務(wù)和市場需求的不斷變化，一個(gè)企業(yè)可能同時(shí)運(yùn)行著多個(gè)不同的業(yè)務(wù)系統(tǒng),，這些系統(tǒng)可能基于不同的操作系統(tǒng)、不同的數(shù)據(jù)庫,、異構(gòu)的網(wǎng)絡(luò)環(huán)境?，F(xiàn)在的問題是，如何把這些信息系統(tǒng)結(jié)合成一個(gè)有機(jī)地協(xié)同工作的整體,，真正實(shí)現(xiàn)企業(yè)跨平臺,、分布式應(yīng)用。中間件便是解決之道,，它用自己的復(fù)雜換取了企業(yè)應(yīng)用的簡單,。

舉例：
1,，RMI（Remote Method Invocations, 遠(yuǎn)程調(diào)用）
2，Load Balancing(負(fù)載均衡,，將訪問負(fù)荷分散到各個(gè)服務(wù)器中)
3,，Transparent Fail-over(透明的故障切換)
4，Clustering(集群,用多個(gè)小的服務(wù)器代替大型機(jī)）
5,，Back-end-Integration(后端集成,，用現(xiàn)有的、新開發(fā)的系統(tǒng)如何去集成遺留的系統(tǒng))
6,，Transaction事務(wù)（全局/局部）全局事務(wù)（分布式事務(wù)）局部事務(wù)（在同一數(shù)據(jù)庫聯(lián)接內(nèi)的事務(wù)）
7,，Dynamic Redeployment(動態(tài)重新部署,在不停止原系統(tǒng)的情況下，部署新的系統(tǒng)）
8,，System Management(系統(tǒng)管理)
9,，Threading(多線程處理)
10，Message-oriented Middleware面向消息的中間件（異步的調(diào)用編程）
11,，Component Life Cycle(組件的生命周期管理)
12,，Resource pooling（資源池）
13，Security（安全）
14,，Caching（緩存）

1.1 為什么需要使用消息中間件

具體地說,，中間件屏蔽了底層操作系統(tǒng)的復(fù)雜性，使程序開發(fā)人員面對一個(gè)簡單而統(tǒng)一的開發(fā)環(huán)境,，減少程序設(shè)計(jì)的復(fù)雜性,，將注意力集中在自己的業(yè)務(wù)上，不必再為程序在不同系統(tǒng)軟件上的移植而重復(fù)工作,，從而大大減少了技術(shù)上的負(fù)擔(dān),。中間件帶給應(yīng)用系統(tǒng)的，不只是開發(fā)的簡便,、開發(fā)周期的縮短,，也減少了系統(tǒng)的維護(hù)、運(yùn)行和管理的工作量,，還減少了計(jì)算機(jī)總體費(fèi)用的投入,。

1.2中間件特點(diǎn)

為解決分布異構(gòu)問題，人們提出了中間件(middleware)的概念,。中間件是位于平臺(硬件和操作系統(tǒng))和應(yīng)用之間的通用服務(wù),，如下圖所示，這些服務(wù)具有標(biāo)準(zhǔn)的程序接口和協(xié)議,。針對不同的操作系統(tǒng)和硬件平臺,，它們可以有符合接口和協(xié)議規(guī)范的多種實(shí)現(xiàn)。

也許很難給中間件一個(gè)嚴(yán)格的定義,，但中間件應(yīng)具有如下的一些特點(diǎn)：
（1）滿足大量應(yīng)用的需要
（2）運(yùn)行于多種硬件和OS平臺
（3）支持分布計(jì)算,，提供跨網(wǎng)絡(luò),、硬件和OS平臺的透明性的應(yīng)用或服務(wù)的交互
（4）支持標(biāo)準(zhǔn)的協(xié)議
（5）支持標(biāo)準(zhǔn)的接口

由于標(biāo)準(zhǔn)接口對于可移植性和標(biāo)準(zhǔn)協(xié)議對于互操作性的重要性，中間件已成為許多標(biāo)準(zhǔn)化工作的主要部分,。對于應(yīng)用軟件開發(fā),，中間件遠(yuǎn)比操作系統(tǒng)和網(wǎng)絡(luò)服務(wù)更為重要，中間件提供的程序接口定義了一個(gè)相對穩(wěn)定的高層應(yīng)用環(huán)境,，不管底層的計(jì)算機(jī)硬件和系統(tǒng)軟件怎樣更新?lián)Q代,，只要將中間件升級更新，并保持中間件對外的接口定義不變,，應(yīng)用軟件幾乎不需任何修改,，從而保護(hù)了企業(yè)在應(yīng)用軟件開發(fā)和維護(hù)中的重大投資。

簡單說：中間件有個(gè)很大的特點(diǎn),，是脫離于具體設(shè)計(jì)目標(biāo),，而具備提供普遍獨(dú)立功能需求的模塊。這使得中間件一定是可替換的,。如果一個(gè)系統(tǒng)設(shè)計(jì)中,，中間件是不可替換的，不是架構(gòu),、框架設(shè)計(jì)有問題,，那么就是這個(gè)中間件，在 別處可能是個(gè)中間件,，在這個(gè)系統(tǒng)內(nèi)是引擎,。哈。

1.3 在項(xiàng)目中什么時(shí)候使用中間件技術(shù)

在項(xiàng)目的架構(gòu)和重構(gòu)中,，使用任何技術(shù)和架構(gòu)的改變我們都需要謹(jǐn)慎斟酌和思考,，因?yàn)槿魏渭夹g(shù)的融入和變化都可能人員，技術(shù),，和成本的增加,，中間件的技術(shù)一般現(xiàn)在一些互聯(lián)網(wǎng)公司或者項(xiàng)目中使用比較多，如果你僅僅還只是一個(gè)初創(chuàng)公司建議還是使用單體架構(gòu),，最多加個(gè)緩存中間件即可，不要盲目追求新或者所謂的高性能,，而追求的背后一定是業(yè)務(wù)的驅(qū)動和項(xiàng)目的驅(qū)動,，因?yàn)橐坏┳非缶鸵馕吨愕膶W(xué)習(xí)成本，公司的人員結(jié)構(gòu)以及服務(wù)器成本,，維護(hù)和運(yùn)維的成本都會增加,，所以需要謹(jǐn)慎選擇和考慮。

但是作為一個(gè)開放人員,，一定要有學(xué)習(xí)中間件技術(shù)的能力和思維,，否則很容易當(dāng)項(xiàng)目發(fā)展到一個(gè)階段在去掌握估計(jì)或者在面試中提及,，就會給自己帶來不小的困擾，在當(dāng)今這個(gè)時(shí)代這些技術(shù)也并不是什么新鮮的東西,，如果去掌握和挖掘最關(guān)鍵的還是自己花時(shí)間和花精力去探討和研究,。

1.4 課程的規(guī)劃和安排

消息中間件 ActiveMQ

消息中間件 RabbitMQ

消息中間件 Kafaka

消息中間件 RocketMQ

消息中間件應(yīng)用場景說明

負(fù)載均衡中間件(Nginx/Lvs)

緩存中間件(Memcache/Redis)

數(shù)據(jù)庫中間件(ShardingJdbc/Mycat)

二、中間件技術(shù)及架構(gòu)的概述

知識圖譜

2.1 學(xué)習(xí)中間件的方式和技巧

1：理解中間件在項(xiàng)目架構(gòu)中的作用,，以及各中間件的底層實(shí)現(xiàn),。
2：可以使用一些類比的生活概念去理解中間件，
3：使用一些流程圖或者腦圖的方式去梳理各個(gè)中間件在架構(gòu)中的作用
4：嘗試用java技術(shù)去實(shí)現(xiàn)中間件的遠(yuǎn)離
5：靜下來去思考中間件在項(xiàng)目中設(shè)計(jì)的和使用的原因
6：如果找到對應(yīng)的替代總結(jié)方案
7：嘗試編寫博文總結(jié)類同中間件技術(shù)的對比和使用場景,。
8：學(xué)會查看中間件的源碼以及開開源項(xiàng)目和博文,。

2.2 學(xué)習(xí)目標(biāo)

什么是消息中間件
什么是協(xié)議
什么是持久化
消息分發(fā)
消息的高可用
消息的集群
消息的容錯(cuò)
消息的冗余

2.3 單體架構(gòu)

在實(shí)際的項(xiàng)目中，大部分的企業(yè)項(xiàng)目開發(fā)中,，在早期都采用的是單體的架構(gòu)模式,，如下圖：

在企業(yè)開發(fā)的中，大部分的初期架構(gòu)都采用的是單體架構(gòu)的模式進(jìn)行架構(gòu),，而這種架構(gòu)的典型的特點(diǎn)：就是把所有的業(yè)務(wù)和模塊,，源代碼，靜態(tài)資源文件等都放在一個(gè)一工程中,，如果其中的一個(gè)模塊升級或者迭代發(fā)生一個(gè)很小變動都會重新編譯和重新部署項(xiàng)目,。 這種的架構(gòu)存在的問題就是：
1：耦合度太高
2：運(yùn)維的成本過高
3：不易維護(hù)
4：服務(wù)器的成本高
5：以及升級架構(gòu)的復(fù)雜度也會增大

這樣就有后續(xù)的分布式架構(gòu)系統(tǒng)。

2.4 分布式架構(gòu)

何謂分布式系統(tǒng)呢：

通俗一點(diǎn)：就是一個(gè)請求由服務(wù)器端的多個(gè)服務(wù)（服務(wù)或者系統(tǒng)）協(xié)同處理完成和單體架構(gòu)不同的是,，單體架構(gòu)是一個(gè)請求發(fā)起jvm調(diào)度線程（確切的是tomcat線程池）分配線程Thread來處理請求直到釋放,，而分布式是系統(tǒng)是：一個(gè)請求是由多個(gè)系統(tǒng)共同來協(xié)同完成，jvm和環(huán)境都可能是獨(dú)立,。如果生活中的比喻的話,，單體架構(gòu)就想建設(shè)一個(gè)小房子很快就能夠搞定，如果你要建設(shè)一個(gè)鳥巢或者大型的建筑,，你就必須是各個(gè)環(huán)節(jié)的協(xié)同和分布,，這樣目的也是項(xiàng)目發(fā)展都后期的時(shí)候要去部署和思考的問題。我們也不能看出來：分布式架構(gòu)系統(tǒng)存在的特點(diǎn)和問題如下：

存在問題
1：學(xué)習(xí)成本高,，技術(shù)棧過多
2：運(yùn)維成本和服務(wù)器成本增高
3：人員的成本也會增高
4：項(xiàng)目的負(fù)載度也會上升
5：面臨的錯(cuò)誤和容錯(cuò)性也會成倍增加
6：占用的服務(wù)器端口和通訊的選擇的成本高
7：安全性的考慮和因素逼迫可能選擇RMI/MQ相關(guān)的服務(wù)器端通訊,。

好處
1：服務(wù)系統(tǒng)的獨(dú)立，占用的服務(wù)器資源減少和占用的硬件成本減少,，
確切的說是：可以合理的分配服務(wù)資源,，不造成服務(wù)器資源的浪費(fèi)
2：系統(tǒng)的獨(dú)立維護(hù)和部署，耦合度降低,，可插拔性,。
3：系統(tǒng)的架構(gòu)和技術(shù)棧的選擇可以變的靈活（而不是單純的選擇java）
4：彈性的部署，不會造成平臺因部署造成的癱瘓和停服的狀態(tài),。

三,、基于消息中間件的分布式系統(tǒng)的架構(gòu)

3.1 基于消息中間件的分布式系統(tǒng)的架構(gòu)

從上圖中可以看出來,，消息中間件的是
1：利用可靠的消息傳遞機(jī)制進(jìn)行系統(tǒng)和系統(tǒng)直接的通訊
2：通過提供消息傳遞和消息的排隊(duì)機(jī)制，它可以在分布式系統(tǒng)環(huán)境下擴(kuò)展進(jìn)程間的通訊,。

3.4 消息中間件應(yīng)用的場景

1:跨系統(tǒng)數(shù)據(jù)傳遞
2:高并發(fā)的流量削峰
3:數(shù)據(jù)的分發(fā)和異步處理
4:大數(shù)據(jù)分析與傳遞
5:分布式事務(wù)
比如你有一個(gè)數(shù)據(jù)要進(jìn)行遷移或者請求并發(fā)過多的時(shí)候,，比如你有10W的并發(fā)請求下訂單，我們可以在這些訂單入庫之前,，我們可以把訂單請求堆積到消息隊(duì)列中,，讓它穩(wěn)健可靠的入庫和執(zhí)行。

3.5 常見的消息中間件

ActiveMQ,、RabbitMQ,、Kafka、RocketMQ等,。

3.6 消息中間件的本質(zhì)及設(shè)計(jì)

它是一種接受數(shù)據(jù),，接受請求、存儲數(shù)據(jù),、發(fā)送數(shù)據(jù)等功能的技術(shù)服務(wù),。

MQ消息隊(duì)列：負(fù)責(zé)數(shù)據(jù)的傳接受，存儲和傳遞,，所以性能要過于普通服務(wù)和技術(shù),。

誰來生產(chǎn)消息，存儲消息和消費(fèi)消息呢,？

3.7 消息中間件的核心組成部分

1：消息的協(xié)議
2：消息的持久化機(jī)制
3：消息的分發(fā)策略
4：消息的高可用,，高可靠
5：消息的容錯(cuò)機(jī)制

3.8 小結(jié)

其實(shí)不論選擇單體架構(gòu)還是分布式架構(gòu)都是項(xiàng)目開發(fā)的一個(gè)階段，在什么階段選擇適合的架構(gòu)方式,，而不能盲目追求,，最后造成的后果和問題都需要自己買單。但是作為一個(gè)開發(fā)人員學(xué)習(xí)和探討新的技術(shù)是我們每個(gè)程序開發(fā)者都應(yīng)該去保持和思考的問題,。當(dāng)我們沒辦法去改變社會和世界的時(shí)候,，我們?yōu)榱松詈蜕婺蔷捅仨氁掀髽I(yè)和市場的需求，發(fā)揮你的價(jià)值和所學(xué)的才能,，創(chuàng)造價(jià)值和實(shí)現(xiàn)自我,。

四、消息隊(duì)列協(xié)議

4.1 什么是協(xié)議

我們知道消息中間件負(fù)責(zé)數(shù)據(jù)的傳遞,，存儲,，和分發(fā)消費(fèi)三個(gè)部分，數(shù)據(jù)的存儲和分發(fā)的過程中肯定要遵循某種約定成俗的規(guī)范,，你是采用底層的TCP/IP，UDP協(xié)議還是其他的自己取構(gòu)建等,，而這些約定成俗的規(guī)范就稱之為：協(xié)議,。

所謂協(xié)議是指：
1：計(jì)算機(jī)底層操作系統(tǒng)和應(yīng)用程序通訊時(shí)共同遵守的一組約定,，只有遵循共同的約定和規(guī)范，系統(tǒng)和底層操作系統(tǒng)之間才能相互交流,。
2：和一般的網(wǎng)絡(luò)應(yīng)用程序的不同它主要負(fù)責(zé)數(shù)據(jù)的接受和傳遞,，所以性能比較的高。
3：協(xié)議對數(shù)據(jù)格式和計(jì)算機(jī)之間交換數(shù)據(jù)都必須嚴(yán)格遵守規(guī)范,。

4.2 網(wǎng)絡(luò)協(xié)議的三要素

1.語法,。語法是用戶數(shù)據(jù)與控制信息的結(jié)構(gòu)與格式,以及數(shù)據(jù)出現(xiàn)的順序。
2.語義,。語義是解釋控制信息每個(gè)部分的意義,。它規(guī)定了需要發(fā)出何種控制信息,以及完成的動作與做出什么樣的響應(yīng)。
3.時(shí)序,。時(shí)序是對事件發(fā)生順序的詳細(xì)說明,。

比如我MQ發(fā)送一個(gè)信息，是以什么數(shù)據(jù)格式發(fā)送到隊(duì)列中,，然后每個(gè)部分的含義是什么,，發(fā)送完畢以后的執(zhí)行的動作，以及消費(fèi)者消費(fèi)消息的動作,，消費(fèi)完畢的響應(yīng)結(jié)果和反饋是什么,，然后按照對應(yīng)的執(zhí)行順序進(jìn)行處理。如果你還是不理解：大家每天都在接觸的http請求協(xié)議:

1：語法：http規(guī)定了請求報(bào)文和響應(yīng)報(bào)文的格式,。
2：語義：客戶端主動發(fā)起請求稱之為請求,。（這是一種定義，同時(shí)你發(fā)起的是post/get請求）
3：時(shí)序：一個(gè)請求對應(yīng)一個(gè)響應(yīng),。（一定先有請求在有響應(yīng),，這個(gè)是時(shí)序）

而消息中間件采用的并不是http協(xié)議，而常見的消息中間件協(xié)議有：OpenWire,、AMQP,、MQTT、Kafka,，OpenMessage協(xié)議,。

面試題：為什么消息中間件不直接使用http協(xié)議呢？
1: 因?yàn)閔ttp請求報(bào)文頭和響應(yīng)報(bào)文頭是比較復(fù)雜的,，包含了cookie,，數(shù)據(jù)的加密解密，狀態(tài)碼,，響應(yīng)碼等附加的功能,，但是對于一個(gè)消息而言，我們并不需要這么復(fù)雜，也沒有這個(gè)必要性,，它其實(shí)就是負(fù)責(zé)數(shù)據(jù)傳遞,，存儲，分發(fā)就行,，一定要追求的是高性能,。盡量簡潔，快速,。
2:大部分情況下http大部分都是短鏈接,，在實(shí)際的交互過程中，一個(gè)請求到響應(yīng)很有可能會中斷,，中斷以后就不會就行持久化,，就會造成請求的丟失。這樣就不利于消息中間件的業(yè)務(wù)場景,，因?yàn)橄⒅虚g件可能是一個(gè)長期的獲取消息的過程,，出現(xiàn)問題和故障要對數(shù)據(jù)或消息就行持久化等，目的是為了保證消息和數(shù)據(jù)的高可靠和穩(wěn)健的運(yùn)行,。

4.3 AMQP協(xié)議

AMQP：(全稱：Advanced Message Queuing Protocol) 是高級消息隊(duì)列協(xié)議,。由摩根大通集團(tuán)聯(lián)合其他公司共同設(shè)計(jì)。是一個(gè)提供統(tǒng)一消息服務(wù)的應(yīng)用層標(biāo)準(zhǔn)高級消息隊(duì)列協(xié)議,，是應(yīng)用層協(xié)議的一個(gè)開放標(biāo)準(zhǔn),，為面向消息的中間件設(shè)計(jì)?；诖藚f(xié)議的客戶端與消息中間件可傳遞消息,，并不受客戶端/中間件不同產(chǎn)品，不同的開發(fā)語言等條件的限制,。Erlang中的實(shí)現(xiàn)有RabbitMQ等,。
特性：
1：分布式事務(wù)支持。
2：消息的持久化支持,。
3：高性能和高可靠的消息處理優(yōu)勢,。

AMQP協(xié)議的支持者：

4.4 MQTT協(xié)議

MQTT協(xié)議：（Message Queueing Telemetry Transport）消息隊(duì)列是IBM開放的一個(gè)即時(shí)通訊協(xié)議，物聯(lián)網(wǎng)系統(tǒng)架構(gòu)中的重要組成部分,。
特點(diǎn)：
1：輕量
2：結(jié)構(gòu)簡單
3：傳輸快,，不支持事務(wù)
4：沒有持久化設(shè)計(jì)。
應(yīng)用場景：
1：適用于計(jì)算能力有限
2：低帶寬
3：網(wǎng)絡(luò)不穩(wěn)定的場景,。
支持者：

4.5 OpenMessage協(xié)議

是近幾年由阿里,、雅虎和滴滴出行、Stremalio等公司共同參與創(chuàng)立的分布式消息中間件,、流處理等領(lǐng)域的應(yīng)用開發(fā)標(biāo)準(zhǔn),。
特點(diǎn)：
1：結(jié)構(gòu)簡單
2：解析速度快
3：支持事務(wù)和持久化設(shè)計(jì),。

4.6 Kafka協(xié)議

Kafka協(xié)議是基于TCP/IP的二進(jìn)制協(xié)議。消息內(nèi)部是通過長度來分割,，由一些基本數(shù)據(jù)類型組成,。
特點(diǎn)是：
1：結(jié)構(gòu)簡單
2：解析速度快
3：無事務(wù)支持（Kafka 從 0.11 版本開始支持了事務(wù)機(jī)制）
4：有持久化設(shè)計(jì)

五、消息隊(duì)列持久化

5.1 持久化

簡單來說就是將數(shù)據(jù)存入磁盤,，而不是存在內(nèi)存中隨服務(wù)器重啟斷開而消失，使數(shù)據(jù)能夠永久保存,。

5.2 常見的持久化方式

六,、消息的分發(fā)策略

6.1 消息的分發(fā)策略

MQ消息隊(duì)列有如下幾個(gè)角色
1：生產(chǎn)者
2：存儲消息
3：消費(fèi)者
那么生產(chǎn)者生成消息以后，MQ進(jìn)行存儲,，消費(fèi)者是如何獲取消息的呢,？一般獲取數(shù)據(jù)的方式無外乎推（push）或者拉（pull）兩種方式，典型的git就有推拉機(jī)制,，我們發(fā)送的http請求就是一種典型的拉取數(shù)據(jù)庫數(shù)據(jù)返回的過程,。而消息隊(duì)列MQ是一種推送的過程，而這些推機(jī)制會適用到很多的業(yè)務(wù)場景也有很多對應(yīng)推機(jī)制策略,。

6.2 場景分析一

比如我在APP上下了一個(gè)訂單,，我們的系統(tǒng)和服務(wù)很多，我們?nèi)绾蔚弥@個(gè)消息被那個(gè)系統(tǒng)或者那些服務(wù)或者系統(tǒng)進(jìn)行消費(fèi),，那這個(gè)時(shí)候就需要一個(gè)分發(fā)的策略,。這就需要消費(fèi)策略?；蛘叻Q之為消費(fèi)的方法論,。

6.3 場景分析二

在發(fā)送消息的過程中可能會出現(xiàn)異常，或者網(wǎng)絡(luò)的抖動,，故障等等因?yàn)樵斐上⒌臒o法消費(fèi),，比如用戶在下訂單，消費(fèi)MQ接受,，訂單系統(tǒng)出現(xiàn)故障,，導(dǎo)致用戶支付失敗，那么這個(gè)時(shí)候就需要消息中間件就必須支持消息重試機(jī)制策略,。也就是支持：出現(xiàn)問題和故障的情況下,，消息不丟失還可以進(jìn)行重發(fā)。

6.4 消息分發(fā)策略的機(jī)制和對比

七,、消息隊(duì)列高可用和高可靠

7.1 什么是高可用機(jī)制

所謂高可用：是指產(chǎn)品在規(guī)定的條件和規(guī)定的時(shí)刻或時(shí)間內(nèi)處于可執(zhí)行規(guī)定功能狀態(tài)的能力,。
當(dāng)業(yè)務(wù)量增加時(shí)，請求也過大,，一臺消息中間件服務(wù)器的會觸及硬件（CPU,內(nèi)存,，磁盤）的極限,，一臺消息服務(wù)器你已經(jīng)無法滿足業(yè)務(wù)的需求，所以消息中間件必須支持集群部署,。來達(dá)到高可用的目的,。

7.2 集群模式1 - Master-slave主從共享數(shù)據(jù)的部署方式

解說：生產(chǎn)者講消費(fèi)發(fā)送到Master節(jié)點(diǎn)，所有的都連接這個(gè)消息隊(duì)列共享這塊數(shù)據(jù)區(qū)域,，Master節(jié)點(diǎn)負(fù)責(zé)寫入,，一旦Master掛掉，slave節(jié)點(diǎn)繼續(xù)服務(wù),。從而形成高可用,，

7.3 集群模式2 - Master- slave主從同步部署方式

解釋：這種模式寫入消息同樣在Master主節(jié)點(diǎn)上，但是主節(jié)點(diǎn)會同步數(shù)據(jù)到slave節(jié)點(diǎn)形成副本,，和zookeeper或者redis主從機(jī)制很類同,。這樣可以達(dá)到負(fù)載均衡的效果，如果消費(fèi)者有多個(gè)這樣就可以去不同的節(jié)點(diǎn)就行消費(fèi),，以為消息的拷貝和同步會暫用很大的帶寬和網(wǎng)絡(luò)資源,。在后續(xù)的rabbtmq中會有使用。

7.4 集群模式3 - 多主集群同步部署模式

解釋：和上面的區(qū)別不是特別的大,，但是它的寫入可以往任意節(jié)點(diǎn)去寫入,。

7.5 集群模式4 - 多主集群轉(zhuǎn)發(fā)部署模式

解釋：如果你插入的數(shù)據(jù)是broker-1中，元數(shù)據(jù)信息會存儲數(shù)據(jù)的相關(guān)描述和記錄存放的位置（隊(duì)列）,。
它會對描述信息也就是元數(shù)據(jù)信息就行同步,，如果消費(fèi)者在broker-2中進(jìn)行消費(fèi)，發(fā)現(xiàn)自己幾點(diǎn)沒有對應(yīng)的消息,，可以從對應(yīng)的元數(shù)據(jù)信息中去查詢,，然后返回對應(yīng)的消息信息，場景：比如買火車票或者黃牛買演唱會門票,，比如第一個(gè)黃牛有顧客說要買的演唱會門票,，但是沒有但是他會去聯(lián)系其他的黃牛詢問，如果有就返回,。

7.6 集群模式5 Master-slave與Breoker-cluster組合的方案

解釋：實(shí)現(xiàn)多主多從的熱備機(jī)制來完成消息的高可用以及數(shù)據(jù)的熱備機(jī)制,，在生產(chǎn)規(guī)模達(dá)到一定的階段的時(shí)候，這種使用的頻率比較高,。

這么集群模式,，具體在后續(xù)的課程中會進(jìn)行一個(gè)分析和講解。他們的最終目的都是為保證：消息服務(wù)器不會掛掉,，出現(xiàn)了故障依然可以抱著消息服務(wù)繼續(xù)使用,。

反正終歸三句話：
1：要么消息共享，
2：要么消息同步
3：要么元數(shù)據(jù)共享

7.7 什么是高可靠機(jī)制

所謂高可用是指：是指系統(tǒng)可以無故障低持續(xù)運(yùn)行,，比如一個(gè)系統(tǒng)突然崩潰,，報(bào)錯(cuò),，異常等等并不影響線上業(yè)務(wù)的正常運(yùn)行，出錯(cuò)的幾率極低,，就稱之為：高可靠,。
在高并發(fā)的業(yè)務(wù)場景中，如果不能保證系統(tǒng)的高可靠,，那造成的隱患和損失是非常嚴(yán)重的,。
如何保證中間件消息的可靠性呢？可以從兩個(gè)方面考慮：
1：消息的傳輸：通過協(xié)議來保證系統(tǒng)間數(shù)據(jù)解析的正確性,。
2：消息的存儲可靠：通過持久化來保證消息的可靠性,。