首先貼出官網地址：https://kafka.apache.org/
一、 簡介
Kafka 是 linkedin 使用 Scala 編寫具有高水平擴充套件和高吞吐量的分散式訊息系統。Kafka 對訊息儲存時根據 Topic 進行歸類，傳送訊息者成為 Producer ，訊息接受者成為 Consumer ，此外 kafka 叢集有多個 kafka 例項組成，每個例項(server)稱為 broker。無論是 Kafka叢集，還是 producer 和 consumer 都依賴於 zookeeper 來保證系統可用性，為叢集儲存一些 meta 資訊。（但新版本除外，不用依賴zookeeper）
二、常用MQ效能對比
三、kafa主要功能
Apache Kafka® 是 一個分散式流處理平臺
流處理平臺特性
- 可以讓你釋出和訂閱流式的記錄。這一方面與訊息佇列或者企業訊息系統類似。
- 可以儲存流式的記錄，並且有較好的容錯性。
- 可以在流式記錄產生時就進行處理。
Kafka 適合什麼樣的場景
- 構造實時流資料管道，它可以在系統或應用之間可靠地獲取資料。 (相當於訊息佇列)
- 構建實時流式應用程式，對這些流資料進行轉換或者影響。
四、kafa相關概念
AMQP (Advanced Message Queuing Protocol) ，是一個提供統一訊息服務的標準高階訊息佇列協議，是應用層協議的一個開放標準，為面向訊息的中介軟體而設計。
一些基本的概念：
AMQP伺服器端（broker）：用來接收生產者傳送的訊息並將這些訊息路由給伺服器中的佇列
消費者（Consumer）：從訊息佇列中請求訊息的客戶端應用程式
生產者（Producer）：向 broker 釋出訊息的客戶端應用程式
Topics 和 Logs
Topic 就是資料主題，是資料記錄釋出的地方，可以用來區分業務系統。Kafka 中的 Topics 總是多訂閱者模式，一個 topic 可以擁有一個或者多個消費者來訂閱它的資料。對於每一個topic，Kafka叢集都會維持一個分割槽日誌，如圖所示：
Partition
每一個分割槽都是一個順序的、不可變的訊息佇列， 並且可以持續的新增。分割槽中的訊息都被分了一個序列號，稱之為偏移量(offset)，在每個分割槽中此偏移量都是唯一的。Kafka叢集保持所有的訊息，直到它們過期， 無論訊息是否被消費了。 實際上消費者所持有的僅有的後設資料就是這個偏移量，也就是消費者在這個log中的位置。 這個偏移量由消費者控制：正常情況當消費者消費訊息的時候，偏移量也線性的的增加。但是實際偏移量由消費者控制，消費者可以將偏移量重置為更老的一個偏移量，重新讀取訊息。 可以看到這種設計對消費者來說操作自如， 一個消費者的操作不會影響其它消費者對此log的處理。kafka 並沒有提供其他額外的索引機制來儲存 offset，因為在 kafka 中幾乎不允許對訊息進行“隨機讀寫”。再說說分割槽。Kafka中採用分割槽的設計有幾個目的。一是可以處理更多的訊息，不受單臺伺服器的限制。Topic擁有多個分割槽意味著它可以不受限的處理更多的資料。第二，分割槽可以作為並行處理的單元
Distribution
Log 的分割槽被分佈到叢集中的多個伺服器上，每個伺服器處理它分到的分割槽， 根據配置每個分割槽還可以複製到其它伺服器作為備份容錯。每個分割槽有一個 leader，零或多個 follower。Leader 處理此分割槽的所有的讀寫請求，而 follower 被動的複製資料。如果 leader 當機，其它的一個 follower 會被推舉為新的 leader。 一臺伺服器可能同時是一個分割槽的 leader，另一個分割槽的 follower。 這樣可以平衡負載，避免所有的請求都只讓一臺或者某幾臺伺服器處理。
Producers
生產者往某個Topic上釋出訊息，生產者也負責選擇釋出到Topic上的哪一個分割槽。最簡單的方式從分割槽列表中輪流選擇，也可以根據某種演算法依照權重選擇分割槽。開發者負責如何選擇分割槽的演算法。
Consumers
消費者使用一個消費組名稱來進行標識，釋出到 topic 中的每條記錄被分配給訂閱消費組中的一個消費者例項。消費者例項可以分佈在多個程式中或者多個機器上。
如果所有的消費者例項在同一消費組中，訊息記錄會負載平衡到每一個消費者例項。
如果所有的消費者例項在不同的消費組中，每條訊息記錄會廣播到所有的消費者程式。
如圖，這個 Kafka 叢集有兩臺 server 的，四個分割槽(p0-p3)和兩個消費者組。消費組A有兩個消費者，消費組B有四個消費者。通常情況下，每個 topic 都會有一些消費組，一個消費組對應一個"邏輯訂閱者
"。一個消費組由許多消費者例項組成，便於擴充套件和容錯。這就是釋出和訂閱的概念，只不過訂閱者是一組消費者而不是單個的程式。在Kafka中實現消費的方式是將日誌中的分割槽劃分到每一個消費者例項上，以便在任何時間，每個例項都是分割槽唯一的消費者。維護消費組中的消費關係由Kafka協議動態處理。如果新的例項加入組，他們將從組中其他成員處接管一些 partition 分割槽;如果一個例項消失，擁有的分割槽將被分發到剩餘的例項。Kafka 只保證分割槽內的記錄是有序的，而不保證主題中不同分割槽的順序。每個 partition 分割槽按照key值排序足以滿足大多數應用程式的需求。但如果你需要總記錄在所有記錄的上面，可使用僅有一個分割槽的主題來實現，這意味著每個消費者組只有一個消費者程式。
Replication
每個partition還會被複制到其它伺服器作為replication，這是一種冗餘備份策略
- 同一個partition的多個replication不允許在同一broker上
- 每個partition的replication中，有一個leader ，零或多個follower
- leader處理此分割槽的所有的讀寫請求， follower僅僅被動的複製資料
- leader當機後，會從follower中選舉出新的leader
四個核心 API
- Producer API：允許一個應用程式釋出一串流式的資料到一個或者多個 Kafka topic。
- Consumer API：允許一個應用程式訂閱一個或多個 topic ，並且對釋出給他們的流式資料進行處理。
- Streams API：允許一個應用程式作為一個流處理器，消費一個或者多個 topic 產生的輸入流，然後生產一個輸出流到一個或多個 topic 中去，在輸入輸出流中進行有效的轉換。
- Connector API：允許構建並執行可重用的生產者或者消費者，將Kafka topics連線到已存在的應用程式或者資料系統。比如，連線到一個關係型資料庫，捕捉表（table）的所有變更內容。
在Kafka中，客戶端和伺服器之間的通訊是通過簡單，高效能，語言無關的TCP協議完成的。此協議已版本化並保持與舊版本的向後相容性。Kafka提供多種語言客戶端。
kafka API - producer
Properties props = new Properties(); props.put("batch.size",16384); //預設值為16384 props.put("linger.ms",16384); //預設值為0 props.put("acks", "all"); props.put("retries",1); //... Producer<String, String> producer = new KafkaProducer(props); ProducerRecord<String, String> record =new ProducerRecord<String, String>("my-topic", "key", "value"); producer.send(record); producer.close();
- Producer會為每個partition維護一個緩衝，用來記錄還沒有傳送的資料，每個緩衝區大小用 batch.size指定，預設值為16k.
- linger.ms為，buffer中的資料在達到batch.size前，需要等待的時間
- acks用來配置請求成功的標準
kafka API - consumer
Kafka Simple Consumer
Simple Cnsumer 位於kafka.javaapi.consumer包中，不提供負載均衡、容錯的特性每次獲取資料都要指定topic、partition、offset、fetchSize
High-level Consumer
該客戶端透明地處理kafka broker異常，透明地切換consumer的partition，通過和broker互動來實現consumer group級別的負載均衡。
如圖，這個 Kafka 叢集有兩臺 server 的，四個分割槽(p0-p3)和兩個消費者組。消費組A有兩個消費者，消費組B有四個消費者。通常情況下，每個 topic 都會有一些消費組，一個消費組對應一個"邏輯訂閱者"。一個消費組由許多消費者例項組成，便於擴充套件和容錯。這就是釋出和訂閱的概念，只不過訂閱者是一組消費者而不是單個的程式。在Kafka中實現消費的方式是將日誌中的分割槽劃分到每一個消費者例項上，以便在任何時間，每個例項都是分割槽唯一的消費者。維護消費組中的消費關係由Kafka協議動態處理。如果新的例項加入組，他們將從組中其他成員處接管一些 partition 分割槽;如果一個例項消失，擁有的分割槽將被分發到剩餘的例項。Kafka 只保證分割槽內的記錄是有序的，而不保證主題中不同分割槽的順序。每個partition 分割槽按照key值排序足以滿足大多數應用程式的需求。但如果你需要總記錄在所有記錄的上面，可使用僅有一個分割槽的主題來實現，這意味著每個消費者組只有一個消費者程式。
五、kafa整體架構
