本文是根據(jù)平時(shí)面試以及網(wǎng)上資源進(jìn)行的整理。希望對(duì)小伙伴們面試有幫助。
消息隊(duì)列的作用和使用場(chǎng)景
通過異步處理提高響應(yīng)時(shí)間，削峰填谷：
場(chǎng)景：數(shù)據(jù)比較集中且實(shí)時(shí)要求不是太高逗载，如果同步處理，假如業(yè)務(wù)高峰需要4臺(tái)服務(wù)支撐链烈，那么在業(yè)務(wù)高峰過了之后厉斟，就會(huì)出現(xiàn)資源閑置，如果引入消息隊(duì)列的話强衡，將數(shù)據(jù)放到消息隊(duì)列后直接返回成功擦秽，提升了響應(yīng)時(shí)間，真正的業(yè)務(wù)在消息隊(duì)列后面消費(fèi)處理，可能2臺(tái)服務(wù)就能夠支撐的住感挥，而且流量更加均勻缩搅。
降低系統(tǒng)間的耦合度：
場(chǎng)景：數(shù)據(jù)不止一方依賴，可能多個(gè)系統(tǒng)都需要這份數(shù)據(jù)触幼，如果由發(fā)送方直接調(diào)用硼瓣，那么如果新增業(yè)務(wù)也依賴數(shù)據(jù)，就得修改發(fā)送方代碼置谦；使用消息隊(duì)列的話堂鲤，將發(fā)送方和接收方解耦，發(fā)送方將數(shù)據(jù)扔到消息隊(duì)列媒峡，依賴方可根據(jù)需求消費(fèi)處理瘟栖。
使用消息隊(duì)列會(huì)帶來哪些問題？
系統(tǒng)復(fù)雜度提高丝蹭，可用性降低慢宗，不僅需要考慮消息隊(duì)列的可用性坪蚁，還要考慮數(shù)據(jù)的一致性
如何做的消息隊(duì)列選型奔穿，為什么選擇kafka？
kafka和rocketmq吞吐量可達(dá)百萬級(jí)敏晤，比activemq贱田、rabbitmq要高一個(gè)數(shù)量級(jí)
kafka和rocketmq都是分布式架構(gòu)，高可用
kafka和rocketmq都是毫秒級(jí)低延時(shí)嘴脾，rocketmq甚至到微秒級(jí)
rocketmq不支持隊(duì)列層面的廣播男摧，kafka的consumer group支持組間廣播，組內(nèi)負(fù)載均衡
kafka可能會(huì)產(chǎn)生消息重復(fù)译打，業(yè)務(wù)做好冪等
kafka相關(guān)概念與消費(fèi)模型
broker：kafka集群中的一個(gè)節(jié)點(diǎn)
topic：主題是kafka的邏輯上的隊(duì)列
partition：一個(gè)topic可以包含一個(gè)或多個(gè)partition耗拓，每個(gè)partition的消息數(shù)據(jù)都是單獨(dú)存儲(chǔ)的，offset也是單獨(dú)維護(hù)的奏司，partition內(nèi)部消息有序
partition復(fù)制因子：一個(gè)topic的所有分區(qū)會(huì)分布到各個(gè)broker上乔询，允許設(shè)置復(fù)制因子使分區(qū)可以在其他節(jié)點(diǎn)上留存?zhèn)浞荩谥鞣謪^(qū)所在broker宕機(jī)時(shí)韵洋，可以作為新的主分區(qū)繼續(xù)提供服務(wù)
consumer group：一個(gè)topic可以有消費(fèi)者組消費(fèi)消息竿刁，kafka為每個(gè)消費(fèi)者組單獨(dú)管理每個(gè)分區(qū)的消費(fèi)偏移量offset，消費(fèi)者組間是廣播模式搪缨，對(duì)于一個(gè)消費(fèi)者組內(nèi)是負(fù)載均衡食拜，即一條消息可以被多個(gè)消費(fèi)者組消費(fèi)，只能被一個(gè)消費(fèi)者組內(nèi)的其中一個(gè)消費(fèi)者消費(fèi)副编；消費(fèi)者組內(nèi)的每個(gè)成員負(fù)責(zé)一定數(shù)量的分區(qū)负甸，當(dāng)消費(fèi)者組內(nèi)的消費(fèi)者發(fā)生變動(dòng)時(shí)，會(huì)觸發(fā)分區(qū)的重平衡
pull消費(fèi)模型：消費(fèi)者向負(fù)責(zé)分區(qū)主動(dòng)拉取消息，分區(qū)的消費(fèi)偏移量通過一個(gè)默認(rèn)的topic來記錄呻待，也可以顯示指定
pull模型的優(yōu)點(diǎn)：
消費(fèi)速度可以由消費(fèi)者自由控制
逐條消費(fèi)或者批量消費(fèi)可以由消費(fèi)者自由控制
broker設(shè)計(jì)更簡(jiǎn)單
kafka的消息存儲(chǔ)
kafka的消息存儲(chǔ)在磁盤上煮盼，一個(gè)kafka topic分為一個(gè)或多個(gè)partition，每個(gè)partition單獨(dú)存儲(chǔ)自己的消息數(shù)據(jù)
partition將數(shù)據(jù)記錄到.log文件中带污，為了避免文件過大影響查詢效率僵控，將文件分段處理
記錄消息到.log文件中的同時(shí)，會(huì)記錄消息offset和物理偏移地址的映射作為索引鱼冀，提升查找性能报破；
這個(gè)索引并不是按消息的順序依次記錄的，而是每隔一定字節(jié)的數(shù)據(jù)記錄一條索引千绪，降低了索引文件的大小
kafka查找消息時(shí)充易，只需要根據(jù)文件名和offset進(jìn)行二分查找，找到對(duì)應(yīng)的日志分段后荸型，查找.index文件找到物理偏移地址盹靴，然后查.log讀取消息內(nèi)容
消費(fèi)組與分區(qū)重平衡
當(dāng)有新的消費(fèi)者加入到消費(fèi)者組時(shí)，原本的分區(qū)就需要重新分配瑞妇；比如一個(gè)topic有30個(gè)分區(qū)稿静，原本只有兩個(gè)消費(fèi)者，每人負(fù)責(zé)15個(gè)分區(qū)辕狰，當(dāng)新加入一個(gè)消費(fèi)者時(shí)改备，并沒有分區(qū)可以給他消費(fèi)，只能是將30個(gè)分區(qū)重新分配蔓倍。
每個(gè)消費(fèi)者組都會(huì)有一個(gè)broker負(fù)責(zé)協(xié)調(diào)（稱為group coordinator）悬钳，各個(gè)消費(fèi)者通過發(fā)送心跳的方式向組協(xié)調(diào)者同步狀態(tài)，當(dāng)有消費(fèi)者一定時(shí)間沒有給組協(xié)調(diào)者發(fā)送心跳或者有新的消費(fèi)者加入到消費(fèi)者組時(shí)偶翅，就會(huì)觸發(fā)消費(fèi)組的重平衡操作默勾。
新加入消費(fèi)者觸發(fā)重平衡：
1.新加入消費(fèi)者向組協(xié)調(diào)者發(fā)送joinGroup請(qǐng)求，攜帶訂閱的topic信息
2.此后組協(xié)調(diào)者收到組內(nèi)其他消費(fèi)者的心跳請(qǐng)求時(shí)聚谁，在響應(yīng)中告訴消費(fèi)者要重平衡
3.組內(nèi)原有消費(fèi)者會(huì)重新發(fā)送joinGroup請(qǐng)求到組協(xié)調(diào)者
4.組協(xié)調(diào)者根據(jù)發(fā)送joinGroup請(qǐng)求的先后選出消費(fèi)者leader母剥，將topic和分區(qū)信息響應(yīng)給各個(gè)消費(fèi)者
5.被選為leader的消費(fèi)者將分區(qū)分配好
6.各消費(fèi)者發(fā)送SyncGroup請(qǐng)求給組協(xié)調(diào)者請(qǐng)求新分配好的分區(qū)信息，其中消費(fèi)者leader會(huì)攜帶分配好的分區(qū)信息
7.組協(xié)調(diào)者將各個(gè)消費(fèi)者負(fù)責(zé)的分區(qū)信息響應(yīng)給消費(fèi)者垦巴，重平衡完成
消費(fèi)者主動(dòng)離開導(dǎo)致重平衡
1.消費(fèi)者發(fā)送leaveGroup請(qǐng)求給組協(xié)調(diào)者
2.此后組協(xié)調(diào)者收到組內(nèi)其他消費(fèi)者的心跳請(qǐng)求時(shí)媳搪，在響應(yīng)中告訴消費(fèi)者要重平衡
3.消費(fèi)者會(huì)重新發(fā)送joinGroup請(qǐng)求到組協(xié)調(diào)者
4.組協(xié)調(diào)者根據(jù)發(fā)送joinGroup請(qǐng)求的先后選出消費(fèi)者leader，將topic和分區(qū)信息響應(yīng)給各個(gè)消費(fèi)者
5.被選為leader的消費(fèi)者將分區(qū)分配好
6.各消費(fèi)者發(fā)送SyncGroup請(qǐng)求給組協(xié)調(diào)者請(qǐng)求新分配好的分區(qū)信息骤宣，其中消費(fèi)者leader會(huì)攜帶分配好的分區(qū)信息
7.組協(xié)調(diào)者將各個(gè)消費(fèi)者負(fù)責(zé)的分區(qū)信息響應(yīng)給消費(fèi)者秦爆，重平衡完成
消費(fèi)者失去心跳導(dǎo)致重平衡
1.消費(fèi)者一定時(shí)間內(nèi)沒有發(fā)送心跳信息給組協(xié)調(diào)者
2.此后組協(xié)調(diào)者收到組內(nèi)其他消費(fèi)者的心跳請(qǐng)求時(shí)，在響應(yīng)中告訴消費(fèi)者要重平衡
3.消費(fèi)者會(huì)重新發(fā)送joinGroup請(qǐng)求到組協(xié)調(diào)者
4.組協(xié)調(diào)者根據(jù)發(fā)送joinGroup請(qǐng)求的先后選出消費(fèi)者leader憔披，將topic和分區(qū)信息響應(yīng)給各個(gè)消費(fèi)者
5.被選為leader的消費(fèi)者將分區(qū)分配好
6.各消費(fèi)者發(fā)送SyncGroup請(qǐng)求給組協(xié)調(diào)者請(qǐng)求新分配好的分區(qū)信息等限，其中消費(fèi)者leader會(huì)攜帶分配好的分區(qū)信息
7.組協(xié)調(diào)者將各個(gè)消費(fèi)者負(fù)責(zé)的分區(qū)信息響應(yīng)給消費(fèi)者爸吮，重平衡完成
kafka如何保證不丟失消息？
復(fù)制因子：創(chuàng)建topic的時(shí)候指定復(fù)制因子大于1時(shí)望门，一個(gè)分區(qū)被分配到一個(gè)broker上形娇，同時(shí)會(huì)在其他broker上維護(hù)一個(gè)分區(qū)副本；
isr列表：分區(qū)及其副本分別為leader和follower筹误，leader對(duì)外提供讀寫服務(wù)桐早，follower會(huì)向leader發(fā)送同步請(qǐng)求，拉取最新的數(shù)據(jù)厨剪，如果follower和leader的消息差距保持在一定范圍之內(nèi)哄酝，那么這個(gè)follower在isr列表內(nèi)；當(dāng)分區(qū)leader所在broker宕機(jī)祷膳，會(huì)從isr列表中選舉一個(gè)follower作為新的leader提供服務(wù)
通過kafka的acks參數(shù)可以控制消息的發(fā)送行為陶衅，acks可選的值有0、1直晨、all搀军；當(dāng)設(shè)置為0時(shí)，生產(chǎn)者消息發(fā)送成功即為成功勇皇，不關(guān)心是否寫入到磁盤及后續(xù)操作罩句；當(dāng)設(shè)置為1時(shí)，消息發(fā)送到分區(qū)leader后寫入磁盤即為成功儒士；當(dāng)設(shè)置為all時(shí)的止，消息發(fā)送到分區(qū)leader并寫入磁盤后，同步給isr列表中的所有分區(qū)副本后即為成功
kafka高可用
broker啟動(dòng)會(huì)嘗試向zookeeper創(chuàng)建臨時(shí)節(jié)點(diǎn)：/controller着撩，第一個(gè)broker選舉成功成為集群的controller，其余節(jié)點(diǎn)都會(huì)在/controller注冊(cè)watcher監(jiān)控controller狀態(tài)匾委；當(dāng)controller掛掉拖叙，所有broker感知到，重新嘗試選舉controller
controller節(jié)點(diǎn)通過zookeeper監(jiān)控各broker狀態(tài)赂乐，如果由broker掛掉薯鳍，controller負(fù)責(zé)從其負(fù)責(zé)的leader分區(qū)的isr列表中選舉一個(gè)作為新的leader
kafka副本和leader選舉
kafka高性能原因
零拷貝、利用操作系統(tǒng)頁緩存挨措、磁盤順序?qū)?br>
kafka零拷貝原理
分區(qū)挖滤、分段、建立索引
生產(chǎn)者浅役、消費(fèi)者批處理
Kafka中的ISR斩松、AR又代表什么？ISR的伸縮又指什么
ISR:In-Sync Replicas 副本同步隊(duì)列
AR:Assigned Replicas 所有副本
ISR是由leader維護(hù)觉既，follower從leader同步數(shù)據(jù)有一些延遲（包括延遲時(shí)間replica.lag.time.max.ms和延遲條數(shù)replica.lag.max.messages兩個(gè)維度, 當(dāng)前最新的版本0.10.x中只支持replica.lag.time.max.ms這個(gè)維度）惧盹，任意一個(gè)超過閾值都會(huì)把follower剔除出ISR, 存入OSR（Outof-Sync Replicas）列表乳幸，新加入的follower也會(huì)先存放在OSR中。AR=ISR+OSR钧椰。
** Kafka中的HW粹断、LEO、LSO嫡霞、LW等分別代表什么瓶埋？**
HW:High Watermark 高水位，取一個(gè)partition對(duì)應(yīng)的ISR中最小的LEO作為HW诊沪，consumer最多只能消費(fèi)到HW所在的位置上一條信息
LEO:LogEndOffset 當(dāng)前日志文件中下一條待寫信息的offset
HW/LEO這兩個(gè)都是指最后一條的下一條的位置而不是指最后一條的位置
LSO:Last Stable Offset 對(duì)未完成的事務(wù)而言悬赏，LSO 的值等于事務(wù)中第一條消息的位置(firstUnstableOffset)，對(duì)已完成的事務(wù)而言娄徊，它的值同 HW 相同
LW:Low Watermark 低水位, 代表 AR 集合中最小的 logStartOffset 值
Kafka中是怎么體現(xiàn)消息順序性的闽颇？
kafka每個(gè)partition中的消息在寫入時(shí)都是有序的，消費(fèi)時(shí)寄锐，每個(gè)partition只能被每一個(gè)group中的一個(gè)消費(fèi)者消費(fèi)兵多，保證了消費(fèi)時(shí)也是有序的。
整個(gè)topic不保證有序橄仆。如果為了保證topic整個(gè)有序剩膘，那么將partition調(diào)整為1.
Kafka中的分區(qū)器、序列化器盆顾、攔截器是否了解怠褐？它們之間的處理順序是什么？
攔截器->序列化器->分區(qū)器
Kafka生產(chǎn)者客戶端的整體結(jié)構(gòu)是什么樣子的您宪？
Kafka生產(chǎn)者客戶端中使用了幾個(gè)線程來處理奈懒？分別是什么？
2個(gè)宪巨，主線程和Sender線程磷杏。主線程負(fù)責(zé)創(chuàng)建消息，然后通過分區(qū)器捏卓、序列化器极祸、攔截器作用之后緩存到累加器RecordAccumulator中。Sender線程負(fù)責(zé)將RecordAccumulator中消息發(fā)送到kafka中.
Kafka的舊版Scala的消費(fèi)者客戶端的設(shè)計(jì)有什么缺陷怠晴？
消費(fèi)組中的消費(fèi)者個(gè)數(shù)如果超過topic的分區(qū)遥金，那么就會(huì)有消費(fèi)者消費(fèi)不到數(shù)據(jù)”這句話是否正確？如果不正確蒜田，那么有沒有什么hack的手段稿械？
不正確，通過自定義分區(qū)分配策略物邑，可以將一個(gè)consumer指定消費(fèi)所有partition溜哮。
消費(fèi)者提交消費(fèi)位移時(shí)提交的是當(dāng)前消費(fèi)到的最新消息的offset還是offset+1?
offset+1
有哪些情形會(huì)造成重復(fù)消費(fèi)滔金？
消費(fèi)者消費(fèi)后沒有commit offset(程序崩潰/強(qiáng)行kill/消費(fèi)耗時(shí)/自動(dòng)提交偏移情況下unscrible)
那些情景下會(huì)造成消息漏消費(fèi)？
消費(fèi)者沒有處理完消息 提交offset(自動(dòng)提交偏移 未處理情況下程序異常結(jié)束)
KafkaConsumer是非線程安全的茂嗓，那么怎么樣實(shí)現(xiàn)多線程消費(fèi)餐茵？
1.在每個(gè)線程中新建一個(gè)KafkaConsumer
2.單線程創(chuàng)建KafkaConsumer忿族，多個(gè)處理線程處理消息（難點(diǎn)在于是否要考慮消息順序性道批，offset的提交方式）
簡(jiǎn)述消費(fèi)者與消費(fèi)組之間的關(guān)系
消費(fèi)者從屬與消費(fèi)組入撒，消費(fèi)偏移以消費(fèi)組為單位。每個(gè)消費(fèi)組可以獨(dú)立消費(fèi)主題的所有數(shù)據(jù)璃赡，同一消費(fèi)組內(nèi)消費(fèi)者共同消費(fèi)主題數(shù)據(jù)碉考，每個(gè)分區(qū)只能被同一消費(fèi)組內(nèi)一個(gè)消費(fèi)者消費(fèi)挺身。
當(dāng)你使用kafka-topics.sh創(chuàng)建（刪除）了一個(gè)topic之后，Kafka背后會(huì)執(zhí)行什么邏輯墙贱？
創(chuàng)建:在zk上/brokers/topics/下節(jié)點(diǎn) kafkabroker會(huì)監(jiān)聽節(jié)點(diǎn)變化創(chuàng)建主題
刪除:調(diào)用腳本刪除topic會(huì)在zk上將topic設(shè)置待刪除標(biāo)志嫩痰，kafka后臺(tái)有定時(shí)的線程會(huì)掃描所有需要?jiǎng)h除的topic進(jìn)行刪除
topic的分區(qū)數(shù)可不可以增加窍箍？如果可以怎么增加椰棘？如果不可以榄笙，那又是為什么茅撞？
可以
topic的分區(qū)數(shù)可不可以減少巨朦？如果可以怎么減少糊啡？如果不可以棚蓄，那又是為什么碍脏？
不可以
創(chuàng)建topic時(shí)如何選擇合適的分區(qū)數(shù)？
根據(jù)集群的機(jī)器數(shù)量和需要的吞吐量來決定適合的分區(qū)數(shù)
Kafka目前有那些內(nèi)部topic典尾，它們都有什么特征役拴？各自的作用又是什么河闰？
consumer_offsets 以下劃線開頭勃教，保存消費(fèi)組的偏移
優(yōu)先副本是什么故源？它有什么特殊的作用？
優(yōu)先副本 會(huì)是默認(rèn)的leader副本 發(fā)生leader變化時(shí)重選舉會(huì)優(yōu)先選擇優(yōu)先副本作為leader
Kafka有哪幾處地方有分區(qū)分配的概念印机？簡(jiǎn)述大致的過程及原理
創(chuàng)建主題時(shí)
如果不手動(dòng)指定分配方式 有兩種分配方式
消費(fèi)組內(nèi)分配
簡(jiǎn)述Kafka的日志目錄結(jié)構(gòu)
每個(gè)partition一個(gè)文件夾射赛，包含四類文件.index .log .timeindex leader-epoch-checkpoint
.index .log .timeindex 三個(gè)文件成對(duì)出現(xiàn) 前綴為上一個(gè)segment的最后一個(gè)消息的偏移 log文件中保存了所有的消息 index文件中保存了稀疏的相對(duì)偏移的索引 timeindex保存的則是時(shí)間索引
leader-epoch-checkpoint中保存了每一任leader開始寫入消息時(shí)的offset 會(huì)定時(shí)更新
follower被選為leader時(shí)會(huì)根據(jù)這個(gè)確定哪些消息可用
Kafka中有那些索引文件奶是？
如上
如果我指定了一個(gè)offset聂沙，Kafka怎么查找到對(duì)應(yīng)的消息？
1.通過文件名前綴數(shù)字x找到該絕對(duì)offset 對(duì)應(yīng)消息所在文件
2.offset-x為在文件中的相對(duì)偏移
3.通過index文件中記錄的索引找到最近的消息的位置
4.從最近位置開始逐條尋找
如果我指定了一個(gè)timestamp沮趣，Kafka怎么查找到對(duì)應(yīng)的消息房铭？
原理同上 但是時(shí)間的因?yàn)橄Ⅲw中不帶有時(shí)間戳 所以不精確
聊一聊你對(duì)Kafka的Log Retention的理解
kafka留存策略包括 刪除和壓縮兩種
刪除: 根據(jù)時(shí)間和大小兩個(gè)方式進(jìn)行刪除 大小是整個(gè)partition日志文件的大小
超過的會(huì)從老到新依次刪除 時(shí)間指日志文件中的最大時(shí)間戳而非文件的最后修改時(shí)間
壓縮: 相同key的value只保存一個(gè) 壓縮過的是clean 未壓縮的dirty 壓縮之后的偏移量不連續(xù) 未壓縮時(shí)連續(xù)
聊一聊你對(duì)Kafka的Log Compaction的理解
聊一聊你對(duì)Kafka底層存儲(chǔ)的理解（頁緩存、內(nèi)核層翁狐、塊層谴蔑、設(shè)備層）
聊一聊Kafka的延時(shí)操作的原理
聊一聊Kafka控制器的作用
消費(fèi)再均衡的原理是什么龟梦？（提示：消費(fèi)者協(xié)調(diào)器和消費(fèi)組協(xié)調(diào)器）
Kafka中的冪等是怎么實(shí)現(xiàn)的
pid+序號(hào)實(shí)現(xiàn)，單個(gè)producer內(nèi)冪等
Kafka中的事務(wù)是怎么實(shí)現(xiàn)的（這題我去面試6家被問4次钦睡，照著答案念也要念十幾分鐘荞怒，面試官簡(jiǎn)直湊不要臉褐桌。實(shí)在記不住的話…只要簡(jiǎn)歷上不寫精通Kafka一般不會(huì)問到荧嵌，我簡(jiǎn)歷上寫的是“熟悉Kafka啦撮，了解RabbitMQ….”）
Kafka中有那些地方需要選舉汪厨？這些地方的選舉策略又有哪些劫乱？
失效副本是指什么？有那些應(yīng)對(duì)措施抠璃？
多副本下，各個(gè)副本中的HW和LEO的演變過程
為什么Kafka不支持讀寫分離拉一？
Kafka在可靠性方面做了哪些改進(jìn)？（HW, LeaderEpoch）
Kafka中怎么實(shí)現(xiàn)死信隊(duì)列和重試隊(duì)列蔚润？
Kafka中的延遲隊(duì)列怎么實(shí)現(xiàn)（這題被問的比事務(wù)那題還要多５站馈！叉橱！聽說你會(huì)Kafka窃祝，那你說說延遲隊(duì)列怎么實(shí)現(xiàn)踱侣？）
Kafka中怎么做消息審計(jì)？
Kafka中怎么做消息軌跡抡句？
Kafka中有那些配置參數(shù)比較有意思待榔？聊一聊你的看法
Kafka中有那些命名比較有意思？聊一聊你的看法
Kafka有哪些指標(biāo)需要著重關(guān)注猾担？
生產(chǎn)者關(guān)注MessagesInPerSec绑嘹、BytesOutPerSec工腋、BytesInPerSec 消費(fèi)者關(guān)注消費(fèi)延遲Lag
怎么計(jì)算Lag畅卓？(注意read_uncommitted和read_committed狀態(tài)下的不同)
參考 如何監(jiān)控kafka消費(fèi)Lag情況
Kafka的那些設(shè)計(jì)讓它有如此高的性能翁潘？
零拷貝，頁緩存渗勘，順序?qū)?/p>
Kafka有什么優(yōu)缺點(diǎn)旺坠？
還用過什么同質(zhì)類的其它產(chǎn)品取刃，與Kafka相比有什么優(yōu)缺點(diǎn)璧疗？
為什么選擇Kafka?
吞吐量高，大數(shù)據(jù)消息系統(tǒng)唯一選擇濒翻。
在使用Kafka的過程中遇到過什么困難有送？怎么解決的雀摘？
怎么樣才能確保Kafka極大程度上的可靠性八拱？
關(guān)注我的公眾號(hào)，后臺(tái)回復(fù)【JAVAPDF】獲取200頁面試題肌稻！
5萬人關(guān)注的大數(shù)據(jù)成神之路爹谭，不來了解一下嗎诺凡？
5萬人關(guān)注的大數(shù)據(jù)成神之路东揣，真的不來了解一下嗎嘶卧？
5萬人關(guān)注的大數(shù)據(jù)成神之路芥吟，確定真的不來了解一下嗎？
