免费视频淫片aa毛片_日韩高清在线亚洲专区vr_日韩大片免费观看视频播放_亚洲欧美国产精品完整版

前言

大家好呀，金三銀四即將來臨，整理了十道十分經典的消息隊列面試題，看完肯定對面試有幫助的，大家一起加油哈~

1. 什么是消息隊列
2. 消息隊列的應用場景
3. 消息隊列如何解決消息丟失問題
4. 消息隊列如何保證消息的順序性。
5. 消息有可能發(fā)生重復消費嗎？如何冪等處理？
6. 如何處理消息隊列的消息積壓問題
7. 消息隊列技術選型，Kafka還是RocketMQ，還是RabbitMQ
8. 消息中間件如何做到高可用？
9. 如何保證數(shù)據(jù)一致性，事務消息如何實現(xiàn)
10. 如果讓你寫一個消息隊列，該如何進行架構設計？

1. 什么是消息隊列

你可以把消息隊列理解為一個使用隊列來通信的組件。它的本質，就是個轉發(fā)器，包含發(fā)消息、存消息、消費消息的過程。最簡單的消息隊列模型如下：

我們通常說的消息隊列，簡稱MQ（Message Queue），它其實就指消息中間件，當前業(yè)界比較流行的開源消息中間件包括：RabbitMQ、RocketMQ、Kafka。

2. 消息隊列有哪些使用場景。

有時候面試官會換個角度問你，為什么使用消息隊列。你可以回答以下這幾點：

1. 應用解耦
2. 流量削峰
3. 異步處理
4. 消息通訊
5. 遠程調用

2.1 應用解耦

舉個常見業(yè)務場景：下單扣庫存，用戶下單后，訂單系統(tǒng)去通知庫存系統(tǒng)扣減。傳統(tǒng)的做法就是訂單系統(tǒng)直接調用庫存系統(tǒng)：

• 如果庫存系統(tǒng)無法訪問，下單就會失敗，訂單和庫存系統(tǒng)存在耦合關系
• 如果業(yè)務又接入一個營銷積分服務，那訂單下游系統(tǒng)要擴充，如果未來接入越來越多的下游系統(tǒng)，那訂單系統(tǒng)代碼需要經常修改

如何解決這個問題呢？可以引入消息隊列

1. 訂單系統(tǒng)：用戶下單后，消息寫入到消息隊列，返回下單成功
2. 庫存系統(tǒng)：訂閱下單消息，獲取下單信息，進行庫存扣減操作。

2.2 流量削峰

流量削峰也是消息隊列的常用場景。我們做秒殺實現(xiàn)的時候，需要避免流量暴漲，打垮應用系統(tǒng)的風險?？梢栽趹们懊婕尤胂㈥犃?。

假設秒殺系統(tǒng)每秒最多可以處理2k個請求，每秒卻有5k的請求過來，可以引入消息隊列，秒殺系統(tǒng)每秒從消息隊列拉2k請求處理得了。

有些伙伴擔心這樣會出現(xiàn)消息積壓的問題，

• 首先秒殺活動不會每時每刻都那么多請求過來，高峰期過去后，積壓的請求可以慢慢處理；
• 其次，如果消息隊列長度超過最大數(shù)量，可以直接拋棄用戶請求或跳轉到錯誤頁面；

2.3 異步處理

我們經常會遇到這樣的業(yè)務場景：用戶注冊成功后，給它發(fā)個短信和發(fā)個郵件。

如果注冊信息入庫是30ms，發(fā)短信、郵件也是30ms，三個動作串行執(zhí)行的話，會比較耗時，響應90ms：

如果采用并行執(zhí)行的方式，可以減少響應時間。注冊信息入庫后，同時異步發(fā)短信和郵件。如何實現(xiàn)異步呢，用消息隊列即可，就是說，注冊信息入庫成功后，寫入到消息隊列（這個一般比較快，如只需要3ms），然后異步讀取發(fā)郵件和短信。

2.4 消息通訊

消息隊列內置了高效的通信機制，可用于消息通訊。如實現(xiàn)點對點消息隊列、聊天室等。

2.5 遠程調用

我們公司基于MQ，自研了遠程調用框架。

3. 消息隊列如何解決消息丟失問題？

一個消息從生產者產生，到被消費者消費，主要經過這3個過程：

因此如何保證MQ不丟失消息，可以從這三個階段闡述：

• 生產者保證不丟消息
• 存儲端不丟消息
• 消費者不丟消息

3.1 生產者保證不丟消息

生產端如何保證不丟消息呢？確保生產的消息能到達存儲端。

如果是RocketMQ消息中間件，Producer生產者提供了三種發(fā)送消息的方式，分別是：

• 同步發(fā)送
• 異步發(fā)送
• 單向發(fā)送

生產者要想發(fā)消息時保證消息不丟失，可以：

• 采用同步方式發(fā)送，send消息方法返回成功狀態(tài)，就表示消息正常到達了存儲端Broker。
• 如果send消息異常或者返回非成功狀態(tài)，可以重試。
• 可以使用事務消息，RocketMQ的事務消息機制就是為了保證零丟失來設計的

3.2 存儲端不丟消息

如何保證存儲端的消息不丟失呢？確保消息持久化到磁盤。大家很容易想到就是刷盤機制。

刷盤機制分同步刷盤和異步刷盤：

• 生產者消息發(fā)過來時，只有持久化到磁盤，RocketMQ的存儲端Broker才返回一個成功的ACK響應，這就是同步刷盤。它保證消息不丟失，但是影響了性能。
• 異步刷盤的話，只要消息寫入PageCache緩存，就返回一個成功的ACK響應。這樣提高了MQ的性能，但是如果這時候機器斷電了，就會丟失消息。

Broker一般是集群部署的，有master主節(jié)點和slave從節(jié)點。消息到Broker存儲端，只有主節(jié)點和從節(jié)點都寫入成功，才反饋成功的ack給生產者。這就是同步復制，它保證了消息不丟失，但是降低了系統(tǒng)的吞吐量。與之對應的就是異步復制，只要消息寫入主節(jié)點成功，就返回成功的ack，它速度快，但是會有性能問題。

3.3 消費階段不丟消息

消費者執(zhí)行完業(yè)務邏輯，再反饋會Broker說消費成功，這樣才可以保證消費階段不丟消息。

4. 消息隊列如何保證消息的順序性。

消息的有序性，就是指可以按照消息的發(fā)送順序來消費。有些業(yè)務對消息的順序是有要求的，比如先下單再付款，最后再完成訂單，這樣等。假設生產者先后產生了兩條消息，分別是下單消息（M1），付款消息（M2），M1比M2先產生，如何保證M1比M2先被消費呢。

為了保證消息的順序性，可以將M1、M2發(fā)送到同一個Server上，當M1發(fā)送完收到ack后，M2再發(fā)送。如圖：

這樣還是可能會有問題，因為從MQ服務器到消費端，可能存在網絡延遲，雖然M1先發(fā)送，但是它比M2晚到。

那還能怎么辦才能保證消息的順序性呢？將M1和M2發(fā)往同一個消費者，且發(fā)送M1后，等到消費端ACK成功后，才發(fā)送M2就得了。

消息隊列保證順序性整體思路就是這樣啦。比如Kafka的全局有序消息，就是這種思想的體現(xiàn): 就是生產者發(fā)消息時，1個Topic只能對應1個Partition，一個 Consumer，內部單線程消費。

但是這樣吞吐量太低，一般保證消息局部有序即可。在發(fā)消息的時候指定Partition Key，Kafka對其進行Hash計算，根據(jù)計算結果決定放入哪個Partition。這樣Partition Key相同的消息會放在同一個Partition。然后多消費者單線程消費指定的Partition。

5.消息隊列有可能發(fā)生重復消費，如何避免，如何做到冪等？

消息隊列是可能發(fā)生重復消費的。

• 生產端為了保證消息的可靠性，它可能往MQ服務器重復發(fā)送消息，直到拿到成功的ACK。
• 再然后就是消費端，消費端消費消息一般是這個流程：拉取消息、業(yè)務邏輯處理、提交消費位移。假設業(yè)務邏輯處理完，事務提交了，但是需要更新消費位移時，消費者卻掛了，這時候另一個消費者就會拉到重復消息了。

如何冪等處理重復消息呢？

我之前寫過一篇冪等設計的文章，大家有興趣可以看下哈：聊聊冪等設計

冪等處理重復消息，簡單來說，就是搞個本地表，帶唯一業(yè)務標記的，利用主鍵或者唯一性索引，每次處理業(yè)務，先校驗一下就好啦。又或者用redis緩存下業(yè)務標記，每次看下是否處理過了。

6. 如何處理消息隊列的消息積壓問題

消息積壓是因為生產者的生產速度，大于消費者的消費速度。遇到消息積壓問題時，我們需要先排查，是不是有bug產生了。

如果不是bug，我們可以優(yōu)化一下消費的邏輯，比如之前是一條一條消息消費處理的話，我們可以確認是不是可以優(yōu)為批量處理消息。如果還是慢，我們可以考慮水平擴容，增加Topic的隊列數(shù)，和消費組機器的數(shù)量，提升整體消費能力。

如果是bug導致幾百萬消息持續(xù)積壓幾小時。有如何處理呢？需要解決bug，臨時緊急擴容，大概思路如下：

1. 先修復consumer消費者的問題，以確保其恢復消費速度，然后將現(xiàn)有consumer 都停掉。
2. 新建一個 topic，partition 是原來的 10 倍，臨時建立好原先10倍的queue 數(shù)量。
3. 然后寫一個臨時的分發(fā)數(shù)據(jù)的 consumer 程序，這個程序部署上去消費積壓的數(shù)據(jù)，消費之后不做耗時的處理，直接均勻輪詢寫入臨時建立好的 10 倍數(shù)量的 queue。
4. 接著臨時征用 10 倍的機器來部署 consumer，每一批 consumer 消費一個臨時 queue 的數(shù)據(jù)。這種做法相當于是臨時將 queue 資源和 consumer 資源擴大 10 倍，以正常的 10 倍速度來消費數(shù)據(jù)。
5. 等快速消費完積壓數(shù)據(jù)之后，得恢復原先部署的架構，重新用原先的 consumer 機器來消費消息。

7. 消息隊列技術選型，Kafka還是RocketMQ，還是RabbitMQ

先可以對比下它們優(yōu)缺點：

• RabbitMQ是開源的，比較穩(wěn)定的支持，活躍度也高，但是不是Java語言開發(fā)的。
• 很多公司用RocketMQ，比較成熟，是阿里出品的。
• 如果是大數(shù)據(jù)領域的實時計算、日志采集等場景，用 Kafka 是業(yè)內標準的。

8. 消息中間件如何做到高可用

消息中間件如何保證高可用呢？單機是沒有高可用可言的，高可用都是對集群來說的，一起看下kafka的高可用吧。

Kafka 的基礎集群架構，由多個broker組成，每個broker都是一個節(jié)點。當你創(chuàng)建一個topic時，它可以劃分為多個partition，而每個partition放一部分數(shù)據(jù)，分別存在于不同的 broker 上。也就是說，一個 topic 的數(shù)據(jù)，是分散放在多個機器上的，每個機器就放一部分數(shù)據(jù)。

有些伙伴可能有疑問，每個partition放一部分數(shù)據(jù)，如果對應的broker掛了，那這部分數(shù)據(jù)是不是就丟失了？那還談什么高可用呢？

Kafka 0.8 之后，提供了復制品副本機制來保證高可用，即每個 partition 的數(shù)據(jù)都會同步到其它機器上，形成多個副本。然后所有的副本會選舉一個 leader 出來，讓leader去跟生產和消費者打交道，其他副本都是follower。寫數(shù)據(jù)時，leader 負責把數(shù)據(jù)同步給所有的follower，讀消息時， 直接讀 leader 上的數(shù)據(jù)即可。如何保證高可用的？就是假設某個 broker 宕機，這個broker上的partition 在其他機器上都有副本的。如果掛的是leader的broker呢？其他follower會重新選一個leader出來。

9. 如何保證數(shù)據(jù)一致性，事務消息如何實現(xiàn)

一條普通的MQ消息，從產生到被消費，大概流程如下：

1. 生產者產生消息，發(fā)送帶MQ服務器
2. MQ收到消息后，將消息持久化到存儲系統(tǒng)。
3. MQ服務器返回ACk到生產者。
4. MQ服務器把消息push給消費者
5. 消費者消費完消息，響應ACK
6. MQ服務器收到ACK，認為消息消費成功，即在存儲中刪除消息。

我們舉個下訂單的例子吧。訂單系統(tǒng)創(chuàng)建完訂單后，再發(fā)送消息給下游系統(tǒng)。如果訂單創(chuàng)建成功，然后消息沒有成功發(fā)送出去，下游系統(tǒng)就無法感知這個事情，出導致數(shù)據(jù)不一致。

如何保證數(shù)據(jù)一致性呢？可以使用事務消息。一起來看下事務消息是如何實現(xiàn)的吧。

1. 生產者產生消息，發(fā)送一條半事務消息到MQ服務器
2. MQ收到消息后，將消息持久化到存儲系統(tǒng)，這條消息的狀態(tài)是待發(fā)送狀態(tài)。
3. MQ服務器返回ACK確認到生產者，此時MQ不會觸發(fā)消息推送事件
4. 生產者執(zhí)行本地事務
5. 如果本地事務執(zhí)行成功，即commit執(zhí)行結果到MQ服務器；如果執(zhí)行失敗，發(fā)送rollback。
6. 如果是正常的commit，MQ服務器更新消息狀態(tài)為可發(fā)送；如果是rollback，即刪除消息。
7. 如果消息狀態(tài)更新為可發(fā)送，則MQ服務器會push消息給消費者。消費者消費完就回ACK。
8. 如果MQ服務器長時間沒有收到生產者的commit或者rollback，它會反查生產者，然后根據(jù)查詢到的結果執(zhí)行最終狀態(tài)。

10. 讓你寫一個消息隊列，該如何進行架構設計？

這個問題面試官主要考察三個方面的知識點：

• 你有沒有對消息隊列的架構原理比較了解
• 考察你的個人設計能力
• 考察編程思想，如什么高可用、可擴展性、冪等等等。

遇到這種設計題，大部分人會很蒙圈，因為平時沒有思考過類似的問題。大多數(shù)人平時埋頭增刪改啥，不去思考框架背后的一些原理。有很多類似的問題，比如讓你來設計一個 Dubbo 框架，或者讓你來設計一個MyBatis 框架，你會怎么思考呢？

回答這類問題，并不要求你研究過那技術的源碼，你知道那個技術框架的基本結構、工作原理即可。設計一個消息隊列，我們可以從這幾個角度去思考：

1. 首先是消息隊列的整體流程，producer發(fā)送消息給broker，broker存儲好，broker再發(fā)送給consumer消費，consumer回復消費確認等。
2. producer發(fā)送消息給broker，broker發(fā)消息給consumer消費，那就需要兩次RPC了，RPC如何設計呢？可以參考開源框架Dubbo，你可以說說服務發(fā)現(xiàn)、序列化協(xié)議等等
3. broker考慮如何持久化呢，是放文件系統(tǒng)還是數(shù)據(jù)庫呢，會不會消息堆積呢，消息堆積如何處理呢。
4. 消費關系如何保存呢？點對點還是廣播方式呢？廣播關系又是如何維護呢？zk還是config server
5. 消息可靠性如何保證呢？如果消息重復了，如何冪等處理呢？
6. 消息隊列的高可用如何設計呢？可以參考Kafka的高可用保障機制。多副本 -> leader & follower -> broker 掛了重新選舉 leader 即可對外服務。
7. 消息事務特性，與本地業(yè)務同個事務，本地消息落庫;消息投遞到服務端，本地才刪除；定時任務掃描本地消息庫，補償發(fā)送。
8. MQ得伸縮性和可擴展性，如果消息積壓或者資源不夠時，如何支持快速擴容，提高吞吐？可以參照一下 Kafka 的設計理念，broker -> topic -> partition，每個 partition 放一個機器，就存一部分數(shù)據(jù)。如果現(xiàn)在資源不夠了，簡單啊，給 topic 增加 partition，然后做數(shù)據(jù)遷移，增加機器，不就可以存放更多數(shù)據(jù)，提供更高的吞吐量了？

參考與感謝

微信8.0將好友放開到了一萬，小伙伴可以加我大號了，先到先得，再滿就真沒了