一、簡介

1.1 介紹

     Kafka是由Apache軟體基金會開發的一個開源流處理平臺，由Scala和Java編寫。

     Kafka是一種高吞吐量的分散式釋出訂閱訊息系統，它可以處理消費者規模的網站中的所有動作流資料。

特性：

    1.通過O(1)的磁碟資料結構提供訊息的持久化，這種結構對於即使數以TB的訊息儲存也能夠保持長時間的穩定效能。

    2.高吞吐量：即使是非常普通的硬體Kafka也可以支援每秒數百萬的訊息。

    3.支援通過

    4.支援Hadoop並行資料載入。

1.2 優點

    1）持續的訊息：為了從大資料中派生出有用的資料，任何資料的丟失都會影響生成的結果，kafka提供了一個複雜度為O(1)的磁碟結構儲存資料，即使是對於TB級別的資料都是提供了一個常量時間效能。

    2）高吞吐量：keep big data in mind，kafka採用普通的硬體支援每秒百萬級別的吞吐量

    3）分散式：明確支援訊息的分割槽，通過

    4）支援多種語言：java、.net、php、ruby、python。

    5）實時性：訊息被生成者執行緒生產就能馬上被消費者執行緒消費，這種特性和事件驅動的系統是相似的。

1.3 使用場景

    1）使用者的行為資料

    2）應用工程的效能資料

    3）日誌的使用者活動資料等

二、通訊方式

2.1 名詞解釋【重要

】

Producer：生產者，用於將流資料傳送到kafka訊息佇列上，它的任務是向Broker傳送資料。

Customer：消費者，與其它訊息中介軟體不同，它主動向broker拉message

Customer Group：消費者組，每個customer屬於一個特定的customer group，可以為每個customer指定一個group name。

Broker：代理，即一個kafka例項，即一個kafka程序，可以把Message持久化到本地磁碟；

    多個Broker即多個kafka例項構成kafka叢集；

    每個Cluster當中會選舉出一個Broker來擔任Controller，負責處理Partition的Leader選舉，協調Partition遷移等工作。Broker是無狀態的，消費狀態靠消費者維護的offset偏移量。

Topic：類別，主題

    每條釋出到kafka叢集的訊息都屬於一個類別，這個類別被稱為Topic；

    物理上：不同Topic的訊息分開儲存、

    邏輯上：一個Topic的訊息雖然保存於一個或多個Broker上，但使用者只需指定訊息的Topic，即可生產或消費資料，而不用關心資料存於何處。

    用於劃分message的邏輯概念，可以理解為message的類別，一個topic可以分佈於多個broker上，其資訊存於註冊中心。

Partition：分割槽

    每個topic至少有一個partion（即每個類別至少有一個分割槽），

    這個topic在每個broker上有多個分割槽partion（或無分割槽partion）都是ok的，即隨意。

    生產環境中分割槽數只能增不能

Offset：偏移量，offset是message在partition中的編號，offset編號不跨partition。

    partition中的訊息是有序的，

    偏移量記錄在註冊中心。

Topic和Partition

    該圖可以看到，訊息是按照類別topic來提交到partition當中的。

    Partition當中的訊息是有序的，consumer從一個有序的分割槽訊息佇列中順序獲取訊息。

相關名次定義如下：

    1.Topic：用於劃分Message的邏輯概念，一個Topic可以分佈在多個Broker上。
    2.Partition：是Kafka中橫向擴充套件和一切並行化的基礎，每個Topic都至少被切分為1個Partition。
    3.offset:訊息在Partition中的編號，編號順序不跨Partition。

Replication：備份機制，每個分割槽partition都有自己的映象分割槽來保證高可用，該分割槽和備份分割槽不在同一臺物理機上。

    其中一個分割槽為leader，若leader掛了則會選舉新的leader。 

    Replica個數為所有分割槽的份數，如下4個partition，2個replica。

AR(Assigned Replicas)：所有已註冊副本，AR = ISR + OSR。為保證高可用，引數offsets.topic.replication.factor設定大於1，比如3。

ISR(In-Sync Replicas)：副本同步佇列，由leader維護，follower從leader同步資料有一些延遲(包括延遲時間replica.lag.time.max.ms和延遲條數replica.lag.max.messages兩個維度,版本0.10.x中只支援replica.lag.time.max.ms這個維度) ，任意一個超過閾值都會把follower剔除出ISR, 存入OSR。

注：Kafka 0.10.x版本後移除了replica.lag.max.messages引數，只保留了replica.lag.time.max.ms作為ISR中副本管理的引數。為什麼這樣做呢？replica.lag.max.messages表示當前某個副本落後leaeder的訊息數量超過了這個引數的值，那麼leader就會把follower從ISR中刪除。假設設定replica.lag.max.messages=4，那麼如果producer一次傳送至broker的訊息數量都小於4條時，因為在leader接受到producer傳送的訊息之後而follower副本開始拉取這些訊息之前，follower落後leader的訊息數不會超過4條訊息，故此沒有follower移出ISR，所以這時候replica.lag.max.message的設定似乎是合理的。但是producer發起瞬時高峰流量，producer一次傳送的訊息超過4條時，也就是超過replica.lag.max.messages，此時follower都會被認為是與leader副本不同步了，從而被踢出了ISR。但實際上這些follower都是存活狀態的且沒有效能問題。那麼在之後追上leader,並被重新加入了ISR。於是就會出現它們不斷地剔出ISR然後重新迴歸ISR，這無疑增加了無謂的效能損耗。而且這個引數是broker全域性的。設定太大了，影響真正“落後”follower的移除；設定的太小了，導致follower的頻繁進出。無法給定一個合適的replica.lag.max.messages的值，故此，新版本的Kafka移除了這個引數。

OSR(Outof-Sync Replicas)：副本未同步佇列，ISR中超過閾值的flower會被踢出ISR加入OSR，新加入的flower也會先存放在OSR。

HW(High Watermark)：高水位，每個replica都有自己的HW，replica中各partition對應ISR最小(越小越舊)的LEO作為HW，即最後commit的offset，consumer最多隻能消費到HW所在的位置。

LEO(log end offset)：日誌尾部偏移量，每個partition都有自己的LEO，是每個partition日誌中的最後的offset，可能未被commit。

Coordinator：中心協調器，0.10.x版本及之後才有，為所有Consumer Group的子集選舉出一個Broker作為Coordinator，由它來管理Consumer的增減，然後生成Rebalance命令，並檢查是否這些Rebalance。

2.2 拓撲圖

    以下的元件在分散式環境中均可以是多個，

    ZK僅和Broker和Customer有關。

    Broker是無狀態的，消費的狀態依靠消費者維護partition的offset偏移量，message依靠消費者主動拉取。

    Brokers中的Controller，主要負責Partition管理和副本狀態管理，也會執行類似重分配partition之類的管理任務，如處理Partition的Leader選舉等。

2.3 區域性有序性

    Producer從0開始生產，進入不同的分割槽按進入順序從0開始排列，消費者從0開始消費，這就保證了單個分割槽的訊息有序性，但無法保證全域性有序性。

2.4 ZK儲存結構

說明： 本人原創，後續會繼續更新增加內容；

    如有錯誤之處，敬請指出，不勝感謝，共同學習共同進步