下面給出 Kafka 一些重要概念,讓大家對 Kafka 有個整體的認識和感知,后面還會詳細的決議每一個概念的作用以及更深入的原理
? Producer:訊息生產者,向 Kafka Broker 發訊息的客戶端,
? Consumer:訊息消費者,從 Kafka Broker 取訊息的客戶端,
? Consumer Group:消費者組(CG),消費者組內每個消費者負責消費不同磁區的資料,提高消費能力,一個磁區只能由組內一個消費者消費,消費者組之間互不影響,所有的消費者都屬于某個消費者組,即消費者組是邏輯上的一個訂閱者,
? Broker:一臺 Kafka 機器就是一個 Broker,一個集群由多個 Broker 組成,一個 Broker 可以容納多個 Topic,
? Topic:可以理解為一個佇列,Topic 將訊息分類,生產者和消費者面向的是同一個 Topic,
? Partition:為了實作擴展性,提高并發能力,一個非常大的 Topic 可以分布到多個 Broker (即服務器)上,一個 Topic 可以分為多個 Partition,每個 Partition 是一個 有序的佇列,
? Replica:副本,為實作備份的功能,保證集群中的某個節點發生故障時,該節點上的 Partition 資料不丟失,且 Kafka 仍然能夠繼續作業,Kafka 提供了副本機制,一個 Topic 的每個磁區都有若干個副本,一個 Leader 和若干個 Follower,
? Leader:每個磁區多個副本的“主”副本,生產者發送資料的物件,以及消費者消費資料的物件,都是 Leader,
? Follower:每個磁區多個副本的“從”副本,實時從 Leader 中同步資料,保持和 Leader 資料的同步,Leader 發生故障時,某個 Follower 還會成為新的 Leader,
? Offset:消費者消費的位置資訊,監控資料消費到什么位置,當消費者掛掉再重新恢復的時候,可以從消費位置繼續消費,
? ZooKeeper:Kafka 集群能夠正常作業,需要依賴于 ZooKeeper,ZooKeeper 幫助 Kafka 存盤和管理集群資訊,
1. 訊息和批次
Kafka中的資料單元稱為訊息(message),如果你對資料庫非常了解,那么您可以將其視為與資料庫中行或記錄類似,就Kafka而言,訊息只是一個位元組陣列,因此其中包含的資料對Kafka沒有特定的格式或含義,訊息可以具有可選的元資料位,其被稱為key,key也是一個位元組陣列,與訊息一樣,對Kafka沒有特定含義,當訊息以更受控制的方式寫入磁區時,使用key,最簡單的方案是生成key的一致哈希,然后通過獲取哈希模的結果(主題中的磁區總數)來選擇該訊息的磁區號,這可確保具有相同key的訊息始終寫入同一磁區,
為了提高效率,將訊息分批寫入Kafka,批處理只是一組訊息,所有訊息都生成到同一主題和磁區,每條訊息通過網路進行單獨的往返會導致過度的開銷,而將訊息一起收集到一個批處理中則會減少這種情況,當然,這是延遲和吞吐量之間的權衡:批次越大,每單位時間可以處理的訊息越多,但單個訊息傳播所需的時間就越長,批次通常也是壓縮的,以一些處理能力為代價提供更有效的資料傳輸和存盤,
1.1 訊息
是Kafka中的最小資料單元,類比“資料庫”中的一條記錄;訊息由位元組陣列組成,Kafka沒有具體的格式和定義,但是客戶端提供的訊息定義中有一組可選的資料單元:
public final class ProducerRecord<K, V> {
private final String topic; //訊息主題
private final Integer partition; //訊息磁區
private final K key; //訊息的鍵
private final V value; // 訊息值
}
在以上的欄位中,只有訊息主題是必須的,標識這個訊息的分類,
2.2 批次
同我們常說的分批處理思想中的批次概念是一致的;從根本上來講都是為了減少消耗,提升效率,
如果每一個生產者產生一條訊息,我們就寫到網路中,會帶來大量的開銷,所以將訊息分批次來傳遞;當然分批會帶來延遲,這樣就需要在延遲和吞吐量之間做一個權衡,Kafka提供引數來給開發者優化這種平衡,
單個批次訊息越多,延遲越大,同時訊息會被壓縮,來提升資料的傳輸和存盤能力,當然壓縮更消耗CPU,
批次里面的訊息都是屬于同一個主題中的同一個磁區,這樣可以保證一次發送一批訊息時的網路開銷最小,
2. 模式(Schemas)
雖然訊息是Kafka本身的不透明位元組陣列,但建議在訊息內容上加上額外的結構或模式,以便易于理解,訊息架構有許多選項,具體取決于您的應用程式的個性化需求,簡單系統,例如Javascript Object Notation(JSON)和可擴展標記語言(XML),易于使用且易于閱讀,但是,它們缺乏強大的型別處理和模式版本之間的兼容性等功能,許多Kafka開發人員都贊成使用Apache Avro,這是一個最初為Hadoop開發的序列化框架, Avro提供緊湊的序列化格式;與訊息有效負載分離的模式,不需要在更改時生成代碼;強大的資料型別和模式演變,兼具向后和向前兼容性,
一致的資料格式在Kafka中很重要,因為它允許寫入和讀取訊息分離,當這些任務緊密耦合時,必須更新訂閱訊息的應用程式以處理新資料格式,與舊格式并行,只有這樣才能更新發布訊息的應用程式以使用新格式,通過使用定義良好的模式并將它們存盤在一個通用的存盤庫中,可以無需協調地理解Kafka中的訊息,
3. 主題和磁區
Kafka 里的訊息用主題進行分類(主題好比資料庫中的表) , 主題下有可以被分為若干個磁區(分表技術) , 磁區本質上是個提交日志檔案, 有新訊息, 這個訊息就會以追加的方式寫入磁區(寫檔案的形式) , 然后用先入先出的順序讀取,
3.1 主題
是訊息的分類標識,類似于檔案系統中的檔案夾
3.2 磁區
是一個主題的佇列,同一個主題會包含若干磁區,每一個磁區都是一個提交記錄,訊息會被追加到磁區中,在一個磁區中保證順序,以先入先出的順序被消費,
Kafka為每個磁區中維護著一個偏移量,偏移量記錄著當前磁區的消費記錄,偏移量保存在分布式協同服務器ZooKeeper上,
磁區在Kafka中有著重要的意義,Kafka通過磁區來實作資料冗余和主題的橫向擴展;多個磁區可以分布在不同的kafka服務端機器上,這使主題也可以橫跨多個服務器存在,保證了分布式的能力;
在訊息中講到了訊息的鍵,在訊息沒有配置鍵的時候,生產者會把訊息均衡的寫入到各個磁區,當我們需要把特定的訊息寫入到固定的磁區時,可以通過訊息的鍵和磁區器來實作,磁區器會將鍵生成成散列值,并映射到各個磁區上,
為了大量的訊息能負載分散,要求主題的磁區數要大于當前Kafka的broker服務器數量,這樣才能保證所有每個broker能分擔到訊息的壓力,在實際生產中,我們可以增加磁區來給主題擴容,但是不能減少磁區,
選定磁區數量是一個需要經驗的事情,需要考慮多個因素:
-
主題需要多大的吞吐 -
單個磁區的最大吞吐量多少 -
每個broker上擁有的磁區數量,這需要考量磁盤和網路帶寬 -
單個磁區上擁有的磁區也不能太多,畢竟磁區越多記憶體也越大,重新選舉的時間也越長
需要注意的是,如果使用了訊息的鍵來控制訊息寫入磁區,那么增加主題時就需要慎重了,因為這會帶來rehash的問題,
4. 生產者和消費者
Kafka客戶端是系統用戶,有兩種基本型別:生產者和消費者,還有高級客戶端API - 用于資料集成的Kafka Connect API和用于流處理的Kafka Streams,高級客戶端使用生產者和消費者作為構建塊,并在頂部提供更高級別的功能,
4.1 生產者
生產者創造新的資訊,在其他發布/訂閱系統中,這些可以稱為發布者或撰寫者,通常,將為特定主題生成訊息,默認情況下,生產者不關心特定訊息寫入的磁區,并將均衡地平衡主題的所有磁區上的訊息,在某些情況下,生產者會將訊息定向到特定磁區,這通常使用訊息key和磁區程式來完成,該磁區程式將生成key的散列并將其映射到特定磁區,這確保了使用給定key生成的所有訊息都將寫入同一磁區,生產者還可以使用遵循其他業務規則的自定義磁區程式將訊息映射到磁區,
4.2 消費者
消費者閱讀訊息, 在其他發布/訂閱系統中,這些客戶端可以被稱為訂閱者或讀者, 消費者訂閱一個或多個主題,并按訊息的生成順序讀取訊息, 消費者通過跟蹤訊息的偏移來跟蹤它已經消耗了哪些訊息, 偏移量(Offset)是元資料 - 一個不斷增加的整數值 - Kafka在生成時添加到每個訊息中, 給定磁區中的每條訊息都有唯一的偏移量, 通過在Zookeeper或Kafka本身中存盤每個磁區的最后消耗訊息的偏移量,消費者可以停止并重新啟動而不會丟失其位置,
消費者負責消費者群組的一部分作業,消費者群組是一起作業以消費主題的一個或多個磁區, 該小組確保每個磁區僅由一名成員消費, 在單個組中有三個消費者使用主題, 其中兩個消費者分別在一個磁區作業,而第三個消費者在兩個磁區作業, 消費者對磁區的映射通常稱為消費者對磁區的所有權,
不同的消費者群組可以讀取同一個主題,但對于同一個群組中不同消費者不能讀取相同磁區

通過這種方式,消費者可以橫向擴展以消費具有大量訊息的主題, 此外,如果單個使用者失敗,則該組的其余成員將重新平衡正在使用的磁區以接管缺少的成員,
5. 保留訊息
保留訊息是Kafka的一個重要特性,Kafka broker默認的訊息保留策略有兩種,
-
保留一段固定的時間,比如7天 -
保留到訊息達到一定大小的位元組數,如1GB 當達到上限后,舊的訊息會過期從而被洗掉,所以在任何時刻,可用訊息的總量不會超過配置引數所指定的大小,
6. 多集群
隨著Kafka部署的增長,擁有多個集群通常是有利的, 有幾個原因可以解決這個問題:
? 分離資料型別
? 為安全要求隔離
? 多個資料中心(災難恢復)
特別是在處理多個資料中心時,通常需要在它們之間復制訊息, 通過這種方式,在線應用程式可以訪問兩個站點的用戶活動, 例如,如果用戶更改其組態檔中的公共資訊,則無論顯示搜索結果的資料中心如何,都需要顯示該更改, 或者,可以將監控資料從許多站點收集到分析和警報系統所在的單個中心位置, Kafka集群中的復制機制僅設計用于單個集群,而不是多個集群之間,
Kafka專案包括一個名為MirrorMaker的工具,用于此目的, MirrorMaker的核心是Kafka消費者和生產者,與佇列鏈接在一起, 訊息從一個Kafka集群中消耗并為另一個集群生成,使用MirrorMaker架構,將來自兩個本地群集的訊息聚合到聚合群集中,然后將該群集復制到其他資料中心, 應用程式的簡單特性掩蓋了它在創建復雜資料管道方面的能力,
本文由
傳智教育博學谷教研團隊發布,如果本文對您有幫助,歡迎
關注和點贊;如果您有任何建議也可留言評論或私信,您的支持是我堅持創作的動力,轉載請注明出處!
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/538693.html
標籤:其他
上一篇:<九>理解虛繼承和虛基類
下一篇:Python工具箱系列(十六)
