1.為什么要使用消息隊列？

1.通過異步處理提高系統(tǒng)性能；削峰、減少響應(yīng)所需時間

如果不使用消息隊列時，用戶請求的大量數(shù)據(jù)直接寫入到數(shù)據(jù)庫中，在高并發(fā)的情況下，寫入能力驟降，響應(yīng)變慢；使用消息隊列后，用戶請求后可以立即加入到隊列，然后返回給用戶，數(shù)據(jù)庫通過消息隊列消費消息，因此響應(yīng)速度能得到大幅改善。

消息隊列具有很好的削峰作用的功能——即通過異步處理，將短時間高并發(fā)產(chǎn)生的事務(wù)消息存儲在消息隊列中，從而削平高峰期的并發(fā)事務(wù)。

用戶請求數(shù)據(jù)后，由于異步操作，比如消費消息后與數(shù)據(jù)庫的操作可能出現(xiàn)失敗的情況，這種情況我們就不能直接提示用戶操作成功，需要通過后置處理來提醒用戶成功或失敗。

2..降低系統(tǒng)耦合性

模塊之間不存在直接調(diào)用，可擴展性更好。消費隊列是利用發(fā)布-訂閱模式工作，生產(chǎn)者發(fā)布消息，一個或多個消費者消費消息，新增業(yè)務(wù)只需要訂閱消息從而實現(xiàn)網(wǎng)站業(yè)務(wù)的可擴展性設(shè)計。

2.使用消息隊列帶來的一些問題

系統(tǒng)可用性降低：加入MQ之后，需要考慮消息丟失或者說MQ掛掉等等的情況

系統(tǒng)復(fù)雜性提高：需要保證消息不被重復(fù)消費，處理消息丟失的情況、保證消息傳遞的順序性等等問題

一致性問題：我上面講了消息隊列可以實現(xiàn)異步，消息隊列帶來的異步確實可以提高系統(tǒng)響應(yīng)速度。但是，萬一消息的真正消費者并沒有正確消費消息怎么辦?這樣就會導(dǎo)致數(shù)據(jù)不一致的情況了!

3.JMS

JMS(JAVA Message Service,Java消息服務(wù))API是一個消息服務(wù)的標(biāo)準(zhǔn)或者說是規(guī)范。ActiveMQ 就是基于 JMS 規(guī)范實現(xiàn)的。

JMS兩種消息模型：1.點對點；2.發(fā)布/訂閱

JMS 五種不同的消息正文格式：

StreamMessage -- Java原始值的數(shù)據(jù)流

MapMessage--一套名稱-值對

TextMessage--一個字符串對象

ObjectMessage--一個序列化的 Java對象

BytesMessage--一個字節(jié)的數(shù)據(jù)流

3.AMQP

AMQP，即Advanced Message Queuing Protocol,一個提供統(tǒng)一消息服務(wù)的應(yīng)用層標(biāo)準(zhǔn) 高級消息隊列協(xié)議(二進制應(yīng)用層協(xié)議)，是應(yīng)用層協(xié)議的一個開放標(biāo)準(zhǔn),為面向消息的中間件設(shè)計，兼容 JMS?；诖藚f(xié)議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件同產(chǎn)品，不同的開發(fā)語言等條件的限制。RabbitMQ 就是基于 AMQP 協(xié)議實現(xiàn)的。

4.常見的消息隊列對比

從五個方面分析：

吞吐量：萬級的ActiveMQ和RebbitMQ的吞吐量，要比十萬甚至百萬級別的RocketMQ 和 Kafka 低一個數(shù)量級

可用性：都可以實現(xiàn)高可用，ActiveMQ 和 RabbitMQ 都是基于主從架構(gòu)實現(xiàn)高可用性。RocketMQ 基于分布式架構(gòu)。 kafka 也是分布式的，一個數(shù)據(jù)多個副本，少數(shù)機器宕機，不會丟失數(shù)據(jù)，不會導(dǎo)致不可用

時效性：RabbitMQ 基于erlang開發(fā)，所以并發(fā)能力很強，性能極其好，延時很低，達到微秒級。其他三個都是ms 級。

功能支持：Kafka 功能較為簡單，主要支持簡單的MQ功能，在大數(shù)據(jù)領(lǐng)域的實時計算以及日志采集被大規(guī)模使用，其他都較為完善

消息丟失：丟失可能性很低

5.什么是 Dubbo?

Apache Dubbo (incubating) |?d?b??| 是一款高性能、輕量級的開源Java RPC 框架，它提供了三大核心能力:面向接口的遠(yuǎn)程方法調(diào)用，智能容錯和負(fù)載均衡，以及服務(wù)自動注冊和發(fā)現(xiàn)。簡單來說 Dubbo 是一個分布式服務(wù)框架，致力于提供高性能和透明化的RPC遠(yuǎn)程服務(wù)調(diào)用方案，以及SOA服務(wù)治理方案。

6.什么是 RPC?

RPC是遠(yuǎn)程過程調(diào)用，他是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計算機請求服務(wù)，而不需要了解網(wǎng)絡(luò)協(xié)議，比如兩臺計算機，A提供一個服務(wù)，B提供一個服務(wù)，服務(wù)A想要調(diào)用B的服務(wù)，雖然也可以通過HTTP調(diào)用實現(xiàn)，但是HTTP可能會處理比較慢，并且優(yōu)化不好，用RPC就是為了解決這個問題。

7.RPC原理

1.服務(wù)消費方調(diào)用本地方式提供的服務(wù)

2.client stub接收到調(diào)用后將調(diào)用信息組裝成網(wǎng)絡(luò)消息的傳輸體

3.client stub找到服務(wù)提供方，將消息發(fā)送

4.server stub接收到消息后進行解碼

5.server stub根據(jù)解碼結(jié)果調(diào)用本地服務(wù)

7.將本地調(diào)用的結(jié)果打包成消息發(fā)送回client stub

8.client stub對消息進行解密，發(fā)送給服務(wù)消費方

9.消費方獲得結(jié)果

時序圖

8.為什么要用 Dubbo?

Dubbo的誕生與SOA分布式架構(gòu)有著密切的聯(lián)系，SOA面向服務(wù)的架構(gòu)，將系統(tǒng)拆分為服務(wù)層、表現(xiàn)層兩個部分，服務(wù)層對業(yè)務(wù)邏輯進行處理，表現(xiàn)層只需要處理與頁面的交互，業(yè)務(wù)邏輯都交給服務(wù)層進行處理。SOA的兩個特色就是服務(wù)提供者和服務(wù)消費者

Dubbo有四點特性：

1.負(fù)載均衡：可部署多臺服務(wù)器，系統(tǒng)訪問時由dubbo決定具體調(diào)用哪一臺

2.服務(wù)調(diào)用鏈路形成：部署的服務(wù)越多，服務(wù)啟動的依賴關(guān)系就會模糊，dubbo可以解決我們服務(wù)間是如何調(diào)用的問題；

3.服務(wù)訪問壓力以及時長統(tǒng)計、資源調(diào)度和治理：提供可視化工具，可以對服務(wù)進行治理

4.服務(wù)降級：如果一臺服務(wù)掛掉后，會自動調(diào)用其他的服務(wù)。

9.什么是分布式?

分布式就是將系統(tǒng)的各個模塊通過服務(wù)的方式，部署到不同服務(wù)器上，用以減輕服務(wù)器壓力，并且可以提高系統(tǒng)并發(fā)量和性能。

10.為什么使用分布式？

1.系統(tǒng)拆分為不同的模塊便于開發(fā)；

2.系統(tǒng)拆分為不同的模塊便于系統(tǒng)的維護，提高系統(tǒng)的性能。

11.Dubbo的圖解

dubbo

Provider: 暴露服務(wù)的服務(wù)提供方

Consumer: 調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費方

Registry: 服務(wù)注冊與發(fā)現(xiàn)的注冊中心

Monitor: 統(tǒng)計服務(wù)的調(diào)用次數(shù)和調(diào)用時間的監(jiān)控中心Container: 服務(wù)運行容器

Container: 服務(wù)運行容器

重要知識點總結(jié):

注冊中心負(fù)責(zé)服務(wù)地址的注冊與查找，相當(dāng)于目錄服務(wù)，服務(wù)提供者和消費者只在啟動時與注冊中心交互，注冊中心不轉(zhuǎn)發(fā)請求，壓力較小

監(jiān)控中心負(fù)責(zé)統(tǒng)計各服務(wù)調(diào)用次數(shù)，調(diào)用時間等，統(tǒng)計先在內(nèi)存匯總后每分鐘一次發(fā)送到監(jiān)控中心服務(wù)器，并以報表展示

注冊中心，服務(wù)提供者，服務(wù)消費者三者之間均為長連接，監(jiān)控中心除外

注冊中心通過長連接感知服務(wù)提供者的存在，服務(wù)提供者宕機，注冊中心將立即推送事件通知消費者

注冊中心和監(jiān)控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表

注冊中心和監(jiān)控中心都是可選的，服務(wù)消費者可以直連服務(wù)提供者

服務(wù)提供者無狀態(tài)，任意一臺宕掉后，不影響使用

服務(wù)提供者全部宕掉后，服務(wù)消費者應(yīng)用將無法使用，并無限次重連等待服務(wù)提供者恢復(fù)

12.Dubbo 提供的負(fù)載均衡策略

1.基于權(quán)重的隨機負(fù)載均衡機制；2.基于權(quán)重的輪詢負(fù)載均衡機制；3.最少活躍調(diào)用數(shù)，最慢的服務(wù)活躍數(shù)計數(shù)差大；4.一致性hash

13.zookeeper宕機與dubbo直連的情況

zookeeper宕掉后，dubbo還能基于緩存在一段時間內(nèi)提供服務(wù)。dubbo的健壯性表現(xiàn)在：

1.?監(jiān)控中心宕掉不影響使用，只是丟失部分采樣數(shù)據(jù)

2. 數(shù)據(jù)庫宕掉后，注冊中心仍能通過緩存提供服務(wù)列表查詢，但不能注冊新服務(wù)

3. 注冊中心對等集群，任意一臺宕掉后，將自動切換到另一臺

4. 注冊中心全部宕掉后，服務(wù)提供者和服務(wù)消費者仍能通過本地緩存通訊

5. 服務(wù)提供者無狀態(tài)，任意一臺宕掉后，不影響使用

6. 服務(wù)提供者全部宕掉后，服務(wù)消費者應(yīng)用將無法使用，并無限次重連等待服務(wù)提供者恢復(fù)