深刻理解kafka:核心設計與原理實踐-1.初始Kafka

Kafka起初是由Linkedin公司採用 Scala 語言開發的一個多分區,多副本且基於Zookeeper協調的分佈式消息系統,現己被捐獻給 Apache 基金會。目前Kafka已經定位爲一個分佈式流式處理平臺,它以高吞吐,可持久化,可水平擴展,支持流數據處理等多種特性而被普遍使用。目前愈來愈多的開源分佈式處理系統如Cloudera,Storm,Spark,Flink ,等都支持與Kafka集成。Kafka之因此受到愈來愈受青睞,與它所「扮」的大角色是分不開的。服務器

  • 消息系統:Kafka 和傳統的消息系統(也稱做消息中間件)都具有系統解稿、冗餘存儲、流量峯、緩衝、異步通訊、擴展性、可恢復性等功能。與此同時, Kafka還提供了大多數消息系統難以實現的消息序性保障及回溯消費的功能。
  • 存儲系統:Kafka把消息持久化到磁盤,相比於其餘基於內存存儲的系統而言,有效地下降了數據丟失的風險也正是得益於Kafka的消息持久化功能和多副本機制咱們能夠把Kafka做爲長期的數據存儲系統來使用,只須要把對應的數據保留策略設置爲「永久」或啓用主題的日誌壓縮功能便可。
  • 流式處理平臺:Kafka不只爲每一個流行的流式處理框架提供了可靠的數據來源,還提供了一個完整的流式處理類庫,好比窗口、鏈接、變換和聚合等各種操做。
  • 1.1基本概念 一個典型的 Kafka 體系架構包括若干 Producer、若干 Broker 、若干 Consumer ,以及一個Zookeeper集羣,以下圖所示。其中ZooKeeper是Kafka用來負責集羣元數據的管理、控制器的選舉 操做的。Producer將消息發送到Broker,Broker負責將收到的消息存儲到磁盤中,而Consumer負責從Broker訂閱並消費消息。
  • 整個Kafka體系結構中引入瞭如下3個術語。
  • (1)Producer:生產者,也就是發送消息的一方。生產者負責建立消息 而後將其投遞到Kafka中。
  • (2)Consumer:消費者,也就是接收消息的一方。消費者鏈接到Kafka上並接收消息,進而進行相應的業務邏輯處理。
  • (3)Broker:服務代理節點,對於Kafka而言,Broke能夠簡單地看做一個獨立的Kafka服務節點或Kafka服務實例。大多數狀況下也能夠將Broker看做一臺Kafka服務器,前提是這臺服務器上只部署了一個Kafka實例。一個或多個Broker組成了一個Kafka集羣。通常而言,咱們更習慣使用首字母小寫的broker來表示服務代理節點。 在Kafka中還有兩個特別重要的概念一主題(Topic)與分區(Partition)。Kafka中的消息以主題爲單位進行歸類,生產者負責將消息發送到特定的主題(發送到Kafka集羣中的每一條消息都要指定一個主題),而消費者負責訂閱主題並進行消費。
  • 主題是一個邏輯上的概念,它還能夠細分爲多個分區,一個分區只屬於單個主題,不少時候也會把分區稱爲主題分區(Topic-Partition)。同一主題下的不一樣分區包含的消息是不一樣的,分區在存儲層面能夠看做一個可追加的日誌(Log)文件,消息在被追加到分區日誌,文件的時候都會分配一個特定的偏移量(offset)。offset是消息在分區中的惟一標識,Kafka經過它來保證消息在分區內的順序性,不過offset並不跨越分區,也就是說,Kafka保證的是分區有序而不是主題有序。 以下圖所示,主題中有個分區,消息被順序追加到每一個分區日誌文件的尾部。Kafka中的分區能夠分佈在不一樣的服務器(broker)上,也就是說,一個主題能夠橫跨多個broker,以此來提供比單個broker更強大的性能。

  • 每一條消息被髮送到broker以前,會根據分區規則選擇存儲到哪一個具體的分區若是分區規則設定得合理,全部的消息均可以均勻地分配到不一樣的分區中。若是一個主題只對應一個文件,那麼這個文件所在的機器將會成爲這個主題的性能瓶頸,而分區解決了這個問題。在建立主題的時候能夠經過指定的參數來設置分區的個數,固然也能夠在主題建立完成以後去修改分區的數量,經過增長分區的數量能夠實現水平擴展。
  • Kafka爲分區引入了多副本Replica機制,經過增長副本數量能夠提高容災能力。同一分區的不一樣副本中保存的是相同的消息(在同一時刻,副本之間並不是徹底同樣)副本之間是"一主多從"的關係,其中leader副本負處理讀寫請求,follower副本只負責與leader副本的消息同步。副本處於不一樣的broker,當leader副本出現故障時,從follower副本中從新選舉新的leader副本對外提供服務。Kafka經過多副本機制實現了故障的自動轉移,當 Kafka 集羣中某個broker失效時仍然能保證服務可用。
  • 經過多副本機制實現了故障的自動轉移,當Kafka集羣中某個broker失效時仍然能保證服務可用。以下圖所示Kafka集羣中有4個broker,某個主題中有3個分區,且副本因子(即副本個數)也爲3,如此每一個分區便有1個leader副本和2個follower副本。生產者和消費者只與leader副本進行交互,而follower副本只負責消息的同步,不少時候follower副本中的消息相對leader副本而言會有必定的滯後。
相關文章
相關標籤/搜索