https://zhuanlan.zhihu.com/p/367683572
@TOC
<hr style=" border:solid; width:100px; height:1px;" color=#000000 size=1">
我們在業務開發的過程中，會涉及很多“事件驅動”的場景，比如：
處理IoT裝置上報的事件(如紅外傳感器檢測到有人經過、溫度傳感器檢測到溫度變化等等)；
實時監控金融使用者的行為，識别可疑行為并作攔截處理；
對微服務進行監控，實時上報服務的異常情況；
這些場景有一個共同的模式：有一個“事件源”、需要實時處理“事件序列”。
那麼問題來了，事件源通過什麼方式上報資料？上報來的事件資料如何存儲？如何實時感覺新事件的産生并作處理？于是，Kafka應運而生。
Kafka官方的定義是
Apache Kafka is an open-source distributed event streaming platform.
即一個開源的、分布式的事件流處理平台。起初由LinkedIn公司(沒錯，就是領英)研發，用于處理資料管道的問題。後LinkedIn将其貢獻給了Apache基金會，成為Apache的頂級項目之一。
Kafka采用"Producer -> Server -> Consumer"的業務模型來解決上文提到的實際問題：
Producer：生産者，事件源通過該元件上報事件資訊；
Server：對上報來的事件資料作持久化存儲，并通過精心設計的機制保證高吞吐量；
Consumer：負責從Server端實時拉取事件資料，以執行相應的業務處理；
這裡将通過“逐漸引入”的方式向諸君闡述Kafka架構中的核心概念(基于Kafka 2.0版本)。更多細節将通過後續文章從源碼層面給大家分析。
通過上文介紹，我們有了下圖：
3類元件的職責不再贅述。
實際應用中，一個Kafka叢集會承載很多類别的事件流。那麼不同僚件流之間如何作區分呢？實際上，Kafka使用"釋出訂閱模式"組織事件資料，為一類事件流配置設定一個主題(Topic)。Producer可将事件發到某個Topic下，Consumer可以訂閱其感興趣的Topic，進而可以處理對應的事件流。
對于Kafka的目标場景，"高吞吐"是很必要的。而對于提高吞吐量，增加并行度是很常見的手段。在Kafka業務模型下展現在一個Topic允許多個Consumer同時消費資料。可是并行操作同一份資料的話，就需要完善的同步機制，而同步本身又不利于提高吞吐。是以，Kafka将一個Topic下的資料橫向分成了多個"分區"(Partition)，而每個Partition隻允許一個Consumer來消費。那麼如何決定将一個Partition分給哪個Consumer呢？Kafka引入了ConsumerGroup的概念，即将訂閱同一個Topic的多個Consumer打成"組"，然後在将Topic内的Parition通過一定的算法配置設定給組内的Consumer。
考慮一個問題，如果Parition對應的檔案損壞，或者Partition所在機器下線，那是否就意味着這部分資料就丢失了？為了避免這類資料單點問題，Kafka引入了Replica(副本)的概念：
一個Partition的資料會同時儲存N份，即N個Replica；
Replica之間有"主從"之分，Producer将資料寫入主Replica中，從Replica異步到主Replica拉資料以實作同步；
Producer在産生資料時可以指定acks參數，表示本次寫入需要有多少個從Replica完成同步才視為成功；
當主Replica損壞或當機時，其中一個從Replica會被選舉為主Replica；
到目前為止，我們都是将"服務端"視為一個整體，接下來就介紹下服務端節點組成。Kafka Server端有多個節點組成，每個節點都有一個名字叫Broker。其中一個Broker會被選舉稱為KafkaController，用于監測所有Broker的狀态，發現故障後啟動故障轉移過程。例如，假設Broker_1上承載兩個Replica，分别為Partition_1-1的主Replica和Partition_1-2的從Replica；若Broker_1當機，KafkaController會将Broker_2上的Partition_1-1的從Replica提升為主Replica，使得叢集可以繼續對外提供服務。
Kafka官方源碼位址：https://github.com/apache/kafka
我也維護了一個"注釋版"Kafka源碼鏡像，供諸君參考:
https://github.com/Hao1296/kafka (見note-hao分支，基于Kafka 2.0)
Kafka核心目錄如下：
clients: 用戶端實作源碼，包括Producer和Consumer
core: 服務站實作源碼
connect: connector實作源碼，用于執行Kafka資料的導入/導出
stream: 流式計算相關源碼
本文作為Kafka源碼分析系列文章的概述，宏觀簡要介紹了下Kafka的基本原理，沒有深入。更多細節會在後續文章中逐個分析。Kafka源碼分析系列文章目錄: https://zhuanlan.zhihu.com/p/367683572，歡迎諸君随時交流。
微信搜尋"村口老張頭"，不定時推送技術文章哦~
也可以在知乎搜尋"村口老張頭"哦~