???????

1、為什么使用消息隊(duì)列？

解耦、異步、削峰

2、消息隊(duì)列有什么優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：解耦、異步、削峰

缺點(diǎn)：系統(tǒng)可用性降低、系統(tǒng)復(fù)雜度提高、一致性問題

3、如何進(jìn)?消息隊(duì)列選型？

• Kafka：

○ 優(yōu)點(diǎn)： 吞吐量?常?，性能?常好，集群?可?。

○ 缺點(diǎn)：會丟數(shù)據(jù)，功能?較單?。

○ 使?場景：?志分析、?數(shù)據(jù)采集

• RabbitMQ：

○ 優(yōu)點(diǎn)： 消息可靠性?，功能全?。

○ 缺點(diǎn)：吞吐量?較低，消息積累會嚴(yán)重影響性能。erlang語?不好定制。

○ 使?場景：?規(guī)模場景

• RocketMQ：

○ 優(yōu)點(diǎn)：?吞吐、?性能、?可?，功能?常全?。

○ 缺點(diǎn)：開源版功能不如云上商業(yè)版。官??檔和周邊?態(tài)還不夠成熟。客戶端只?持java。

○ 使?場景：?乎是全場景。

4、ActiveMQ、RabbitMQ、RocketMQ、Kafka比較

1. 單機(jī)吞吐量： ActiveMQ、RabbitMQ 萬級；RocketMQ、Kafka 10萬級

2. topic數(shù)量對吞吐量影響：RocketMQ幾百幾千topic性能略微下降，Kafka從幾十到幾百性能急劇下降

3. 時效性： RabbitMQ 微秒級別；ActiveMQ、RocketMQ、Kafka 毫秒級別

4. 可用性：ActiveMQ、RabbitMQ主從架構(gòu)，高可用；RocketMQ、Kafka分布式架構(gòu)，可用性非常高

5. 可靠性：ActiveMQ小概率丟數(shù)據(jù)；Rabbit幾乎不丟；RocketMQ、Kafka通過配置可實(shí)現(xiàn)0丟失功能支持

6. 功能完備度：ActiveMQ極其完備；RabbitMQ性能高延遲低；RocketMQ功能豐富且是分布式架構(gòu)，易擴(kuò)展；Kafka功能簡單，適合特定場景。

5、RocketMQ

（1）RocketMQ組成部分（角色）有哪些？

1. 生產(chǎn)者（Producer）：負(fù)責(zé)產(chǎn)生消息，生產(chǎn)者向消息服務(wù)器發(fā)送由業(yè)務(wù)應(yīng)用程序系統(tǒng)生成的消息。

2. 消費(fèi)者（Consumer）：負(fù)責(zé)消費(fèi)消息，消費(fèi)者從消息服務(wù)器拉取信息并將其輸入用戶應(yīng)用程序。

3. 消息服務(wù)器（Broker）：是消息存儲中心，主要作用是接收來自 Producer 的消息并存儲， Consumer從這里取得消息。

4. 名稱服務(wù)器（NameServer）：用來保存 Broker 相關(guān) Topic 等元信息并給 Producer ，提供 Consumer查找 Broker 信息。

（2）RocketMQ消費(fèi)模式有幾種?

集群消費(fèi)

• 一條消息只會被同Group中的一個Consumer消費(fèi)

• 多個Group同時消費(fèi)一個Topic時，每個Group都會有一個Consumer消費(fèi)到數(shù)據(jù)???????

廣播消費(fèi)

• 消息將對一個Consumer Group 下的各個 Consumer 實(shí)例都消費(fèi)一遍。即即使這些 Consumer

屬于同一個Consumer Group ，消息也會被 Consumer Group 中的每個 Consumer 都消費(fèi)一

次

（3）RocketMQ如何保證消息的順序消費(fèi)？

生產(chǎn)者有序發(fā)送

生產(chǎn)者在投放消息的時候自定義投放策略，我們實(shí)現(xiàn)一個MessageQueueSelector接口，使用Hash取模法來保證同一個訂單在同一個隊(duì)列中就行了，即通過訂單ID%隊(duì)列數(shù)量得到該ID的訂單所投放的隊(duì)列在隊(duì)列列表中的索引，然后該訂單的所有消息都會被投放到這個隊(duì)列中。

消費(fèi)者有序消費(fèi)

RockerMQ的MessageListener回調(diào)函數(shù)提供了兩種消費(fèi)模式，有序消費(fèi)模式MessageListenerOrderly和并發(fā)消費(fèi)模式MessageListenerConcurrently。

在消費(fèi)的時候，還需要保證消費(fèi)者注冊MessageListenerOrderly類型的回調(diào)接口實(shí)現(xiàn)順序消費(fèi)，如果消費(fèi)者采用Concurrently并行消費(fèi)，則仍然不能保證消息消費(fèi)順序。

（4）RocketMQ如何保證消息不丟失？

Producer端

采取 send() 同步發(fā)消息，發(fā)送結(jié)果是同步感知的。

發(fā)送失敗后可以重試，設(shè)置重試次數(shù)。默認(rèn)3次。

Broker端

修改刷盤策略為同步刷盤。默認(rèn)情況下是異步刷盤的。

集群部署

Consumer端

完全消費(fèi)正常后在進(jìn)行手動ack確認(rèn)

（5）RocketMQ執(zhí)行流程?

1. 啟動 Namesrv，Namesrv起 來后監(jiān)聽端口，等待 Broker、Producer、Consumer 連上來，相當(dāng)于一個路由控制中心。

2. Broker 啟動，跟所有的 Namesrv 保持長連接，定時發(fā)送心跳包。

3. 收發(fā)消息前，先創(chuàng)建 Topic 。創(chuàng)建 Topic 時，需要指定該 Topic 要存儲在 哪些 Broker上。也可以在發(fā)送消息時自動創(chuàng)建Topic。

4. Producer 發(fā)送消息。

5. Consumer 消費(fèi)消息。

（6）消費(fèi)者獲取消息有幾種模式？

消費(fèi)者獲取消息有兩種模式：推送模式和拉取模式。

PushConsumer

推送模式（雖然 RocketMQ 使用的是長輪詢）的消費(fèi)者。消息的能及時被消費(fèi)。使用非常簡單，內(nèi)部已處理如線程池消費(fèi)、流控、負(fù)載均衡、異常處理等等的各種場景。

PullConsumer

拉取模式的消費(fèi)者。應(yīng)用主動控制拉取的時機(jī)，怎么拉取，怎么消費(fèi)等。主動權(quán)更高。但要自己處理各種場景

（7）RocketMQ的事務(wù)消息是如何實(shí)現(xiàn)的

a. ?產(chǎn)者訂單系統(tǒng)先發(fā)送?條half消息到Broker，half消息對消費(fèi)者??是不可?的

b. 再創(chuàng)建訂單，根據(jù)創(chuàng)建訂單成功與否，向Broker發(fā)送commit或rollback

c. 并且?產(chǎn)者訂單系統(tǒng)還可以提供Broker回調(diào)接?，當(dāng)Broker發(fā)現(xiàn)?段時間half消息沒有收到任

何操作命令，則會主動調(diào)此接?來查詢訂單是否創(chuàng)建成功

d. ?旦half消息commit了，消費(fèi)者庫存系統(tǒng)就會來消費(fèi)，如果消費(fèi)成功，則消息銷毀，分布式事

務(wù)成功結(jié)束

e. 如果消費(fèi)失敗，則根據(jù)重試策略進(jìn)?重試，最后還失敗則進(jìn)?死信隊(duì)列，等待進(jìn)?步處理

6、如何保證消息隊(duì)列的高可用

Rabbit：鏡像集群

在鏡像集群模式下，你創(chuàng)建的 queue，無論元數(shù)據(jù)還是 queue 里的消息都會存在于多個實(shí)例上，就是說，每個 RabbitMQ 節(jié)點(diǎn)都有這個 queue 的一個完整鏡像，包含 queue 的全部數(shù)據(jù)的意思。然后每次你寫消息到 queue 的時候，都會自動把消息同步到多個實(shí)例的 queue 上。

Kafka：基于分布式實(shí)現(xiàn)高可用，多個broker，多partion，多replica，leader讀寫，follower主動從leader處pull數(shù)據(jù)

7、如何保證消息不被重復(fù)消費(fèi)？

上下游約定唯一標(biāo)識

1. 寫庫根據(jù)唯一鍵排重

2. 寫redis set天然排重

8、如何保證消息的可靠性傳輸？

消息可靠傳輸代表了兩層意思，既不能多也不能少。

1. 為了保證消息不多，也就是消息不能重復(fù)，也就是?產(chǎn)者不能重復(fù)?產(chǎn)消息，或者消費(fèi)者不能重復(fù)消費(fèi)消息

2. ?先要確保消息不多發(fā)，這個不常出現(xiàn)，也?較難控制，因?yàn)槿绻霈F(xiàn)了多發(fā)，很?的原因是?產(chǎn)者??的原因，如果要避免出現(xiàn)問題，就需要在消費(fèi)端做控制

3. 要避免不重復(fù)消費(fèi)，最保險的機(jī)制就是消費(fèi)者實(shí)現(xiàn)冪等性，保證就算重復(fù)消費(fèi)，也不會有問題，通過冪等性，也能解決?產(chǎn)者重復(fù)發(fā)送消息的問題

4. 消息不能少，意思就是消息不能丟失，?產(chǎn)者發(fā)送的消息，消費(fèi)者?定要能消費(fèi)到，對于這個問題，就要考慮兩個??

5. ?產(chǎn)者發(fā)送消息時，要確認(rèn)broker確實(shí)收到并持久化了這條消息，?如RabbitMQ的confirm機(jī)制，Kafka的ack機(jī)制都可以保證?產(chǎn)者能正確的將消息發(fā)送給broker

6. broker要等待消費(fèi)者真正確認(rèn)消費(fèi)到了消息時才刪除掉消息，這?通常就是消費(fèi)端ack機(jī)制，消費(fèi)者接收到?條消息后，如果確認(rèn)沒問題了，就可以給broker發(fā)送?個ack，broker接收到ack后才會刪除消息

9、Kafka如何保證消息的順序性

在Kafka中Partition(分區(qū))是真正保存消息的地方，發(fā)送的消息都存放在這里。Partition(分區(qū))又存在于Topic（主題）中，并且一個Topic（主題）可以指定多個Partition(分區(qū))。

在Kafka中，只保證Partition(分區(qū))內(nèi)有序，不保證Topic所有分區(qū)都是有序的。

所以 Kafka 要保證消息的消費(fèi)順序，可以有2種方法：

1. 1個Topic（主題）只創(chuàng)建1個Partition(分區(qū))，這樣生產(chǎn)者的所有數(shù)據(jù)都發(fā)送到了一個Partition(分區(qū))，保證了消息的消費(fèi)順序。

2. 生產(chǎn)者在發(fā)送消息的時候指定要發(fā)送到哪個Partition(分區(qū))。

10、RocketMQ的實(shí)現(xiàn)原理

RocketMQ由NameServer注冊中?集群、Producer?產(chǎn)者集群、Consumer消費(fèi)者集群和若?Broker （RocketMQ進(jìn)程）組成，它的架構(gòu)原理是這樣的：

Broker在啟動的時候去向所有的NameServer注冊，并保持?連接，每30s發(fā)送?次?跳

Producer在發(fā)送消息的時候從NameServer獲取Broker服務(wù)器地址，根據(jù)負(fù)載均衡算法選擇?臺服務(wù)器來發(fā)送消息

Conusmer消費(fèi)消息的時候同樣從NameServer獲取Broker地址，然后主動拉取消息來消費(fèi)

11、kafka的零拷貝原理

1. mmap機(jī)制

2. sendfile()

12、說一下 Kafka 中 Partition 分區(qū)副本的 Leader 選舉算法

Kafka 首先會選擇一個具有最新數(shù)據(jù)的副本作為新的 Leader，也就是 ISR 集合中的副本。其中，ISR（In-Sync Replica）是指與 Leader 同步的副本集合，它們的數(shù)據(jù)同步狀態(tài)與 Leader 最接近，并且它們與 Leader 副本的網(wǎng)絡(luò)通信延遲最小。

如果 ISR 集合中沒有可用的副本，Kafka 會從所有副本中選擇一個具有最新數(shù)據(jù)的副本作為新的 Leader。在這種情況下選舉出來的 Leader，由于和原來老的 Leader 節(jié)點(diǎn)的數(shù)據(jù)存在較大的延遲，會造成數(shù)據(jù)丟失的情況

所以 Kafka 設(shè)計(jì)者把這個功能開關(guān)的選擇交給了開發(fā)者，如果愿意接受這種情況，可以通過unclean.leader.election.enable 參數(shù)來設(shè)置。開啟之后雖然會造成數(shù)據(jù)丟失，但是至少可以保證依然能對外提供服務(wù)，保證了可用性

13、大量消息積壓，如何處理？

1. consumer出問題，首先修復(fù)consumer問題，恢復(fù)其消費(fèi)速度。

2. 新建10個queue，程序分發(fā)原來隊(duì)列里面的數(shù)據(jù)到10個queue里面，10倍consumer機(jī)器，每一批消費(fèi)一個queue，處理完成之后恢復(fù)原來架構(gòu)。

14、如何設(shè)計(jì)一個消息隊(duì)列？

可伸縮性，broker -> topic -> partition

可靠性，消息持久化，磁盤順序?qū)?#xff0c;數(shù)據(jù)零丟失方案

可用性，多副本 -> leader & follower -> broker 掛了重新選舉 leader