一、簡介
Kafka是一種高吞吐量的分佈式發佈訂閱消息系統，它可以處理消費者規模的網站中的所有動作流數據。 這種動作（網頁瀏覽，搜索和其他用戶的行動）是在現代網絡上的許多社會功能的一個關鍵因素。 這些數據通常是由於吞吐量的要求而通過處理日誌和日誌聚合來解決。 對於像Hadoop一樣的日誌數據和離線分析系統，但又要求實時處理的限制，這是一個可行的解決方案。Kafka的目的是通過Hadoop的並行加載機制來統一線上和離線的消息處理，也是爲了通過集羣來提供實時的消息。
二、名詞解釋
- Producer：消息和數據的生產者，向Kafka的一個topic發佈消息的進程/代碼/服務
- Consumer：消息和數據的消費者，訂閱數據（Topic）並且處理其發佈的消息的進程/代碼/服務
- Consumer Group：邏輯概念，對於同一個topic，會廣播給不同的group，一個group中，只有一個consumer可以消費該消息
- Broker：物理概念，Kafka集羣中的每個Kafka節點
- Topic：邏輯概念，Kafka消息的類別，對數據進行區分、隔離
- Partition：物理概念，Kafka下數據存儲的基本單元。一個Topic數據會被分散存儲到多個Partition，每一個Partition是有序的
1）每一個Topic被切分爲多個Partitions
2）消費者數目少於或等於Partition的數目
3）Broker Group中的每一個Broker保存Topic的一個或多個Partitions
4）Consumer Group中的僅有一個Consumer讀取Topic的一個或多個Partitions，並且是唯一的Consumer
- Replication：同一個Partition可能會有多個Replication，多個Replication之間數據是一樣的
1）當集羣中有Broker掛掉的情況，系統可以主動地使Replication提供服務
2）系統默認設置每一個Topic的replication係數爲1，可以在創建Topic時單獨設置
3）Replication的基本單位時Topic的Partition
4）所有的讀和寫都從Leader進，Followers只是作爲備份
5）Follower必須能夠及時複製Leader的數據
- Replication Leader：一個Partition的多個Replication上，需要一個Leader負責該Partition上與Producer和Consumer交互
- ReplicationManager：負責管理當前broker所有分區和副本的信息，處理KafkaController發起的一些請求，副本狀態的切換、添加/讀取消息等
三、基本結構
一個典型的Kafka集羣中包含若干Producer（可以是web前端FET，或者是服務器日誌等），若干broker（Kafka支持水平擴展，一般broker數量越多，集羣吞吐率越高），若干ConsumerGroup，以及一個Zookeeper集羣。Kafka通過Zookeeper管理Kafka集羣配置：選舉Kafka broker的leader，以及在Consumer Group發生變化時進行rebalance，因爲consumer消費kafka topic的partition的offsite信息是存在Zookeeper的。Producer使用push模式將消息發佈到broker，Consumer使用pull模式從broker訂閱並消費消息。
四、Kafka消息事務
數據傳輸的事務定義
- 最多一次：消息不會被重複發送，最多被傳輸一次，但也有可能一次不傳輸
- 最少一次：消息不會被漏發送，最少被傳輸一次，但也有可能被重複傳輸
- 精確的一次（Exactly once)：不會漏傳輸也不會重複傳輸，每個消息都被傳輸一次而且僅僅被傳輸一次，這是大家所期望的
事務保證
- 內部重試問題：Procedure冪等處理
- 多分區原子寫入
保證-避免殭屍實例
- 每個事務Producer分配一個transactional.id，在進程重新啓動時能夠識別相同的Producer實例
- Kafka增加了一個與transactional.id相關的epoch，存儲每個transactional.id內部元數據
- 一旦epoch被觸發，任何具有相同的transactional.id和更舊的epoch的Producer被視爲殭屍，Kafka會拒絕來自這些Procedure的後續事務性寫入