Kafka【入門】就這一篇!

 

 

做者:光閃php

 

前言:在以前的文章裏面已經瞭解到了「消息隊列」是怎麼樣的一種存在(傳送門),Kafka 做爲當下流行的一種中間件,咱們如今開始學習它!html

1、Kafka 簡介

Kafka 建立背景

Kafka 是一個消息系統,本來開發自 LinkedIn,用做 LinkedIn 的活動流(Activity Stream)和運營數據處理管道(Pipeline)的基礎。如今它已被多家不一樣類型的公司 做爲多種類型的數據管道和消息系統使用。數據庫

活動流數據是幾乎全部站點在對其網站使用狀況作報表時都要用到的數據中最常規的部分。活動數據包括頁面訪問量(Page View)、被查看內容方面的信息以及搜索狀況等內容。這種數據一般的處理方式是先把各類活動以日誌的形式寫入某種文件,而後週期性地對這些文件進行統計分析。運營數據指的是服務器的性能數據(CPU、IO 使用率、請求時間、服務日誌等等數據)。運營數據的統計方法種類繁多。bootstrap

近年來,活動和運營數據處理已經成爲了網站軟件產品特性中一個相當重要的組成部分,這就須要一套稍微更加複雜的基礎設施對其提供支持。數組

Kafka 簡介

Kafka 是一種分佈式的,基於發佈 / 訂閱的消息系統。主要設計目標以下:緩存

  • 以時間複雜度爲 O(1) 的方式提供消息持久化能力,即便對 TB 級以上數據也能保證常數時間複雜度的訪問性能。安全

  • 高吞吐率。即便在很是廉價的商用機器上也能作到單機支持每秒 100K 條以上消息的傳輸。服務器

  • 支持 Kafka Server 間的消息分區,及分佈式消費,同時保證每一個 Partition 內的消息順序傳輸。網絡

  • 同時支持離線數據處理和實時數據處理。session

  • Scale out:支持在線水平擴展。

Kafka 基礎概念

概念一:生產者與消費者

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

對於 Kafka 來講客戶端有兩種基本類型:生產者(Producer)消費者(Consumer)。除此以外,還有用來作數據集成的 Kafka Connect API 和流式處理的 Kafka Streams 等高階客戶端,但這些高階客戶端底層仍然是生產者和消費者API,它們只不過是在上層作了封裝。

這很容易理解,生產者(也稱爲發佈者)建立消息,而消費者(也稱爲訂閱者)負責消費or讀取消息。

概念二:主題(Topic)與分區(Partition)

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

在 Kafka 中,消息以主題(Topic)來分類,每個主題都對應一個「消息隊列」,這有點兒相似於數據庫中的表。可是若是咱們把全部同類的消息都塞入到一個「中心」隊列中,勢必缺乏可伸縮性,不管是生產者/消費者數目的增長,仍是消息數量的增長,均可能耗盡系統的性能或存儲。

咱們使用一個生活中的例子來講明:如今 A 城市生產的某商品須要運輸到 B 城市,走的是公路,那麼單通道的高速公路不管是在「A 城市商品增多」仍是「如今 C 城市也要往 B 城市運輸東西」這樣的狀況下都會出現「吞吐量不足」的問題。因此咱們如今引入分區(Partition)的概念,相似「容許多修幾條道」的方式對咱們的主題完成了水平擴展。

概念三:Broker 和集羣(Cluster)

一個 Kafka 服務器也稱爲 Broker,它接受生產者發送的消息並存入磁盤;Broker 同時服務消費者拉取分區消息的請求,返回目前已經提交的消息。使用特定的機器硬件,一個 Broker 每秒能夠處理成千上萬的分區和百萬量級的消息。(如今動不動就百萬量級..我特意去查了一把,好像確實集羣的狀況下吞吐量挺高的..摁..)

若干個 Broker 組成一個集羣(Cluster),其中集羣內某個 Broker 會成爲集羣控制器(Cluster Controller),它負責管理集羣,包括分配分區到 Broker、監控 Broker 故障等。在集羣內,一個分區由一個 Broker 負責,這個 Broker 也稱爲這個分區的 Leader;固然一個分區能夠被複制到多個 Broker 上來實現冗餘,這樣當存在 Broker 故障時能夠將其分區從新分配到其餘 Broker 來負責。下圖是一個樣例:

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

Kafka 的一個關鍵性質是日誌保留(retention),咱們能夠配置主題的消息保留策略,譬如只保留一段時間的日誌或者只保留特定大小的日誌。當超過這些限制時,老的消息會被刪除。咱們也能夠針對某個主題單獨設置消息過時策略,這樣對於不一樣應用能夠實現個性化。

概念四:多集羣

隨着業務發展,咱們每每須要多集羣,一般處於下面幾個緣由:

  • 基於數據的隔離;

  • 基於安全的隔離;

  • 多數據中心(容災)

當構建多個數據中心時,每每須要實現消息互通。舉個例子,假如用戶修改了我的資料,那麼後續的請求不管被哪一個數據中心處理,這個更新須要反映出來。又或者,多個數據中心的數據須要彙總到一個總控中心來作數據分析。

上面說的分區複製冗餘機制只適用於同一個 Kafka 集羣內部,對於多個 Kafka 集羣消息同步可使用 Kafka 提供的 MirrorMaker 工具。本質上來講,MirrorMaker 只是一個 Kafka 消費者和生產者,並使用一個隊列鏈接起來而已。它從一個集羣中消費消息,而後往另外一個集羣生產消息。

2、Kafka 的設計與實現

上面咱們知道了 Kafka 中的一些基本概念,但做爲一個成熟的「消息隊列」中間件,其中有許多有意思的設計值得咱們思考,下面咱們簡單列舉一些。

討論一:Kafka 存儲在文件系統上

是的,您首先應該知道 Kafka 的消息是存在於文件系統之上的。Kafka 高度依賴文件系統來存儲和緩存消息,通常的人認爲 「磁盤是緩慢的」,因此對這樣的設計持有懷疑態度。實際上,磁盤比人們預想的快不少也慢不少,這取決於它們如何被使用;一個好的磁盤結構設計可使之跟網絡速度同樣快。

現代的操做系統針對磁盤的讀寫已經作了一些優化方案來加快磁盤的訪問速度。好比,預讀會提早將一個比較大的磁盤快讀入內存。後寫會將不少小的邏輯寫操做合併起來組合成一個大的物理寫操做。而且,操做系統還會將主內存剩餘的全部空閒內存空間都用做磁盤緩存,全部的磁盤讀寫操做都會通過統一的磁盤緩存(除了直接 I/O 會繞過磁盤緩存)。綜合這幾點優化特色,若是是針對磁盤的順序訪問,某些狀況下它可能比隨機的內存訪問都要快,甚至能夠和網絡的速度相差無幾。

上述的 Topic 實際上是邏輯上的概念,面相消費者和生產者,物理上存儲的實際上是 Partition,每個 Partition 最終對應一個目錄,裏面存儲全部的消息和索引文件。默認狀況下,每個 Topic 在建立時若是不指定 Partition 數量時只會建立 1 個 Partition。好比,我建立了一個 Topic 名字爲 test ,沒有指定 Partition 的數量,那麼會默認建立一個 test-0 的文件夾,這裏的命名規則是:<topic_name>-<partition_id>

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

任何發佈到 Partition 的消息都會被追加到 Partition 數據文件的尾部,這樣的順序寫磁盤操做讓 Kafka 的效率很是高(經驗證,順序寫磁盤效率比隨機寫內存還要高,這是 Kafka 高吞吐率的一個很重要的保證)。

每一條消息被髮送到 Broker 中,會根據 Partition 規則選擇被存儲到哪個 Partition。若是 Partition 規則設置的合理,全部消息能夠均勻分佈到不一樣的 Partition中。

討論二:Kafka 中的底層存儲設計

假設咱們如今 Kafka 集羣只有一個 Broker,咱們建立 2 個 Topic 名稱分別爲:「topic1」和「topic2」,Partition 數量分別爲 一、2,那麼咱們的根目錄下就會建立以下三個文件夾:

| --topic1-0
    | --topic2-0
    | --topic2-1

在 Kafka 的文件存儲中,同一個 Topic 下有多個不一樣的 Partition,每一個 Partition 都爲一個目錄,而每個目錄又被平均分配成多個大小相等的 Segment File 中,Segment File 又由 index file 和 data file 組成,他們老是成對出現,後綴 ".index" 和 ".log" 分表表示 Segment 索引文件和數據文件。

如今假設咱們設置每一個 Segment 大小爲 500 MB,並啓動生產者向 topic1 中寫入大量數據,topic1-0 文件夾中就會產生相似以下的一些文件:

| --topic1-0
        | --00000000000000000000.index
        | --00000000000000000000.log
        | --00000000000000368769.index
        | --00000000000000368769.log
        | --00000000000000737337.index
        | --00000000000000737337.log
        | --00000000000001105814.index
        | --00000000000001105814.log
    | --topic2-0
    | --topic2-1

Segment 是 Kafka 文件存儲的最小單位。Segment 文件命名規則:Partition 全局的第一個 Segment 從 0 開始,後續每一個 Segment 文件名爲上一個 Segment 文件最後一條消息的 offset 值。數值最大爲 64 位 long 大小,19 位數字字符長度,沒有數字用0填充。如 00000000000000368769.index 和 00000000000000368769.log。

以上面的一對 Segment File 爲例,說明一下索引文件和數據文件對應關係:

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

其中以索引文件中元數據 <3, 497> 爲例,依次在數據文件中表示第 3 個 message(在全局 Partition 表示第 368769 + 3 = 368772 個 message)以及該消息的物理偏移地址爲 497。

注意該 index 文件並非從0開始,也不是每次遞增1的,這是由於 Kafka 採起稀疏索引存儲的方式,每隔必定字節的數據創建一條索引,它減小了索引文件大小,使得可以把 index 映射到內存,下降了查詢時的磁盤 IO 開銷,同時也並無給查詢帶來太多的時間消耗。

由於其文件名爲上一個 Segment 最後一條消息的 offset ,因此當須要查找一個指定 offset 的 message 時,經過在全部 segment 的文件名中進行二分查找就能找到它歸屬的 segment ,再在其 index 文件中找到其對應到文件上的物理位置,就能拿出該 message 。

因爲消息在 Partition 的 Segment 數據文件中是順序讀寫的,且消息消費後不會刪除(刪除策略是針對過時的 Segment 文件),這種順序磁盤 IO 存儲設計師 Kafka 高性能很重要的緣由。

Kafka 是如何準確的知道 message 的偏移的呢?這是由於在 Kafka 定義了標準的數據存儲結構,在 Partition 中的每一條 message 都包含了如下三個屬性:

  • offset:表示 message 在當前 Partition 中的偏移量,是一個邏輯上的值,惟一肯定了 Partition 中的一條 message,能夠簡單的認爲是一個 id;

  • MessageSize:表示 message 內容 data 的大小;

  • data:message 的具體內容

討論三:生產者設計概要

當咱們發送消息以前,先問幾個問題:每條消息都是很關鍵且不能容忍丟失麼?偶爾重複消息能夠麼?咱們關注的是消息延遲仍是寫入消息的吞吐量?

舉個例子,有一個信用卡交易處理系統,當交易發生時會發送一條消息到 Kafka,另外一個服務來讀取消息並根據規則引擎來檢查交易是否經過,將結果經過 Kafka 返回。對於這樣的業務,消息既不能丟失也不能重複,因爲交易量大所以吞吐量須要儘量大,延遲能夠稍微高一點。

再舉個例子,假如咱們須要收集用戶在網頁上的點擊數據,對於這樣的場景,少許消息丟失或者重複是能夠容忍的,延遲多大都不重要只要不影響用戶體驗,吞吐則根據實時用戶數來決定。

不一樣的業務須要使用不一樣的寫入方式和配置。具體的方式咱們在這裏不作討論,如今先看下生產者寫消息的基本流程:

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

圖片來源:http://www.dengshenyu.com/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/2017/11/12/kafka-producer.html

 

流程以下:

  1. 首先,咱們須要建立一個ProducerRecord,這個對象須要包含消息的主題(topic)和值(value),能夠選擇性指定一個鍵值(key)或者分區(partition)。

  2. 發送消息時,生產者會對鍵值和值序列化成字節數組,而後發送到分配器(partitioner)。

  3. 若是咱們指定了分區,那麼分配器返回該分區便可;不然,分配器將會基於鍵值來選擇一個分區並返回。

  4. 選擇完分區後,生產者知道了消息所屬的主題和分區,它將這條記錄添加到相同主題和分區的批量消息中,另外一個線程負責發送這些批量消息到對應的Kafka broker。

  5. 當broker接收到消息後,若是成功寫入則返回一個包含消息的主題、分區及位移的RecordMetadata對象,不然返回異常。

  6. 生產者接收到結果後,對於異常可能會進行重試。

討論四:消費者設計概要

消費者與消費組

假設這麼個場景:咱們從Kafka中讀取消息,而且進行檢查,最後產生結果數據。咱們能夠建立一個消費者實例去作這件事情,但若是生產者寫入消息的速度比消費者讀取的速度快怎麼辦呢?這樣隨着時間增加,消息堆積愈來愈嚴重。對於這種場景,咱們須要增長多個消費者來進行水平擴展。

Kafka消費者是消費組的一部分,當多個消費者造成一個消費組來消費主題時,每一個消費者會收到不一樣分區的消息。假設有一個T1主題,該主題有4個分區;同時咱們有一個消費組G1,這個消費組只有一個消費者C1。那麼消費者C1將會收到這4個分區的消息,以下所示:

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

若是咱們增長新的消費者C2到消費組G1,那麼每一個消費者將會分別收到兩個分區的消息,以下所示:

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

若是增長到4個消費者,那麼每一個消費者將會分別收到一個分區的消息,以下所示:

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

但若是咱們繼續增長消費者到這個消費組,剩餘的消費者將會空閒,不會收到任何消息:

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

總而言之,咱們能夠經過增長消費組的消費者來進行水平擴展提高消費能力。這也是爲何建議建立主題時使用比較多的分區數,這樣能夠在消費負載高的狀況下增長消費者來提高性能。另外,消費者的數量不該該比分區數多,由於多出來的消費者是空閒的,沒有任何幫助。

Kafka一個很重要的特性就是,只需寫入一次消息,能夠支持任意多的應用讀取這個消息。換句話說,每一個應用均可以讀到全量的消息。爲了使得每一個應用都能讀到全量消息,應用須要有不一樣的消費組。對於上面的例子,假如咱們新增了一個新的消費組G2,而這個消費組有兩個消費者,那麼會是這樣的:

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

在這個場景中,消費組G1和消費組G2都能收到T1主題的全量消息,在邏輯意義上來講它們屬於不一樣的應用。

最後,總結起來就是:若是應用須要讀取全量消息,那麼請爲該應用設置一個消費組;若是該應用消費能力不足,那麼能夠考慮在這個消費組裏增長消費者。

消費組與分區重平衡

能夠看到,當新的消費者加入消費組,它會消費一個或多個分區,而這些分區以前是由其餘消費者負責的;另外,當消費者離開消費組(好比重啓、宕機等)時,它所消費的分區會分配給其餘分區。這種現象稱爲重平衡(rebalance)。重平衡是 Kafka 一個很重要的性質,這個性質保證了高可用和水平擴展。不過也須要注意到,在重平衡期間,全部消費者都不能消費消息,所以會形成整個消費組短暫的不可用。並且,將分區進行重平衡也會致使原來的消費者狀態過時,從而致使消費者須要從新更新狀態,這段期間也會下降消費性能。後面咱們會討論如何安全的進行重平衡以及如何儘量避免。

消費者經過按期發送心跳(hearbeat)到一個做爲組協調者(group coordinator)的 broker 來保持在消費組內存活。這個 broker 不是固定的,每一個消費組均可能不一樣。當消費者拉取消息或者提交時,便會發送心跳。

若是消費者超過必定時間沒有發送心跳,那麼它的會話(session)就會過時,組協調者會認爲該消費者已經宕機,而後觸發重平衡。能夠看到,從消費者宕機到會話過時是有必定時間的,這段時間內該消費者的分區都不能進行消息消費;一般狀況下,咱們能夠進行優雅關閉,這樣消費者會發送離開的消息到組協調者,這樣組協調者能夠當即進行重平衡而不須要等待會話過時。

在 0.10.1 版本,Kafka 對心跳機制進行了修改,將發送心跳與拉取消息進行分離,這樣使得發送心跳的頻率不受拉取的頻率影響。另外更高版本的 Kafka 支持配置一個消費者多長時間不拉取消息但仍然保持存活,這個配置能夠避免活鎖(livelock)。活鎖,是指應用沒有故障可是因爲某些緣由不能進一步消費。

Partition 與消費模型

上面提到,Kafka 中一個 topic 中的消息是被打散分配在多個 Partition(分區) 中存儲的, Consumer Group 在消費時須要從不一樣的 Partition 獲取消息,那最終如何重建出 Topic 中消息的順序呢?

答案是:沒有辦法。Kafka 只會保證在 Partition 內消息是有序的,而無論全局的狀況。

下一個問題是:Partition 中的消息能夠被(不一樣的 Consumer Group)屢次消費,那 Partition中被消費的消息是什麼時候刪除的?Partition 又是如何知道一個 Consumer Group 當前消費的位置呢?

不管消息是否被消費,除非消息到期 Partition 從不刪除消息。例如設置保留時間爲 2 天,則消息發佈 2 天內任何 Group 均可以消費,2 天后,消息自動被刪除。
Partition 會爲每一個 Consumer Group 保存一個偏移量,記錄 Group 消費到的位置。以下圖:

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

爲何  Kafka 是 pull 模型

消費者應該向 Broker 要數據(pull)仍是 Broker 向消費者推送數據(push)?做爲一個消息系統,Kafka 遵循了傳統的方式,選擇由 Producer 向 broker push 消息並由 Consumer 從 broker pull 消息。一些 logging-centric system,好比 Facebook 的Scribe和 Cloudera 的Flume,採用 push 模式。事實上,push 模式和 pull 模式各有優劣。

push 模式很難適應消費速率不一樣的消費者,由於消息發送速率是由 broker 決定的。push 模式的目標是儘量以最快速度傳遞消息,可是這樣很容易形成 Consumer 來不及處理消息,典型的表現就是拒絕服務以及網絡擁塞。而 pull 模式則能夠根據 Consumer 的消費能力以適當的速率消費消息。

對於 Kafka 而言,pull 模式更合適。pull 模式可簡化 broker 的設計,Consumer 可自主控制消費消息的速率,同時 Consumer 能夠本身控制消費方式——便可批量消費也可逐條消費,同時還能選擇不一樣的提交方式從而實現不一樣的傳輸語義。

討論五:Kafka 如何保證可靠性

當咱們討論可靠性的時候,咱們總會提到保證*這個詞語。可靠性保證是基礎,咱們基於這些基礎之上構建咱們的應用。好比關係型數據庫的可靠性保證是ACID,也就是原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)和持久性(Durability)。

Kafka 中的可靠性保證有以下四點:

  • 對於一個分區來講,它的消息是有序的。若是一個生產者向一個分區先寫入消息A,而後寫入消息B,那麼消費者會先讀取消息A再讀取消息B。

  • 當消息寫入全部in-sync狀態的副本後,消息纔會認爲已提交(committed)這裏的寫入有可能只是寫入到文件系統的緩存,不必定刷新到磁盤。生產者能夠等待不一樣時機的確認,好比等待分區主副本寫入即返回,後者等待全部in-sync狀態副本寫入才返回。

  • 一旦消息已提交,那麼只要有一個副本存活,數據不會丟失。

  • 消費者只能讀取到已提交的消息。

使用這些基礎保證,咱們構建一個可靠的系統,這時候須要考慮一個問題:究竟咱們的應用須要多大程度的可靠性?可靠性不是無償的,它與系統可用性、吞吐量、延遲和硬件價格息息相關,得此失彼。所以,咱們每每須要作權衡,一味的追求可靠性並不實際。

想了解更多戳這裏:http://www.dengshenyu.com/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/2017/11/21/kafka-data-delivery.html

3、動手搭一個 Kafka

經過上面的描述,咱們已經大體瞭解到了「Kafka」是何方神聖了,如今咱們開始嘗試本身動手本地搭一個來實際體驗一把。

第一步:下載 Kafka

這裏以 Mac OS 爲例,在安裝了 Homebrew 的狀況下執行下列代碼:

brew install kafka

因爲 Kafka 依賴了 Zookeeper,因此在下載的時候會自動下載。

第二步:啓動服務

咱們在啓動以前首先須要修改 Kafka 的監聽地址和端口爲 localhost:9092

vi /usr/local/etc/kafka/server.properties

而後修改爲下圖的樣子:

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

依次啓動 Zookeeper 和 Kafka:

brew services start zookeeper
brew services start kafka

而後執行下列語句來建立一個名字爲 "test" 的 Topic:

kafka-topics --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic test

咱們能夠經過下列的命令查看咱們的 Topic 列表:

kafka-topics --list --zookeeper localhost:2181

第三步:發送消息

而後咱們新建一個控制檯,運行下列命令建立一個消費者關注剛纔建立的 Topic:

kafka-console-consumer --bootstrap-server localhost:9092 --topic test --from-beginning

用控制檯往剛纔建立的 Topic 中添加消息,並觀察剛纔建立的消費者窗口:

kafka-console-producer --broker-list localhost:9092 --topic test

能經過消費者窗口觀察到正確的消息:

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=參考資料

 

  1. http://www.dengshenyu.com/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/2017/11/06/kafka-Meet-Kafka.html - Kafka系列(一)初識Kafka

  2. https://lotabout.me/2018/kafka-introduction/ - Kafka 入門介紹

  3. https://www.zhihu.com/question/28925721 - Kafka 中的 Topic 爲何要進行分區? - 知乎

  4. https://blog.joway.io/posts/kafka-design-practice/ - Kafka 的設計與實踐思考

  5. http://www.dengshenyu.com/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/2017/11/21/kafka-data-delivery.html - Kafka系列(六)可靠的數據傳輸

     

     

 

 

watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=

相關文章
相關標籤/搜索