消息中間件面試題31道RabbitMQ+ActiveMQ+Kafka-創(chuàng)新互聯(lián)

前言

文章開始前，我們先了解一下什么是消息中間件？

創(chuàng)新互聯(lián)公司堅(jiān)信：善待客戶，將會(huì)成為終身客戶。我們能堅(jiān)持多年，是因?yàn)槲覀円恢笨芍档眯刨?。我們從不忽悠初訪客戶，我們用心做好本職工作，不忘初心，方得始終。10年網(wǎng)站建設(shè)經(jīng)驗(yàn)創(chuàng)新互聯(lián)公司是成都老牌網(wǎng)站營(yíng)銷服務(wù)商,為您提供成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)、html5、網(wǎng)站制作、品牌網(wǎng)站建設(shè)、成都微信小程序服務(wù),給眾多知名企業(yè)提供過好品質(zhì)的建站服務(wù)。

什么是中間件？

非底層操作系統(tǒng)軟件，非業(yè)務(wù)應(yīng)用軟件，不是直接給最終用戶使用的，不能直接給客戶帶來價(jià)值的軟件統(tǒng)稱為中間件。

什么是消息中間件？

是關(guān)注于數(shù)據(jù)的發(fā)送和接收，利用高效可靠的異步消息傳遞機(jī)制集成分布式系統(tǒng)

圖示：

消息中間件RabbitMQ+ActiveMQ+Kafka的對(duì)比

接下來就是消息中間件面試題RabbitMQ+ActiveMQ+Kafka

RabbitMQ消息中間件系列

1：RabbitMQ 中的 broker 是指什么？cluster 又是指什么？

答：broker 是指一個(gè)或多個(gè) erlang node 的邏輯分組，且 node 上運(yùn)行著 RabbitMQ 應(yīng)用程序。cluster 是在 broker 的基礎(chǔ)之上，增加了 node 之間共享元數(shù)據(jù)的約束。

2：什么是元數(shù)據(jù)？元數(shù)據(jù)分為哪些類型？包括哪些內(nèi)容？與 cluster 相關(guān)的元數(shù)據(jù)有哪些？元數(shù)據(jù)是如何保存的？元數(shù)據(jù)在 cluster 中是如何分布的？

答：在非 cluster 模式下，元數(shù)據(jù)主要分為 Queue 元數(shù)據(jù)（queue 名字和屬性等）、Exchange 元數(shù)據(jù)（exchange 名字、類型和屬性等）、Binding 元數(shù)據(jù)（存放路由關(guān)系的查找表）、Vhost 元數(shù)據(jù)（vhost 范圍內(nèi)針對(duì)前三者的名字空間約束和安全屬性設(shè)置）。在cluster 模式下，還包括 cluster 中 node 位置信息和 node 關(guān)系信息。元數(shù)據(jù)按照 erlang node 的類型確定是僅保存于 RAM 中，還是同時(shí)保存在 RAM 和 disk 上。元數(shù)據(jù)在cluster 中是全 node 分布的。

3：RAM node 和 disk node 的區(qū)別？

答：RAM node 僅將 fabric（即 queue、exchange 和 binding 等 RabbitMQ 基礎(chǔ)構(gòu)件）相關(guān)元數(shù)據(jù)保存到內(nèi)存中，但 disk node 會(huì)在內(nèi)存和磁盤中均進(jìn)行存儲(chǔ)。RAM node 上唯一會(huì)存儲(chǔ)到磁盤上的元數(shù)據(jù)是 cluster 中使用的 disk node 的地址。要求在 RabbitMQ cluster 中至少存在一個(gè) disk node 。

4：RabbitMQ 上的一個(gè) queue 中存放的 message 是否有數(shù)量限制？

答：可以認(rèn)為是無(wú)限制，因?yàn)橄拗迫Q于機(jī)器的內(nèi)存，但是消息過多會(huì)導(dǎo)致處理效率的下降。

5：RabbitMQ 概念里的 channel、exchange 和 queue 這些東東是邏輯概念，還是對(duì)應(yīng)著進(jìn)程實(shí)體？這些東東分別起什么作用？

答：queue 具有自己的 erlang 進(jìn)程；exchange 內(nèi)部實(shí)現(xiàn)為保存 binding 關(guān)系的查找表； channel 是實(shí)際進(jìn)行路由工作的實(shí)體，即負(fù)責(zé)按照 routing_key 將 message 投遞給queue 。由 AMQP 協(xié)議描述可知，channel 是真實(shí) TCP 連接之上的虛擬連接，所有AMQP 命令都是通過 channel 發(fā)送的，且每一個(gè) channel 有唯一的 ID。一個(gè) channel 只能被單獨(dú)一個(gè)操作系統(tǒng)線程使用，故投遞到特定 channel 上的 message 是有順序的。但一個(gè)操作系統(tǒng)線程上允許使用多個(gè) channel 。channel 號(hào)為 0 的 channel 用于處理所有對(duì)于當(dāng)前 connection 全局有效的幀，而 1-65535 號(hào) channel 用于處理和特定 channel 相關(guān)的幀。

其中每一個(gè) channel 運(yùn)行在一個(gè)獨(dú)立的線程上，多線程共享同一個(gè) socket。

6：vhost 是什么？起什么作用？

答：vhost 可以理解為虛擬 broker ，即 mini-RabbitMQ server。其內(nèi)部均含有獨(dú)立的

queue、exchange 和 binding 等，但最最重要的是，其擁有獨(dú)立的權(quán)限系統(tǒng)，可以做到vhost 范圍的用戶控制。當(dāng)然，從 RabbitMQ 的全局角度，vhost 可以作為不同權(quán)限隔離的手段（一個(gè)典型的例子就是不同的應(yīng)用可以跑在不同的 vhost 中）。

7：為什么 heavy RPC 的使用場(chǎng)景下不建議采用 disk node ？

答：heavy RPC 是指在業(yè)務(wù)邏輯中高頻調(diào)用 RabbitMQ 提供的 RPC 機(jī)制，導(dǎo)致不斷創(chuàng)建、銷毀 reply queue ，進(jìn)而造成 disk node 的性能問題（因?yàn)闀?huì)針對(duì)元數(shù)據(jù)不斷寫盤）。所以在使用 RPC 機(jī)制時(shí)需要考慮自身的業(yè)務(wù)場(chǎng)景。

8：向不存在的 exchange 發(fā) publish 消息會(huì)發(fā)生什么？向不存在的 queue 執(zhí)行consume 動(dòng)作會(huì)發(fā)生什么？

答：都會(huì)收到 Channel.Close 信令告之不存在（內(nèi)含原因 404 NOT_FOUND）。

9：RabbitMQ 允許發(fā)送的 message 大可達(dá)多大？

答：根據(jù) AMQP 協(xié)議規(guī)定，消息體的大小由 64-bit 的值來指定，所以你就可以知道到底能發(fā)多大的數(shù)據(jù)了。

10：什么情況下 producer 不主動(dòng)創(chuàng)建 queue 是安全的？

答：1.message是允許丟失的；2.實(shí)現(xiàn)了針對(duì)未處理消息的republish功能（例如采用Publisher Confirm 機(jī)制）。

11：“dead letter”queue 的用途？

答：當(dāng)消息被 RabbitMQ server 投遞到 consumer 后，但 consumer 卻通過 Basic.Reject 進(jìn)行了拒絕時(shí)（同時(shí)設(shè)置 requeue=false），那么該消息會(huì)被放入“dead letter”queue 中。該 queue 可用于排查 message 被 reject 或 undeliver 的原因。

12：為什么說保證 message 被可靠持久化的條件是 queue 和 exchange 具有durable 屬性，同時(shí) message 具有 persistent 屬性才行？

答：binding 關(guān)系可以表示為 exchange – binding – queue 。從文檔中我們知道，若要求投遞的 message 能夠不丟失，要求 message 本身設(shè)置 persistent 屬性，要求 exchange 和 queue 都設(shè)置 durable 屬性。其實(shí)這問題可以這么想，若 exchange 或 queue 未設(shè)置durable 屬性，則在其 crash 之后就會(huì)無(wú)法恢復(fù)，那么即使 message 設(shè)置了 persistent 屬性，仍然存在 message 雖然能恢復(fù)但卻無(wú)處容身的問題；同理，若 message 本身未設(shè)置persistent 屬性，則 message 的持久化更無(wú)從談起。

13：什么情況下會(huì)出現(xiàn) blackholed 問題？

答：blackholed 問題是指，向 exchange 投遞了 message ，而由于各種原因?qū)е略搈essage 丟失，但發(fā)送者卻不知道?？蓪?dǎo)致 blackholed 的情況：1.向未綁定 queue 的exchange 發(fā)送 message；2.exchange 以 binding_key key_A 綁定了 queue queue_A，但向該 exchange 發(fā)送 message 使用的 routing_key 卻是 key_B。

14：如何防止出現(xiàn) blackholed 問題？

答：沒有特別好的辦法，只能在具體實(shí)踐中通過各種方式保證相關(guān) fabric 的存在。另外， 如果在執(zhí)行 Basic.Publish 時(shí)設(shè)置 mandatory=true ，則在遇到可能出現(xiàn) blackholed 情況時(shí)，服務(wù)器會(huì)通過返回 Basic.Return 告之當(dāng)前 message 無(wú)法被正確投遞（內(nèi)含原因 312 NO_ROUTE）。

15：Consumer Cancellation Notification 機(jī)制用于什么場(chǎng)景？

答：用于保證當(dāng)鏡像 queue 中 master 掛掉時(shí)，連接到 slave 上的 consumer 可以收到自身 consume 被取消的通知，進(jìn)而可以重新執(zhí)行 consume 動(dòng)作從新選出的 master 出獲得消息。若不采用該機(jī)制，連接到 slave 上的 consumer 將不會(huì)感知 master 掛掉這個(gè)事情，導(dǎo)致后續(xù)無(wú)法再收到新 master 廣播出來的 message 。另外，因?yàn)樵阽R像 queue 模式下，存在將 message 進(jìn)行 requeue 的可能，所以實(shí)現(xiàn) consumer 的邏輯時(shí)需要能夠正確處理出現(xiàn)重復(fù) message 的情況。

ActiveMQ消息中間件系列

1.什么是 ActiveMQ?

activeMQ 是一種開源的，實(shí)現(xiàn)了 JMS1.1 規(guī)范的，面向消息(MOM)的中間件，為應(yīng)用程序提供高效的、可擴(kuò)展的、穩(wěn)定的和安全的企業(yè)級(jí)消息通信

2.ActiveMQ 服務(wù)器宕機(jī)怎么辦？

這得從 ActiveMQ 的儲(chǔ)存機(jī)制說起。在通常的情況下，非持久化消息是存儲(chǔ)在內(nèi)存中的，持久化消息是存儲(chǔ)在文件中的，它們的大限制在配置文件的節(jié)點(diǎn)中配置。但是，在非持久化消息堆積到一定程度，內(nèi)存告急的時(shí)候，ActiveMQ 會(huì)將內(nèi)存中的非持久化消息寫入臨時(shí)文件中，以騰出內(nèi)存。雖然都保存到了文件里，但它和持久化消息的區(qū)別是，重啟后持久化消息會(huì)從文件中恢復(fù)，非持久化的臨時(shí)文件會(huì)直接刪除。

那如果文件增大到達(dá)了配置中的大限制的時(shí)候會(huì)發(fā)生什么？我做了以下實(shí)驗(yàn)：

設(shè)置 2G 左右的持久化文件限制，大量生產(chǎn)持久化消息直到文件達(dá)到大限制，此時(shí)生產(chǎn)者阻塞，但消費(fèi)者可正常連接并消費(fèi)消息，等消息消費(fèi)掉一部分，文件刪除又騰出空間之后，生產(chǎn)者又可繼續(xù)發(fā)送消息， 服務(wù)自動(dòng)恢復(fù)正常。

設(shè)置 2G 左右的臨時(shí)文件限制，大量生產(chǎn)非持久化消息并寫入臨時(shí)文件，在達(dá)到大限制時(shí)，生產(chǎn)者阻塞，消費(fèi)者可正常連接但不能消費(fèi)消息，或者原本慢速消費(fèi)的消費(fèi)者，消費(fèi)突然停止。整個(gè)系統(tǒng)可連接， 但是無(wú)法提供服務(wù)，就這樣掛了。

具體原因不詳，解決方案：盡量不要用非持久化消息，非要用的話，將臨時(shí)文件限制盡可能的調(diào)大。

3.丟消息怎么辦？

這得從 java 的 java.net.SocketException 異常說起。簡(jiǎn)單點(diǎn)說就是當(dāng)網(wǎng)絡(luò)發(fā)送方發(fā)送一堆數(shù)據(jù)，然后調(diào)用 close 關(guān)閉連接之后。這些發(fā)送的數(shù)據(jù)都在接收者的緩存里，接收者如果調(diào)用 read 方法仍舊能從緩存中讀取這些數(shù)據(jù)，盡管對(duì)方已經(jīng)關(guān)閉了連接。但是當(dāng)接收者嘗試發(fā)送數(shù)據(jù)時(shí)，由于此時(shí)連接已關(guān)閉，所以會(huì)發(fā)生異常，這個(gè)很好理解。不過需要注意的是，當(dāng)發(fā)生 SocketException 后，原本緩存區(qū)中數(shù)據(jù)也作廢了，此時(shí)接收者再次調(diào)用 read 方法去讀取緩存中的數(shù)據(jù)，就會(huì)報(bào) Software caused connection abort: recv failed 錯(cuò)誤。

通過抓包得知，ActiveMQ 會(huì)每隔 10 秒發(fā)送一個(gè)心跳包，這個(gè)心跳包是服務(wù)器發(fā)送給客戶端的，用來判斷客戶端死沒死。如果你看過上面第一條，就會(huì)知道非持久化消息堆積到一定程度會(huì)寫到文件里，這個(gè)寫的過程會(huì)阻塞所有動(dòng)作，而且會(huì)持續(xù) 20 到 30 秒，并且隨著內(nèi)存的增大而增大。當(dāng)客戶端發(fā)完消息調(diào)用connection.close()時(shí)，會(huì)期待服務(wù)器對(duì)于關(guān)閉連接的回答，如果超過 15 秒沒回答就直接調(diào)用 socket 層的 close 關(guān)閉 tcp 連接了。這時(shí)客戶端發(fā)出的消息其實(shí)還在服務(wù)器的緩存里等待處理，不過由于服務(wù)器心跳包的設(shè)置，導(dǎo)致發(fā)生了 java.net.SocketException 異常，把緩存里的數(shù)據(jù)作廢了，沒處理的消息全部丟失。

解決方案：用持久化消息，或者非持久化消息及時(shí)處理不要堆積，或者啟動(dòng)事務(wù)，啟動(dòng)事務(wù)后，

commit()方法會(huì)負(fù)責(zé)任的等待服務(wù)器的返回，也就不會(huì)關(guān)閉連接導(dǎo)致消息丟失了。

4.持久化消息非常慢。

默認(rèn)的情況下，非持久化的消息是異步發(fā)送的，持久化的消息是同步發(fā)送的，遇到慢一點(diǎn)的硬盤，發(fā)送消息的速度是無(wú)法忍受的。但是在開啟事務(wù)的情況下，消息都是異步發(fā)送的，效率會(huì)有 2 個(gè)數(shù)量級(jí)的提升。所以在發(fā)送持久化消息時(shí)，請(qǐng)務(wù)必開啟事務(wù)模式。其實(shí)發(fā)送非持久化消息時(shí)也建議開啟事務(wù)，因?yàn)楦静粫?huì)影響性能。

5.消息的不均勻消費(fèi)。

有時(shí)在發(fā)送一些消息之后，開啟 2 個(gè)消費(fèi)者去處理消息。會(huì)發(fā)現(xiàn)一個(gè)消費(fèi)者處理了所有的消息，另一個(gè)消費(fèi)者根本沒收到消息。原因在于 ActiveMQ 的 prefetch 機(jī)制。當(dāng)消費(fèi)者去獲取消息時(shí)，不會(huì)一條一條去獲取，而是一次性獲取一批，默認(rèn)是 1000 條。這些預(yù)獲取的消息，在還沒確認(rèn)消費(fèi)之前，在管理控制臺(tái)還是可以看見這些消息的，但是不會(huì)再分配給其他消費(fèi)者，此時(shí)這些消息的狀態(tài)應(yīng)該算作“已分配未消 費(fèi)”，如果消息最后被消費(fèi)，則會(huì)在服務(wù)器端被刪除，如果消費(fèi)者崩潰，則這些消息會(huì)被重新分配給新的消費(fèi)者。但是如果消費(fèi)者既不消費(fèi)確認(rèn)，又不崩潰，那這些消息就永遠(yuǎn)躺在消費(fèi)者的緩存區(qū)里無(wú)法處理。更通常的情況是，消費(fèi)這些消息非常耗時(shí)，你開了 10 個(gè)消費(fèi)者去處理，結(jié)果發(fā)現(xiàn)只有一臺(tái)機(jī)器吭哧吭哧

處理，另外 9 臺(tái)啥事不干。

解決方案：將 prefetch 設(shè)為 1，每次處理 1 條消息，處理完再去取，這樣也慢不了多少。

6.死信隊(duì)列。

如果你想在消息處理失敗后，不被服務(wù)器刪除，還能被其他消費(fèi)者處理或重試，可以關(guān)閉AUTO_ACKNOWLEDGE，將 ack 交由程序自己處理。那如果使用了 AUTO_ACKNOWLEDGE，消息是什么時(shí)候被確認(rèn)的，還有沒有阻止消息確認(rèn)的方法？有！

消費(fèi)消息有 2 種方法，一種是調(diào)用 consumer.receive()方法，該方法將阻塞直到獲得并返回一條消息。這種情況下，消息返回給方法調(diào)用者之后就自動(dòng)被確認(rèn)了。另一種方法是采用 listener 回調(diào)函數(shù)，在有消息到達(dá)時(shí)，會(huì)調(diào)用 listener 接口的 onMessage 方法。在這種情況下，在 onMessage 方法執(zhí)行完畢后， 消息才會(huì)被確認(rèn)，此時(shí)只要在方法中拋出異常，該消息就不會(huì)被確認(rèn)。那么問題來了，如果一條消息不能被處理，會(huì)被退回服務(wù)器重新分配，如果只有一個(gè)消費(fèi)者，該消息又會(huì)重新被獲取，重新拋異常。就算有多個(gè)消費(fèi)者，往往在一個(gè)服務(wù)器上不能處理的消息，在另外的服務(wù)器上依然不能被處理。難道就這么退回

–獲取–報(bào)錯(cuò)死循環(huán)了嗎？

在重試 6 次后，ActiveMQ 認(rèn)為這條消息是“有毒”的，將會(huì)把消息丟到死信隊(duì)列里。如果你的消息不見了，去 ActiveMQ.DLQ 里找找，說不定就躺在那里。

Kafka消息中間件系列

1.Kafka 的設(shè)計(jì)時(shí)什么樣的呢？

Kafka 將消息以 topic 為單位進(jìn)行歸納

將向 Kafka topic 發(fā)布消息的程序成為 producers.

將預(yù)訂 topics 并消費(fèi)消息的程序成為 consumer.

Kafka 以集群的方式運(yùn)行，可以由一個(gè)或多個(gè)服務(wù)組成，每個(gè)服務(wù)叫做一個(gè) broker. producers 通過網(wǎng)絡(luò)將消息發(fā)送到 Kafka 集群，集群向消費(fèi)者提供消息

2.數(shù)據(jù)傳輸?shù)氖挛锒x有哪三種？

數(shù)據(jù)傳輸?shù)氖聞?wù)定義通常有以下三種級(jí)別：

（1）最多一次: 消息不會(huì)被重復(fù)發(fā)送，最多被傳輸一次，但也有可能一次不傳輸

（2）最少一次: 消息不會(huì)被漏發(fā)送，最少被傳輸一次，但也有可能被重復(fù)傳輸.

（3）精確的一次（Exactly once）:不會(huì)漏傳輸也不會(huì)重復(fù)傳輸,每個(gè)消息都傳輸被一次而且僅僅被傳輸一次，這是大家所期望的

3.Kafka 判斷一個(gè)節(jié)點(diǎn)是否還活著有那兩個(gè)條件？

（1）節(jié)點(diǎn)必須可以維護(hù)和 ZooKeeper 的連接，Zookeeper 通過心跳機(jī)制檢查每個(gè)節(jié)點(diǎn)的連接

（2）如果節(jié)點(diǎn)是個(gè) follower,他必須能及時(shí)的同步 leader 的寫操作，延時(shí)不能太久

4.producer 是否直接將數(shù)據(jù)發(fā)送到 broker 的 leader(主節(jié)點(diǎn))？

producer 直接將數(shù)據(jù)發(fā)送到 broker 的 leader(主節(jié)點(diǎn))，不需要在多個(gè)節(jié)點(diǎn)進(jìn)行分發(fā)，為了幫助 producer 做到這點(diǎn)，所有的 Kafka 節(jié)點(diǎn)都可以及時(shí)的告知:哪些節(jié)點(diǎn)是活動(dòng)的，目標(biāo)topic 目標(biāo)分區(qū)的 leader 在哪。這樣 producer 就可以直接將消息發(fā)送到目的地了

5、Kafa consumer 是否可以消費(fèi)指定分區(qū)消息？

Kafaconsumer 消費(fèi)消息時(shí)，向 broker 發(fā)出"fetch"請(qǐng)求去消費(fèi)特定分區(qū)的消息，consumer 指定消息在日志中的偏移量（offset），就可以消費(fèi)從這個(gè)位置開始的消息，customer 擁有了 offset 的控制權(quán)，可以向后回滾去重新消費(fèi)之前的消息，這是很有意義的

6、Kafka 消息是采用 Pull 模式，還是 Push 模式？

Kafka 最初考慮的問題是，customer 應(yīng)該從 brokes 拉取消息還是 brokers 將消息推送到consumer，也就是 pull 還 push。在這方面，Kafka 遵循了一種大部分消息系統(tǒng)共同的傳統(tǒng)的設(shè)計(jì)：producer 將消息推送到 broker，consumer 從 broker 拉取消息

一些消息系統(tǒng)比如 Scribe 和 ApacheFlume 采用了 push 模式，將消息推送到下游的consumer。這樣做有好處也有壞處：由 broker 決定消息推送的速率，對(duì)于不同消費(fèi)速率的consumer 就不太好處理了。消息系統(tǒng)都致力于讓 consumer 以大的速率最快速的消費(fèi)消息，但不幸的是，push 模式下，當(dāng) broker 推送的速率遠(yuǎn)大于 consumer 消費(fèi)的速率時(shí)， consumer 恐怕就要崩潰了。最終 Kafka 還是選取了傳統(tǒng)的 pull 模式

Pull 模式的另外一個(gè)好處是 consumer 可以自主決定是否批量的從 broker 拉取數(shù)據(jù)。Push 模式必須在不知道下游 consumer 消費(fèi)能力和消費(fèi)策略的情況下決定是立即推送每條消息還是緩存之后批量推送。如果為了避免 consumer 崩潰而采用較低的推送速率，將可能導(dǎo)致一次只推送較少的消息而造成浪費(fèi)。Pull 模式下，consumer 就可以根據(jù)自己的消費(fèi)能力去決

定這些策略

Pull 有個(gè)缺點(diǎn)是，如果 broker 沒有可供消費(fèi)的消息，將導(dǎo)致 consumer 不斷在循環(huán)中輪詢， 直到新消息到 t 達(dá)。為了避免這點(diǎn)，Kafka 有個(gè)參數(shù)可以讓 consumer 阻塞知道新消息到達(dá)(當(dāng)然也可以阻塞知道消息的數(shù)量達(dá)到某個(gè)特定的量這樣就可以批量發(fā)

7.Kafka 的消費(fèi)者如何消費(fèi)數(shù)據(jù)

消費(fèi)者每次消費(fèi)數(shù)據(jù)的時(shí)候，消費(fèi)者都會(huì)記錄消費(fèi)的物理偏移量（offset）的位置等到下次消費(fèi)時(shí)，他會(huì)接著上次位置繼續(xù)消費(fèi)

8.消費(fèi)者負(fù)載均衡策略

一個(gè)消費(fèi)者組中的一個(gè)分片對(duì)應(yīng)一個(gè)消費(fèi)者成員，他能保證每個(gè)消費(fèi)者成員都能訪問，如果組中成員太多會(huì)有空閑的成員

9.數(shù)據(jù)有序

一個(gè)消費(fèi)者組里它的內(nèi)部是有序的消費(fèi)者組與消費(fèi)者組之間是無(wú)序的

10.kafaka 生產(chǎn)數(shù)據(jù)時(shí)數(shù)據(jù)的分組策略

生產(chǎn)者決定數(shù)據(jù)產(chǎn)生到集群的哪個(gè) partition 中每一條消息都是以（key，value）格式

Key 是由生產(chǎn)者發(fā)送數(shù)據(jù)傳入

所以生產(chǎn)者（key）決定了數(shù)據(jù)產(chǎn)生到集群的哪個(gè) partition

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

網(wǎng)頁(yè)題目：消息中間件面試題31道RabbitMQ+ActiveMQ+Kafka-創(chuàng)新互聯(lián)
標(biāo)題鏈接：http://muchs.cn/article28/djgicp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站制作、域名注冊(cè)、定制開發(fā)、Google、定制網(wǎng)站、動(dòng)態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)