來源 | http://r6d.cn/bdjdi
Kafka概述：
Kafka由 linked-in 開源 。
kafka-高產出的分佈式消息系統(A high-throughput distributed messaging system)。
Kafka是一個高吞吐、分佈式、基於發佈訂閱的消息系統，利用Kafka技術可以在廉價的PC Server上搭建起大規模消息系統。
Kafka的特性：
-
高吞吐量、低延遲：kafka每秒可以處理幾十萬條消息，它的延遲最低只有幾毫秒，每個topic可以分多個partition, consumer group 對partition進行consume操作； -
可擴展性：kafka集羣支持熱擴展； -
持久性、可靠性：消息被持久化到本地磁盤，並且支持數據備份防止數據丟失； -
容錯性：允許集羣中節點失敗（若副本數量爲n,則允許n-1個節點失敗）； -
高併發：支持數千個客戶端同時讀寫； -
支持實時在線處理和離線處理：可以使用Storm這種實時流處理系統對消息進行實時進行處理，同時還可以使用Hadoop這種批處理系統進行離線處理；
Kafka應用場景：
Kafka和其他組件比較，具有消息持久化、高吞吐、分佈式、多客戶端支持、實時等特性，適用於離線和在線的消息消費，如常規的消息收集、網站活性跟蹤、聚合統計系統運營數據（監控數據）、日誌收集等大量數據的互聯網服務的數據收集場景。
-
日誌收集：一個公司可以用Kafka可以收集各種服務的log，通過kafka以統一接口服務的方式開放給各種consumer，例如Hadoop、Hbase、Solr等；
-
消息系統：解耦和生產者和消費者、緩存消息等；
-
用戶活動跟蹤：Kafka經常被用來記錄web用戶或者app用戶的各種活動，如瀏覽網頁、搜索、點擊等活動，這些活動信息被各個服務器發佈到kafka的topic中，然後訂閱者通過訂閱這些topic來做實時的監控分析，或者裝載到Hadoop、數據倉庫中做離線分析和挖掘；
-
運營指標：Kafka也經常用來記錄運營監控數據。包括收集各種分佈式應用的數據，生產各種操作的集中反饋，比如報警和報告；
-
流式處理：比如spark streaming和storm；
-
事件源；
-
kafka在FusionInsight中的位置：
Kafka作爲一個分佈式消息系統，支持在線和離線消息處理，並提供了Java API以便其他組件對接使用。
Kafka架構與功能
Kafka架構：
基本概念：
-
Broker：Kafka集羣包含一個或多個服務實例，這些服務實例被稱爲Broker。是Kafka當中具體處理數據的單元。Kafka支持Broker的水平擴展。一般Broker數據越多，集羣的吞吐力就越強。 -
Topic：每條發佈到Kafka集羣的消息都有一個類別，這個類別被稱爲Topic。 -
Partition：Kafka將Topic分成一個或多個Partition，每個Partition在物理上對應一個文件夾，該文件下存儲這個Partition的所有消息。 -
Producer：負責發佈消息到Kafka Broker。 -
Consumer：消息消費者，從Kafka Broker讀取消息的客戶端。 -
Consumer Group：每個Consumer屬於一個特定的Consumer Group（可爲每個Consumer指定group name）。 -
ZooKeeper：kafka與Zookeeper級聯，通過Zookeeper管理級聯配置，選舉Leader。
Kafka Topics：
每條發佈到Kafka的消息都有個類別，這個類別被稱爲Topic，也可以理解爲一個存儲消息的隊列。例如：天氣作爲一個Topic，每天的溫度消息就可以存儲在“天氣”這個隊列裏。數據總數先進先出。後來的數據追加到後面。
Kafka Partition：
每個Topic都有一個或者多個Partitions構成。每個Partition都是有序且不可變的消息隊列。引入Partition機制，保證了Kafka的高吞吐能力。
在每個Partition當中，都會存儲一個Log文件，Log文件中記錄了所有的消息文件。一個Topic的多個Partition，它分佈在不同的Kafka節點上，這樣多個客戶端包括Producer和Consumer就可以併發的訪問不同節點，對同一個Topic進行消息的讀取。
-
Topic的Partition數量可以在創建時配置。 -
Partition數據決定了每個Consumer group中併發消費者的最大數據。 -
Consumer group A有兩個消費者來讀取4個Partition中數據；Consumer group B有四個消費者來讀取4個partition中數據。
Kafka Partition offset:
-
任何發佈到此Partition的消息都會被直接追加到log文件的尾部。 -
每條消息在文件中的位置稱爲offset（偏移量），offset是一個long型數字，它唯一標記一條消息。消費者通過（offset、partition、topic）跟蹤記錄。 -
Kafka不支持消息的隨機讀取。
Kafak Partition Replicas（副本）:
-
副本以分區爲單位。每個分區都有各自的主副本。 -
可以通過配置文件，配置副本的個數。 -
一個Kafka集羣中，各個節點可能互爲Leader和Follower。 -
主副本叫做Leader，從副本叫做Follower，處於同步狀態的副本叫做In-Sync Replicas（ISR）。 -
如果Leader失效，那麼將會有其他的Follower來接管成爲新的Leader。如果由於Follower自身的原因，比如網絡原因導致同步落後太多，那麼當Leader失效後，就不會將這個Follower選爲leader。 -
由於Leader的Server承載了全部的請求壓力，因此從集羣的整體考慮，Kafka會將Leader均衡的分散在每個實例上，來保持整體穩定。 -
Follower通過 拉取的方式從Leader中同步數據。消費者和生產這都是從Leader中讀取數據，不與Follower交互。
主副本和從副本的數據同步：
從Partition的Leader複製數據到Follower，需要一個線程，實際上，複製數據的操作，是Follower主動從Leader上批量拉取數據，這就極大的提高了Kafka的吞吐量。Follower複製數據的線程叫做ReplicaFetcher Thread，而Kafka的Producer和Consumer只與Leader進行交互，不會與Follower進行交互。
Kafka中每個Broker啓動的時候，都會創建一個副本管理服務ReplicaManager，該服務負責維護ReplicaFether Thread與其他Broker鏈路連接關係。該服務中存在的Follower Partition對應的Leader Partition會分佈在不同的Broker上，這些Broker創建相同數量的ReplicaFether Thread，同步對應Partition數據。Kafka中Partition間複製數據，是由Follower主動從Leader拉消息的。Follower每次讀取消息都會更新HW狀態，用於記錄當前最新消息的標識。每當Follower的Partition發生變化而影響Leader所在的Broker時，ReplicaManager就會新建或者銷燬相對應的ReplicaFether Thread。
Kafka Logs：
爲了使得Kafka的吞吐率可以線性提高，物理上把Topic分成一個或多個Partition，每個Partition在物理上對應一個文件夾，該文件夾下存儲這個Partition的所有消息和索性文件。Kafka把Topic中一個Partition大文件分成多個小文件段通過多個小文件段，就容易定期清除或刪除已經消費完的文件，減少磁盤佔用。
Kafka的存儲佈局非常簡單，Topic的每個分區對應一個邏輯日誌，物理上一個日誌爲相同大小的一個分段文件。每次Producer發佈一個消息到一個分區的時候，代理就將這些數據追加到最後一個段文件當中。當發佈的消息數量達到消息設定的閾值，或者經過一定的時間後，段文件就會真正的寫到磁盤當中。在寫入完成以後，消息就會公開給Consumer。
同一個Topic下有不同的分區，每個分區會劃分爲多個文件，只有一個當前文件在寫，其他文件是隻讀的。當寫滿一個文件（即達到某個設定的值）Kafka會新建一個空文件繼續來寫。而老文件切換爲只讀。
文件的命名以起始的偏移量來進行命名。Segment Files由兩大部分組成，分別爲Index file和data file，此兩個文件一一對應成對出現。後綴 .index 和 .log 就分別表示爲Segment的索引文件和數據文件。Segment文件的命名規則是：Partition全局的第一個Segment從0開始，後續每個segment文件爲上一個全局Partition的最大offset，這個數據時64位的long型數據。如果沒有數據就用0進行填充。通常把日誌文件默認爲1G，當達到1G就會創建新的Log文件和index文件。如果設置的參數過小，會產生大量的log文件和index文件，系統在啓動的時候就需要加載大量的index到內存，佔用大量的句柄。如果設置的太大，分段文件又比較少，不利於快速的查找。Kafka就是通過索引實現快速的定位message。
-
通過索引信息可以快速定位message。 -
通過將index元數據全部映射到memory，可以避免segment file的index數據IO磁盤操作。 -
通過索引文件稀疏存儲，可以大幅降低index文件元數據佔用空間大小。 -
稀疏存儲：將原來完整的數據，只間隔的選擇多條數據進行存儲。
Kafka Log Cleanup:
日誌的清理方式有兩種：delete和compact。
刪除的閾值有兩種：過期的時間和分區內總日誌大小。
compact操作是保存每個消息的最新value值。消息時順序存儲的，offset大的爲最新的數據。
Kafka數據可靠性：
Kafka所有消息都會被持久化到磁盤中，同時Kafka通過對Topic Partition設置Replication來保障數據可靠。
消息傳輸過程中保障通常有以下三種：
-
最多一次（At Most Once）：消息可能丟失；消息不會重複發送和處理。 -
最少一次（At Lease Once）：消息不會丟失；消息可能會重複發送和處理。 -
僅有一次（Exactly Once）：消息不會丟失；消息僅被處理一次。
Kafka消息傳輸保障機制，通過配置不同的消息發送模式來保障消息傳輸，進而滿足不同的可靠性要求應用場景。
可靠
Kafka關鍵流程
寫流程：
總體流程：
-
Producer連接任意存活的Broker，請求制定Topic、Partition的Leader元數據信息，然後直接與對應的Broker直接鏈接，發佈數據。
開發分區接口：
-
用戶可以指定分區函數，使得消息可以根據Key，發送到特定的Partition。
Kafka讀流程：
總體流程：
-
Consumer連接指定Topic Partition所在的Leader Broker，用主動獲取方式從Kafka中獲取消息。
Kafka在Zookeeper上的目錄結構
Zookeeper在Kafka的作用：
-
無論是kafka集羣，還是producer和consumer都依賴於zookeeper來保證系統可用性集羣保存一些meta信息。 -
Kafka使用zookeeper作爲其分佈式協調框架，很好的將消息生產、消息存儲、消息消費的過程結合在一起。 -
同時藉助zookeeper，kafka能夠生產者、消費者和broker在內的所以組件在無狀態的情況下，建立起生產者和消費者的訂閱關係，並實現生產者與消費者的負載均衡。
Zookeeper Shell：
通過zkCli來連接正在運行的Zookeeper Shell客戶端，可以通過ls和get命令來獲取Kafka相關信息。
Kafka in ZooKeeper：
圖：Kafka在ZooKeeper中的目錄結構
Kafka Cluster Mirroring
圖：Kafka CLuster Mirroring Kafka Cluster Mirroring是Kafka跨集羣數據同步方案，通過Kafka內置的MirrorMaker工具來實現。通過Mirror Maker工具中的consumer從源集羣消費數據，然後再通過內置的Producer，將數據重新發布到目標集羣。
個人博客網站：https://programmerblog.xyz
本文分享自微信公衆號 - IT技術分享社區（gh_a27c0758eb03）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。