摘要
目前來說市面上可以選擇的消息隊列非常多，像activemq奶陈，rabbitmq抛猫，zeromq已經(jīng)被大多數(shù)人耳熟能詳贼陶，特別像activemq早期應(yīng)用在企業(yè)中的總線通信刃泡，基本作為企業(yè)級IT設(shè)施解決方案中不可或缺的一部分。目前來說Kafka已經(jīng)非常穩(wěn)定碉怔，并且逐步應(yīng)用更加廣泛烘贴，已經(jīng)算不得新生事物，但是不可否認(rèn)Kafka一枝獨(dú)秀如同雨后春筍撮胧，非常耀眼桨踪，今天我們仔細(xì)分解一下Kafka，了解一下它的內(nèi)幕芹啥。以下的內(nèi)容版本基于當(dāng)前最新的Kafka穩(wěn)定版本2.4.0锻离。文章主要包含以下內(nèi)容：
- Kafka為什么快
- Kafka為什么穩(wěn)
- Kafka該怎么用
該文章為開篇引導(dǎo)之做，后續(xù)會有對應(yīng)的HBase墓怀，Spark汽纠，Kylin，Pulsar等相關(guān)組件的剖析傀履。
Kafka為什么快
快是一個相對概念虱朵，沒有對比就沒有傷害，因此通常我們說Kafka是相對于我們常見的activemq钓账，rabbitmq這類會發(fā)生IO因妇，并且主要依托于IO來做信息傳遞的消息隊列景殷，像zeromq這種基本純粹依靠內(nèi)存做信息流傳遞的消息隊列，當(dāng)然會更快，但是此類消息隊列只有特殊場景下會使用北专，不在對比之列。
因此當(dāng)我們說Kakfa快的時候绎狭，通常是基于以下場景：
- 吞吐量：當(dāng)我們需要每秒處理幾十萬上百萬message的時候灌侣，相對其他MQ，Kafka處理的更快卖陵。
- 高并發(fā)：當(dāng)具有百萬以及千萬的consumer的時候遭顶，同等配置的機(jī)器下，Kafka所擁有的Producer和Consumer會更多泪蔫。
- 磁盤鎖：相對其他MQ棒旗，Kafka在進(jìn)行IO操作的時候，其同步鎖住IO的場景更少，發(fā)生等待的時間更短铣揉。
那么基于以上幾點(diǎn)饶深，我們來仔細(xì)探討一下，為什么Kafka就快了逛拱。
消息隊列的推拉模型
首先敌厘，如果我們單純站在Consumer的角度來看“Kafka快”，是一個偽命題朽合，因為相比其他MQ俱两，Kafka從Producer產(chǎn)生一條Message到Consumer消費(fèi)這條Message來看它的時間一定是大于等于其他MQ的，背后的原因涉及到消息隊列設(shè)計的兩種模型：推模型和拉模型曹步，如下圖所示：
對于拉模型來說宪彩，Producer產(chǎn)生Message后，會主動發(fā)送給MQ Server讲婚，為了提升性能和減少開支尿孔，部分Client還會設(shè)計成批量發(fā)送，但是無論是單條還是批量筹麸，Producer都會主動推送消息到MQ Server活合，當(dāng)MQ Server接收到消息后，對于拉模型物赶，MQ Server不會主動發(fā)送消息到Consumer芜辕，同時也不會維持和記錄消息的offset，Consumer會自動設(shè)置定時器到服務(wù)端去詢問是否有新的消息產(chǎn)生块差，通常時間是不超過100ms詢問一次侵续，一旦產(chǎn)生新的消息則會同步到本地，并且修改和記錄offset憨闰，服務(wù)端可以輔助存儲offset状蜗，但是不會主動記錄和校驗offset的合理性，同時Consumer可以完全自主的維護(hù)offset以便實(shí)現(xiàn)自定義的信息讀取鹉动。
對于推模型來說轧坎，服務(wù)端收到Message后，首先會記錄消息的信息泽示，并且從自己的元信息數(shù)據(jù)庫中查詢對應(yīng)的消息的Consumer有誰缸血，由于服務(wù)器和Consumer在鏈接的時候建立了長鏈接，因此可以直接發(fā)送消息到Consumer械筛。
Kafka是基于拉模型的消息隊列捎泻，因此從Consumer獲取消息的角度來說，延遲會小于等于輪詢的周期埋哟，所以會比推模型的消息隊列具有更高的消息獲取延遲笆豁，但是推模型同樣又其問題。首先，由于服務(wù)器需要記錄對應(yīng)的Consumer的元信息闯狱，包括消息該發(fā)給誰煞赢，offset是多少，同時需要向Consumer推送消息哄孤，必然會帶來系列的問題：假如這一刻網(wǎng)絡(luò)不好照筑，Consumer沒有收到，消息沒有發(fā)成功怎么辦瘦陈？假設(shè)消息發(fā)出去了凝危，我怎么知道它有沒有收到？因此服務(wù)器和Consumer之間需要首先多層確認(rèn)口令双饥，以達(dá)到至少消費(fèi)一次，僅且消費(fèi)一次等特性弟断。
Kafka此類的拉模型將這一塊功能都交由Consumer自動維護(hù)咏花，因此服務(wù)器減少了更多的不必要的開支，因此從同等資源的角度來講阀趴，Kafka具備鏈接的Producer和Consumer將會更多昏翰，極大的降低了消息堵塞的情況，因此看起來更快了刘急。
OS Page Cache和Buffer Cache
太陽底下無新鮮事棚菊，對于一個框架來說，要想運(yùn)行的更快叔汁，通常能用的手段也就那么幾招统求，Kafka在將這一招用到了極致，其中之一就是極大化的使用了OS的Cache据块，主要是Page Cache和Buffer Cache码邻。對于這兩個Cache，使用Linux的同學(xué)通常不會陌生另假，例如我們在Linux下執(zhí)行free命令的時候會看到如下的輸出：
（圖片來自網(wǎng)絡(luò)）
會有兩列名為buffers和cached像屋，也有一行名為“-/+ buffers/cache”。這兩個信息的具體解釋如下：
pagecache：文件系統(tǒng)層級的緩存边篮，從磁盤里讀取的內(nèi)容是存儲到這里己莺，這樣程序讀取磁盤內(nèi)容就會非常快戈轿，比如使用Linux的grep和find等命令查找內(nèi)容和文件時凌受，第一次會慢很多，再次執(zhí)行就快好多倍思杯，幾乎是瞬間胁艰。另外page cache的數(shù)據(jù)被修改過后，也即臟數(shù)據(jù)，等到寫入磁盤時機(jī)到來時腾么，會轉(zhuǎn)移到buffer cache 而不是直接寫入到磁盤奈梳。我們看到的cached這列的數(shù)值表示的是當(dāng)前的頁緩存（page cache）的占用量，page cache文件的頁數(shù)據(jù)解虱，頁是邏輯上的概念攘须，因此page cache是與文件系統(tǒng)同級的。
buffer cache：磁盤等塊設(shè)備的緩沖殴泰，內(nèi)存的這一部分是要寫入到磁盤里的 于宙。buffers列表示當(dāng)前的塊緩存（buffer cache）占用量，buffer cache用于緩存塊設(shè)備（如磁盤）的塊數(shù)據(jù)悍汛。塊是物理上的概念捞魁，因此buffer cache是與塊設(shè)備驅(qū)動程序同級的。
兩者都是用來加速數(shù)據(jù)IO离咐，將寫入的頁標(biāo)記為dirty谱俭，然后向外部存儲flush，讀數(shù)據(jù)時首先讀取緩存宵蛀，如果未命中昆著，再去外部存儲讀取，并且將讀取來的數(shù)據(jù)也加入緩存术陶。操作系統(tǒng)總是積極地將所有空閑內(nèi)存都用作page cache和buffer cache凑懂，當(dāng)os的內(nèi)存不夠用時也會用LRU等算法淘汰緩存頁。
有了以上概念后梧宫，我們再看來Kafka是怎么利用這個特性的接谨。首先，對于一次數(shù)據(jù)IO來說塘匣，通常會發(fā)生以下的流程：
- 操作系統(tǒng)將數(shù)據(jù)從磁盤拷貝到內(nèi)核區(qū)的pagecache
- 用戶程序?qū)?nèi)核區(qū)的pagecache拷貝到用戶區(qū)緩存
- 用戶程序?qū)⒂脩魠^(qū)的緩存拷貝到socket緩存中
- 操作系統(tǒng)將socket緩存中的數(shù)據(jù)拷貝到網(wǎng)卡的buffer上疤坝，發(fā)送數(shù)據(jù)
可以發(fā)現(xiàn)一次IO請求操作進(jìn)行了2次上下文切換和4次系統(tǒng)調(diào)用，而同一份數(shù)據(jù)在緩存中多次拷貝馆铁，實(shí)際上對于拷貝來說完全可以直接在內(nèi)核態(tài)中進(jìn)行跑揉，也就是省去第二和第三步驟，變成這樣：
正因為可以如此的修改數(shù)據(jù)的流程埠巨，于是Kafka在設(shè)計之初就參考此流程历谍，盡可能大的利用os的page cache來對數(shù)據(jù)進(jìn)行拷貝，盡量減少對磁盤的操作辣垒。如果kafka生產(chǎn)消費(fèi)配合的好望侈，那么數(shù)據(jù)完全走內(nèi)存，這對集群的吞吐量提升是很大的勋桶。早期的操作系統(tǒng)中的page cache和buffer cache是分開的兩塊cache脱衙，后來發(fā)現(xiàn)同樣的數(shù)據(jù)可能會被cache兩次侥猬，于是大部分情況下兩者都是合二為一的。
Kafka雖然使用JVM語言編寫捐韩，在運(yùn)行的時候脫離不了JVM和JVM的GC退唠，但是Kafka并未自己去管理緩存，而是直接使用了OS的page cache作為緩存荤胁，這樣做帶來了以下好處：
- JVM中的一切皆對象瞧预，所以無論對象的大小，總會有些額外的JVM的對象元數(shù)據(jù)浪費(fèi)空間仅政。
- JVM自己的GC不受程序手動控制垢油，所以如果使用JVM作為緩存，在遇到大對象或者頻繁GC的時候會降低整個系統(tǒng)的吞吐量圆丹。
- 程序異常退出或者重啟滩愁，所有的緩存都將失效，在容災(zāi)架構(gòu)下會影響快速恢復(fù)辫封。而page cache因為是os的cache硝枉，即便程序退出，緩存依舊存在秸讹。
所以Kafka優(yōu)化IO流程檀咙，充分利用page cache雅倒，其消耗的時間更短璃诀，吞吐量更高，相比其他MQ就更快了蔑匣，用一張圖來簡述三者之間的關(guān)系如下：
當(dāng)Producer和Consumer速率相差不大的情況下劣欢，Kafka幾乎可以完全實(shí)現(xiàn)不落盤就完成信息的傳輸。
追加順序?qū)懭?/h4>
除了前面的重要特性之外裁良，Kafka還有一個設(shè)計凿将，就是對數(shù)據(jù)的持久化存儲采用的順序的追加寫入，Kafka在將消息落到各個topic的partition文件時价脾，只是順序追加牧抵，充分的利用了磁盤順序訪問快的特性。
（圖片來自網(wǎng)絡(luò)）
Kafka的文件存儲按照topic下的partition來進(jìn)行存儲侨把，每一個partition有各自的序列文件犀变，各個partition的序列不共享，主要的劃分按照消息的key進(jìn)行hash決定落在哪個分區(qū)之上秋柄，我們先來詳細(xì)解釋一下Kafka的各個名詞获枝，以便充分理解其特點(diǎn)：
- broker：Kafka中用來處理消息的服務(wù)器，也是Kafka集群的一個節(jié)點(diǎn)骇笔，多個節(jié)點(diǎn)形成一個Kafka集群省店。
- topic：一個消息主題嚣崭，每一個業(yè)務(wù)系統(tǒng)或者Consumer需要訂閱一個或者多個主題來獲取消息，Producer需要明確發(fā)生消息對于的topic懦傍，等于信息傳遞的口令名稱雹舀。
- partition：一個topic會拆分成多個partition落地到磁盤，在kafka配置的存儲目錄下按照對應(yīng)的分區(qū)ID創(chuàng)建的文件夾進(jìn)行文件的存儲谎脯，磁盤可以見的最大的存儲單元葱跋。
- segment：一個partition會有多個segment文件來實(shí)際存儲內(nèi)容。
- offset：每一個partition有自己的獨(dú)立的序列編號源梭，作用域僅在當(dāng)前的partition之下娱俺，用來對對應(yīng)的文件內(nèi)容進(jìn)行讀取操作。
- leader：每一個topic需要有一個leader來負(fù)責(zé)該topic的信息的寫入废麻，數(shù)據(jù)一致性的維護(hù)荠卷。
- controller：每一個kafka集群會選擇出一個broker來充當(dāng)controller，負(fù)責(zé)決策每一個topic的leader是誰烛愧，監(jiān)聽集群broker信息的變化油宜，維持集群狀態(tài)的健康。
可以看到最終落地到磁盤都是Segment文件怜姿，每一個partion(目錄)相當(dāng)于一個巨型文件被平均分配到多個大小相等segment(段)數(shù)據(jù)文件中慎冤。但每個段segment file消息數(shù)量不一定相等，這種特性方便老的 segment file快速被刪除沧卢。因為Kafka處理消息的力度是到partition蚁堤，因此只需要保持好partition對應(yīng)的順序處理，segment可以單獨(dú)維護(hù)其狀態(tài)但狭。
segment的文件由index file和data file組成披诗，落地在磁盤的后綴為.index和.log，文件按照序列編號生成立磁，如下所示：
（圖片來自網(wǎng)絡(luò)）
其中index維持著數(shù)據(jù)的物理地址呈队，而data存儲著數(shù)據(jù)的偏移地址，相互關(guān)聯(lián)唱歧，這里看起來似乎和磁盤的順序?qū)懭腙P(guān)系不大宪摧，想想HDFS的塊存儲，每次申請固定大小的塊和這里的segment颅崩？是不是挺相似的几于？另外因為有index文的本身命名是以offset作為文件名的，在進(jìn)行查找的時候可以快速根據(jù)需要查找的offset定位到對應(yīng)的文件挨摸，再根據(jù)文件進(jìn)行內(nèi)容的檢索孩革。因此Kafka的查找流程為先根據(jù)要查找的offset對文件名稱進(jìn)行二分查找，找到對應(yīng)的文件得运，再根據(jù)index的元數(shù)據(jù)的物理地址和log文件的偏移位置結(jié)合順序讀區(qū)到對應(yīng)offset的位置的內(nèi)容即可膝蜈。
segment index file采取稀疏索引存儲方式锅移，它減少索引文件大小，通過mmap可以直接內(nèi)存操作饱搏，稀疏索引為數(shù)據(jù)文件的每個對應(yīng)message設(shè)置一個元數(shù)據(jù)指針,它比稠密索引節(jié)省了更多的存儲空間非剃，但查找起來需要消耗更多的時間，特別是在隨機(jī)讀取的場景下推沸，Kafka非常不合適备绽。所以因為Kafka特殊的存儲設(shè)計，也讓Kafka感覺起來鬓催，更快肺素。
Kafka為什么穩(wěn)
前面提到Kafka為什么快，除了快的特性之外宇驾，Kafka還有其他特點(diǎn)倍靡，那就是：穩(wěn)。Kafka的穩(wěn)體現(xiàn)在幾個維度：
- 數(shù)據(jù)安全课舍，幾乎不會丟數(shù)據(jù)塌西。
- 集群安全，發(fā)生故障幾乎可以Consumer無感知切換筝尾。
- 可用性強(qiáng)捡需，即便部分partition不可用，剩余的partition的數(shù)據(jù)依舊不影響讀取筹淫。
- 流控限制站辉，避免大量Consumer拖垮服務(wù)器的帶寬。
限流機(jī)制
對于Kafka的穩(wěn)贸街，通常是由其整體架構(gòu)設(shè)計決定庵寞，很多優(yōu)秀的特性結(jié)合在一起狸相，就更加的優(yōu)秀薛匪，像Kafka的Qutota就是其中一個，既然是限流脓鹃，那就意味著需要控制Consumer或者Producer的流量帶寬逸尖，通常限制流量這件事需要在網(wǎng)卡上作處理，像常見的N路交換機(jī)或者高端路由器瘸右，所以對于Kafka來說娇跟，想要操控OS的網(wǎng)卡去控制流量顯然具有非常高的難度，因此Kafka采用了另外一個特別的思路太颤，即：沒有辦法控制網(wǎng)卡通過的流量大小苞俘，就控制返回數(shù)據(jù)的時間。對于JVM程序來說龄章，就是一個wait或者seelp的事情吃谣。
所以對于Kafka來說乞封，有一套特殊的時延計算規(guī)則，Kafka按照一個窗口來統(tǒng)計單位時間傳輸?shù)牧髁扛诒铮?dāng)流量大小超過設(shè)置的閾值的時候肃晚，觸發(fā)流量控制，將當(dāng)前請求丟入Kafka的Qutota Manager仔戈，等到延遲時間到達(dá)后关串，再次返回數(shù)據(jù)。我們通過Kafka的ClientQutotaManager類中的方法來看：
這幾行代碼代表了Kafka的限流計算邏輯监徘，大概的思路為：假設(shè)我們設(shè)定當(dāng)前流量上限不超過T晋修，根據(jù)窗口計算出當(dāng)前的速率為O，如果O超過了T凰盔，那么會進(jìn)行限速飞蚓，限速的公示為：
X = (O - T)/ T * W
X為需要延遲的時間，讓我舉一個形象的例子廊蜒，假設(shè)我們限定流量不超過10MB/s趴拧，過去5秒（公示中的W，窗口區(qū)間）內(nèi)通過的流量為100MB山叮，則延遲的時間為：（100-5*10）/ 10=5秒著榴。這樣就能夠保障在下一個窗口運(yùn)行完成后，整個流量的大小是不會超過限制的屁倔。通過KafkaApis里面對Producer和Consumer的call back代碼可以看到對限流的延遲返回：
對于kafka的限流來講脑又，默認(rèn)是按照client id或者user來進(jìn)行限流的，從實(shí)際使用的角度來說锐借，意義不是很大问麸，基于topic或者partition分區(qū)級別的限流，相對使用場景更大钞翔，ThoughtWroks曾經(jīng)幫助某客戶修改Kafka核心源碼严卖，實(shí)現(xiàn)了基于topic的流量控制。
競選機(jī)制
Kafka背后的元信息重度依賴Zookeeper布轿，再次我們不解釋Zookeeper本身哮笆，而是關(guān)注Kafka到底是如何使用zk的，首先一張圖解釋Kafka對zk的重度依賴：
（圖片來源于網(wǎng)絡(luò)）
利用zk除了本身信息的存儲之外汰扭，最重要的就是Kafka利用zk實(shí)現(xiàn)選舉機(jī)制稠肘，其中以controller為主要的介紹，首先controller作為Kafka的心臟萝毛，主要負(fù)責(zé)著包括不限于以下重要事項：
也就是說Controller是Kafka的核心角色项阴，對于Controller來說，采用公平競爭笆包，任何一個Broker都有可能成為Controller环揽，保障了集群的健壯性拷沸，對于Controller來說，其選舉流程如下：
- 先獲取 zk 的 /cotroller 節(jié)點(diǎn)的信息薯演，獲取 controller 的 broker id撞芍，如果該節(jié)點(diǎn)不存在（比如集群剛創(chuàng)建時），* 那么獲取的 controller id 為-1跨扮。
- 如果 controller id 不為-1序无，即 controller 已經(jīng)存在，直接結(jié)束流程衡创。
- 如果 controller id 為-1帝嗡，證明 controller 還不存在，這時候當(dāng)前 broker 開始在 zk 注冊 controller璃氢；哟玷。
- 如果注冊成功，那么當(dāng)前 broker 就成為了 controller一也，這時候開始調(diào)用 onBecomingLeader() 方法巢寡，正式初始化 controller（注意：controller 節(jié)點(diǎn)是臨時節(jié)點(diǎn)，如果當(dāng)前 controller 與 zk 的 session 斷開椰苟，那么 controller 的臨時節(jié)點(diǎn)會消失抑月，會觸發(fā) controller 的重新選舉）。
- 如果注冊失斢吆（剛好 controller 被其他 broker 創(chuàng)建了谦絮、拋出異常等），那么直接返回洁仗。
其代碼直接通過KafkaController可以看到：
一旦Controller選舉出來之后层皱，則其他Broker會監(jiān)聽zk的變化，來響應(yīng)集群中Controller掛掉的情況：
從而觸發(fā)新的Controller選舉動作赠潦。對于Kafka來說叫胖，整個設(shè)計非常緊湊，代碼質(zhì)量相當(dāng)高祭椰，很多設(shè)計也非常具有借鑒意義臭家，類似的功能在Kafka中有非常多的特性體現(xiàn)疲陕，這些特性結(jié)合一起方淤，形成了Kafka整個穩(wěn)定的局面。
Kafka該怎么用
雖然Kafka整體看起來非常優(yōu)秀蹄殃，但是Kafka也不是全能的銀彈携茂，必然有其對應(yīng)的短板，那么對于Kafka如何诅岩，或者如何能用的更好讳苦，則需要經(jīng)過實(shí)際的實(shí)踐才能得感悟的出带膜。經(jīng)過歸納和總結(jié)，能夠發(fā)現(xiàn)以下不同的使用場景和特點(diǎn)鸳谜。
- Kafka 并不合適高頻交易系統(tǒng)：Kafka雖然具有非常高的吞吐量和性能膝藕，但是不可否認(rèn)，Kafka在單條消息的低延遲方面依舊不如傳統(tǒng)MQ咐扭，畢竟依托推模型的MQ能夠在實(shí)時消息發(fā)送的場景下取得先天的優(yōu)勢芭挽。
- Kafka并不具備完善的事務(wù)機(jī)制：0.11之后Kafka新增了事務(wù)機(jī)制，可以保障Producer的批量提交蝗肪，為了保障不會讀取到臟數(shù)據(jù)袜爪，Consumer可以通過對消息狀態(tài)的過濾過濾掉不合適的數(shù)據(jù)，但是依舊保留了讀取所有數(shù)據(jù)的操作薛闪，即便如此Kafka的事務(wù)機(jī)制依舊不完備辛馆，背后主要的原因是Kafka對client并不感冒，所以不會統(tǒng)一所有的通用協(xié)議豁延，因此在類似僅且被消費(fèi)一次等場景下昙篙，效果非常依賴于客戶端的實(shí)現(xiàn)。
- Kafka的異地容災(zāi)方案非常復(fù)雜：對于Kafka來說诱咏，如果要實(shí)現(xiàn)跨機(jī)房的無感知切換瓢对，就需要支持跨集群的代理，因為Kafka特殊的append log的設(shè)計機(jī)制胰苏，導(dǎo)致同樣的offset在不同的broker和不同的內(nèi)容上無法復(fù)用硕蛹，也就是文件一旦被拷貝到另外一臺服務(wù)器上，將不可讀取硕并，相比類似基于數(shù)據(jù)庫的MQ法焰，很難實(shí)現(xiàn)數(shù)據(jù)的跨集群同步，同時對于offset的復(fù)現(xiàn)也非常難倔毙，曾經(jīng)幫助客戶實(shí)現(xiàn)了一套跨機(jī)房的Kafka 集群Proxy埃仪，投入了非常大的成本。
- Kafka Controller架構(gòu)無法充分利用集群資源：Kafka Controller類似于Es的去中心化思想陕赃，按照競選規(guī)則從集群中選擇一臺服務(wù)器作為Controller卵蛉，意味著改服務(wù)器即承擔(dān)著Controller的職責(zé)，同時又承擔(dān)著Broker的職責(zé)么库，導(dǎo)致在海量消息的壓迫下傻丝，該服務(wù)器的資源很容易成為集群的瓶頸，導(dǎo)致集群資源無法最大化诉儒。Controller雖然支持HA但是并不支持分布式葡缰，也就意味著如果要想Kafka的性能最優(yōu)，每一臺服務(wù)器至少都需要達(dá)到最高配置。
- Kafka不具備非常智能的分區(qū)均衡能力：通常在設(shè)計落地存儲的時候泛释，對于熱點(diǎn)或者要求性能足夠高的場景下滤愕，會是SSD和HD的結(jié)合，同時如果集群存在磁盤容量大小不均等的情況怜校，對于Kafka來說會有非常嚴(yán)重的問題间影，Kafka的分區(qū)產(chǎn)生是按照paratition的個數(shù)進(jìn)行統(tǒng)計，將新的分區(qū)創(chuàng)建在個數(shù)最少的磁盤上茄茁，見下圖：
曾經(jīng)我?guī)椭称髽I(yè)修改了分區(qū)創(chuàng)建規(guī)則宇智，考慮了容量的情況，也就是按照磁盤容量進(jìn)行分區(qū)的選擇胰丁，緊接著帶來第二個問題：容量大的磁盤具備更多的分區(qū)随橘，則會導(dǎo)致大量的IO都壓向該盤，最后問題又落回IO锦庸，會影響該磁盤的其他topic的性能机蔗。所以在考慮MQ系統(tǒng)的時候，需要合理的手動設(shè)置Kafka的分區(qū)規(guī)則甘萧。萝嘁。
結(jié)尾
Kafka并不是唯一的解決方案，像幾年前新生勢頭挺厲害的pulsar扬卷，以取代Kafka的口號沖入市場牙言，也許會成為下一個解決Kafka部分痛點(diǎn)的框架，下文再講述pulsar怪得。
更多精彩洞見咱枉，請關(guān)注微信公眾號ThoughtWorks洞見
