???????

1、為什么使用消息隊列？

解耦、異步、削峰

2、消息隊列有什么優(yōu)缺點

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

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

3、如何進?消息隊列選型？

• Kafka：

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

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

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

• RabbitMQ：

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

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

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

• RocketMQ：

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

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

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

4、ActiveMQ、RabbitMQ、RocketMQ、Kafka比較

1. 單機吞吐量： 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通過配置可實現(xiàn)0丟失功能支持

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

5、RocketMQ

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

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

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

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

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

（2）RocketMQ消費模式有幾種?

集群消費

• 一條消息只會被同Group中的一個Consumer消費

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

廣播消費

• 消息將對一個Consumer Group 下的各個 Consumer 實例都消費一遍。即即使這些 Consumer

屬于同一個Consumer Group ，消息也會被 Consumer Group 中的每個 Consumer 都消費一

次

（3）RocketMQ如何保證消息的順序消費？

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

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

消費者有序消費

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

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

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

Producer端

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

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

Broker端

修改刷盤策略為同步刷盤。默認情況下是異步刷盤的。

集群部署

Consumer端

完全消費正常后在進行手動ack確認

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

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

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

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

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

5. Consumer 消費消息。

（6）消費者獲取消息有幾種模式？

消費者獲取消息有兩種模式：推送模式和拉取模式。

PushConsumer

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

PullConsumer

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

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

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

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

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

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

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

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

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

6、如何保證消息隊列的高可用

Rabbit：鏡像集群

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

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

7、如何保證消息不被重復消費？

上下游約定唯一標識

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

2. 寫redis set天然排重

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

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

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

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

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

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

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

6. broker要等待消費者真正確認消費到了消息時才刪除掉消息，這?通常就是消費端ack機制，消費者接收到?條消息后，如果確認沒問題了，就可以給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 要保證消息的消費順序，可以有2種方法：

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

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

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

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

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

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

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

11、kafka的零拷貝原理

1. mmap機制

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é)點的數(shù)據(jù)存在較大的延遲，會造成數(shù)據(jù)丟失的情況

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

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

1. consumer出問題，首先修復consumer問題，恢復其消費速度。

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

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

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

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

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