kafka学习_Kafka 学习笔记01
Kafka概念和基本架構概述
以下內容來自拉勾課程學習拉勾教育 - 拉勾旗下教育平臺一、Kafka介紹
Kafka是最初由 Linkedin 公司開發(fā)，是一個 分布式、分區(qū)的、多副本的、多生產者、多訂閱者，基于zookeeper協(xié)調的分布式日志系統(tǒng)（也可以當做MQ系統(tǒng)）。常見可以用于web/nginx日志、訪問日志，消息服務等等。
Linkedin于2010年貢獻給了Apache基金會并成為頂級開源項目。主要應用場景是：
- 日志收集系統(tǒng)
- 消息系統(tǒng)
Kafka主要設計目標如下：
1. 以時間復雜度為O(1)的方式提供消息持久化能力，即使對 TB級 以上數(shù)據也能保證常數(shù)時間的訪問性能。
2. 高吞吐率。即使在非常廉價的商用機器上也能做到 單機支持 每秒100K條 消息的傳輸。
3. 支持Kafka Server間的消息分區(qū)，及分布式消費，同時保證每個partition內的消息順序傳輸。
4. 同時支持離線數(shù)據處理和實時數(shù)據處理。
5. 支持在線水平擴展。
有兩種主要的消息傳遞模式：
- 點對點傳遞模式
- 發(fā)布-訂閱模式
大部分的消息系統(tǒng)選用發(fā)布-訂閱模式。Kafka就是一種發(fā)布-訂閱模式
對于消息中間件，消息分推拉兩種模式。Kafka只有消息的拉取，沒有推送，可以通過輪詢實現(xiàn)消息的推送。
1. Kafka在一個或多個可以跨越多個數(shù)據中心的服務器上作為集群運行。
2. Kafka集群中按照主題分類管理，一個主題可以有多個分區(qū)，一個分區(qū)可以有多個副本分區(qū)。
3. 每個記錄由一個鍵，一個值和一個時間戳組成。
Kafka具有四個核心API：
1. Producer API：允許應用程序將記錄流發(fā)布到一個或多個Kafka主題。
2. Consumer API：允許應用程序訂閱一個或多個主題并處理為其生成的記錄流。
3. Streams API：允許應用程序充當流處理器，使用一個或多個主題的輸入流，并生成一個或多個輸出主題的輸出流，從而有效地將輸入流轉換為輸出流。
4. Connector API：允許構建和運行將Kafka主題連接到現(xiàn)有應用程序或數(shù)據系統(tǒng)的可重用生產者或使用者。例如，關系數(shù)據庫的連接器可能會捕獲對表的所有更改。 二、Kafka優(yōu)勢
1. 高吞吐量：單機每秒處理幾十上百萬的消息量。即使存儲了許多TB的消息，它也保持穩(wěn)定的性能。
2. 高性能：單節(jié)點支持上千個客戶端，并保證零停機和零數(shù)據丟失。
3. 持久化數(shù)據存儲：將消息持久化到磁盤。通過將數(shù)據持久化到硬盤以及replication防止數(shù)據丟失。
1. 零拷貝
2. 順序讀，順序寫
3. 利用Linux的頁緩存
4. 分布式系統(tǒng)，易于向外擴展。所有的Producer、Broker和Consumer都會有多個，均為分布式的。
無需停機即可擴展機器。多個Producer、Consumer可能是不同的應用。
5. 可靠性 - Kafka是分布式，分區(qū)，復制和容錯的。
6. 客戶端狀態(tài)維護：消息被處理的狀態(tài)是在Consumer端維護，而不是由server端維護。當失敗時能自動平衡。
7. 支持online和offline的場景。
9. 支持多種客戶端語言。Kafka支持Java、.NET、PHP、Python等多種語言。 三、Kafka應用場景
日志收集：
一個公司可以用Kafka可以收集各種服務的Log，通過Kafka以統(tǒng)一接口服務的方式開放給各種Consumer；
消息系統(tǒng)：
解耦生產者和消費者、緩存消息等；
用戶活動跟蹤：
Kafka經常被用來記錄Web用戶或者App用戶的各種活動，如瀏覽網頁、搜索、點擊等活動。
這些活動信息被各個服務器發(fā)布到Kafka的Topic中，然后消費者通過訂閱這些Topic來做實時的監(jiān)控分析，亦可保存到數(shù)據庫；
運營指標：
Kafka也經常用來記錄運營監(jiān)控數(shù)據。包括收集各種分布式應用的數(shù)據，生產各種操作的集中反饋，比如報警和報告；
流式處理：
比如Spark Streaming和Storm。
四、基本架構 消息和批次
Kafka的數(shù)據單元稱為消息。可以把消息看成是數(shù)據庫里的一個“數(shù)據行”或一條“記錄”。消息由字節(jié)數(shù)組組成。
消息有鍵，鍵也是一個字節(jié)數(shù)組。當消息以一種可控的方式寫入不同的分區(qū)時，會用到鍵。
為了提高效率，消息被分批寫入Kafka。批次就是一組消息，這些消息屬于同一個主題和分區(qū)。
把消息分成批次可以減少網絡開銷。批次越大，單位時間內處理的消息就越多，單個消息的傳輸時間就越長。批次數(shù)據會被壓縮，這樣可以提升數(shù)據的傳輸和存儲能力，但是需要更多的計算處理。
模式
消息模式（schema）有許多可用的選項，以便于理解。如JSON和XML，但是它們缺乏強類型處理能力。Kafka的許多開發(fā)者喜歡使用Apache Avro。Avro提供了一種緊湊的序列化格式，模式和消息體分開。當模式發(fā)生變化時，不需要重新生成代碼，它還支持強類型和模式進化，其版本既向前兼容，也向后兼容。
數(shù)據格式的一致性對Kafka很重要，因為它消除了消息讀寫操作之間的耦合性。
主題和分區(qū)
Kafka的消息通過主題進行分類。主題可比是數(shù)據庫的表或者文件系統(tǒng)里的文件夾。
主題可以被分為若干分區(qū)，一個主題通過分區(qū)分布于Kafka集群中，提供了橫向擴展的能力。
生產者和消費者
生產者創(chuàng)建消息。消費者消費消息。
一個消息被發(fā)布到一個特定的主題上。
生產者在默認情況下把消息均衡地分布到主題的所有分區(qū)上：
1. 直接指定消息的分區(qū)
2. 根據消息的key散列取模得出分區(qū)
3. 輪詢指定分區(qū)。
消費者通過偏移量來區(qū)分已經讀過的消息，從而消費消息。
消費者是消費組的一部分。消費組保證每個分區(qū)只能被一個消費者使用，避免重復消費。
broker和集群
一個獨立的Kafka服務器稱為broker。
broker接收來自生產者的消息，為消息設置偏移量，并提交消息到磁盤保存。
broker為消費者提供服務，對讀取分區(qū)的請求做出響應，返回已經提交到磁盤上的消息。
單個broker可以輕松處理數(shù)千個分區(qū)以及每秒百萬級的消息量。
每個集群都有一個broker是集群控制器（自動從集群的活躍成員中選舉出來）。
控制器負責管理工作：
將分區(qū)分配給broker
監(jiān)控broker
集群中一個分區(qū)屬于一個broker，該broker稱為分區(qū)首領。
一個分區(qū)可以分配給多個broker，此時會發(fā)生分區(qū)復制。
分區(qū)的復制提供了消息冗余， 高可用 。副本分區(qū)不負責處理消息的讀寫。 五、核心概念 1.1.5.1 Producer
生產者創(chuàng)建消息。
該角色將消息發(fā)布到Kafka的topic中。broker接收到生產者發(fā)送的消息后，broker將該消息追加到當前用于追加數(shù)據的 segment 文件中。
一般情況下，一個消息會被發(fā)布到一個特定的主題上。
1. 默認情況下通過輪詢把消息均衡地分布到主題的所有分區(qū)上。
2. 在某些情況下，生產者會把消息直接寫到指定的分區(qū)。
這通常是通過消息鍵和分區(qū)器來實現(xiàn)的，分區(qū)器為鍵生成一個散列值，并將其映射到指定的分區(qū)上。
這樣可以保證包含同一個鍵的消息會被寫到同一個分區(qū)上。
3. 生產者也可以使用自定義的分區(qū)器，根據不同的業(yè)務規(guī)則將消息映射到分區(qū)。 1.1.5.2 Consumer
消費者讀取消息。
1. 消費者訂閱一個或多個主題，并按照消息生成的順序讀取它們。
2. 消費者通過檢查消息的偏移量來區(qū)分已經讀取過的消息。
偏移量是另一種元數(shù)據，它是一個不斷遞增的整數(shù)值，在創(chuàng)建消息時，Kafka 會把它添加到消息里。
在給定的分區(qū)里，每個消息的偏移量都是唯一的。
消費者把每個分區(qū)最后讀取的消息偏移量保存在 **Zookeeper** 或 Kafka上 ，如果消費者關閉或重啟，它的讀取狀態(tài)不會丟失。
3. 消費者是消費組的一部分。群組保證每個分區(qū)只能被一個消費者使用。
4. 如果一個消費者失效，消費組里的其他消費者可以接管失效消費者的工作，再平衡，分區(qū)重新分配。
1.1.5.3 Broker
一個獨立的Kafka 服務器被稱為broker。
broker 為消費者提供服務，對讀取分區(qū)的請求作出響應，返回已經提交到磁盤上的消息。
1. 如果某topic有N個partition，集群有N個broker，那么每個broker存儲該topic的一個partition。
2. 如果某topic有N個partition，集群有(N+M)個broker，那么其中有N個broker存儲該topic的一個partition，
剩下的M個broker不存儲該topic的partition數(shù)據。
3. 如果某topic有N個partition，集群中broker數(shù)目少于N個，那么一個broker存儲該topic的一個或多個partition。
在實際生產環(huán)境中，盡量避免這種情況的發(fā)生，這種情況容易導致Kafka集群數(shù)據不均衡。
broker 是集群的組成部分。
每個集群都有一個broker 同時充當了集群控制器的角色（自動從集群的活躍成員中選舉出來）。
控制器負責管理工作，包括將分區(qū)分配給broker 和監(jiān)控broker。
在集群中，一個分區(qū)從屬于一個broker，該broker 被稱為分區(qū)的首領。
1.1.5.4 Topic
每條發(fā)布到Kafka集群的消息都有一個類別，這個類別被稱為Topic。
物理上不同Topic的消息分開存儲。
主題就好比數(shù)據庫的表，尤其是分庫分表之后的邏輯表。
1.1.5.5 Partition
1.1.5.6 Replicas
Kafka 使用主題來組織數(shù)據，每個主題被分為若干個分區(qū)，每個分區(qū)有多個副本。那些副本被保存在broker 上，每個broker 可以保存成百上千個屬于不同主題和分區(qū)的副本。
副本有以下兩種類型： 首領副本
每個分區(qū)都有一個首領副本。為了保證一致性，所有生產者請求和消費者請求都會經過這個副本。
跟隨者副本
首領以外的副本都是跟隨者副本。跟隨者副本不處理來自客戶端的請求，它們唯一的任務就是從首領那里復制消息，保持與首領一致的狀態(tài)。 如果首領發(fā)生崩潰，其中的一個跟隨者會被提升為新首領。
1.1.5.7 Offset
生產者Offset
消息寫入的時候，每一個分區(qū)都有一個offset，這個offset就是生產者的offset，同時也是這個分區(qū)的最新最大的offset。
有些時候沒有指定某一個分區(qū)的offset，這個工作kafka幫我們完成。
消費者Offset
這是某一個分區(qū)的offset情況，生產者寫入的offset是最新最大的值是12，而當Consumer A進行消費時，從0開始消費，一直消費到了9，消費者的offset就記錄在9，Consumer B就紀錄在了11。等下一次他們再來消費時，他們可以選擇接著上一次的位置消費，當然也可以選擇從頭消費，或者跳到最近的記錄并從“現(xiàn)在”開始消費。
1.1.5.8 副本
Kafka通過副本保證高可用。副本分為首領副本(Leader)和跟隨者副本(Follower)。
跟隨者副本包括同步副本和不同步副本，在發(fā)生首領副本切換的時候，只有同步副本可以切換為首領副本。
1.1.5.8.1 AR
分區(qū)中的所有副本統(tǒng)稱為AR（Assigned Repllicas）。AR=ISR+OSR
1.1.5.8.2 ISR
所有與leader副本保持一定程度同步的副本（包括Leader）組成ISR（In-Sync Replicas），ISR集合是AR集合中的一個子集。消息會先發(fā)送到leader副本，然后follower副本才能從leader副本中拉取消息進行同步，同步期間內follower副本相對于leader副本而言會有一定程度的滯后。前面所說的“一定程度”是指可以忍受的滯后范圍，這個范圍可以通過參數(shù)進行配置。
1.1.5.8.3 OSR
與leader副本同步滯后過多的副本（不包括leader）副本，組成OSR(Out-Sync Relipcas)。在正常情況下，所有的follower副本都應該與leader副本保持一定程度的同步，即AR=ISR,OSR集合為空。
1.1.5.8.4 HW
HW是High Watermak的縮寫， 俗稱高水位，它表示了一個特定消息的偏移量（offset），消費之只能拉取到這個offset之前的消息。
1.1.5.8.5 LEO
LEO是Log End Offset的縮寫，它表示了當前日志文件中下一條待寫入消息的offset。
總結
以上是生活随笔為你收集整理的kafka学习_Kafka 学习笔记01的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： android 代码 shape,And
- 下一篇： html td装满图片,HTML：桌子上