一、Kafka簡介
二、kafka基本概念
三、kafka結構設計
四、kafka場景與應用
五、簡單使用案例
六、代碼案例
七、kafka高級特性
一、Kafka簡介
Kafka流處理平臺由LinkedIn開發，2011年被apache收納。
Kafka的三個關鍵特性：
- 發佈和訂閱記錄流，類似於消息隊列或企業消息傳遞系統。
- 以容錯的持久方式存儲記錄流。
- 當記錄流產生時，就可以進行處理
Kafka通常被用在兩大類應用：
- 構建實時流數據管道，在系統和應用程序之間可靠地獲取數據
- 構建實時流應用程序以轉換或響應數據流
Kafka特點
1.分佈式：
- 多分區(partitions)
- 多副本(replications)[提供容錯]
- 多訂閱者[Topic可以有一個或多個訂閱者，訂閱者數量不大於Partions數量]
- 基於Zookeeper調度[存儲Broker、Topic、Partions信息等等]
2.高性能：
- 高吞吐量[每秒幾十萬的吞吐量]，低延遲，高併發，事件複雜度爲o(1)
3.持久性和擴展性：
- 數據可持久化、容錯性、支持在線水平擴展、消息自動平衡
二、kafka基本概念
| 名稱 | 解釋 |
|---|---|
| Producer | 消息和數據的生產者，向Kafka的一個topic發佈消息的進程/代碼/服務 |
| Cumsumer | 消息和數據的消費者，訂閱數據(Topic)並且處理其發佈的消息的進程/代碼/服務。 |
| Consumer Group | 邏輯概念，對於同一個topic，會廣播給不同的group，一個group中，只有一個consumer可以消費該topic。 |
| Broker | 物理概念，Kafka集羣中的每個Kafka節點 |
| Topic | 邏輯概念，Kafka消息的類別，對數據進行區分、隔離 |
| Partition | 物理概念，Kafka下數據存儲的基本單元。一個Topic數據，會被分散存儲到多個Partition，每一個Partition時有序的，kafka會將一個Partition放在一個Broker裏面。 |
| Replication | 同一個Partition可能會有多個Replica，多個Replica之間數據是一樣的。 |
| Replication Leader | 一個Partition的多個Replica上，需要一個Leader負責該Partition上與Produce和Consumer交互。 |
| RepicaManager | 負責管理當前broker所有分區和副本的信息，處理KafkaController發起的一些請求，副本狀態的切換、添加/讀取消息、選舉Leader等。 |
名詞概念延伸
Partition
1.每一個Topic被切分爲多個Partitions
2.消費者數目少於或等於Partition的數目(否作多個消費者消費同一個Partition)
3.Broker Group中每一個Broker保存Topic的一個或多個Partitions，同一個Partitions不會被多個Broker同時保存，當Partitions很大時，會切分給各個broker存儲。
Consumer Group中僅有一個Consumer讀取Topic的一個或多個Partitions並且是唯一的Consumer
Replication
1.當集羣中有Broker掛掉的情況，系統可以主動地使用Replicas提供服務。
2.系統默認設置每一個Topic的replication係數爲1(沒有副本)，可以在創建Topic時單獨設置
Replication特點
1.基本單位時Topic的Partition;
2.所有的讀和寫都從Leader進，Followers只是做爲備份
3.Follwers必須能夠及時負責Leader的數據
三、基本結構
kafka消息隊列運作圖
從上圖看出，Kafka強依賴於zookeeper，那麼其作用是：
1.Broker信息都存儲在Zookeeper上
2.Topic信息和Partitions分佈信息都存儲在Zookeeper
Kafka消息結構
| 字段 | 解釋 |
|---|---|
| offset | 記錄當前這個消息它所處於的偏移量 |
| Length | 當前消息長度 |
| CRC32 | 校驗信息完整性，避免信息不完整導致數據生產或消費失敗 |
| Magic | 快速判定該消息是否是kafka消息，否則遺棄 |
| attributes | 存儲當前消息的屬性 |
| Timestamp | 時間戳 |
| Key Length | key的長度 |
| Key | key的值，無長度限制 |
| Value Length | value長度 |
| Value | value的值，無長度限制 |
四、Kafka的應用場景及應用
- 消息隊列： 優勢在於高吞吐、分區、副本等容錯性，大規模消息處理系統；穩定，同時它的消息可被重複消費，內置數據持久化具有更低延遲。媲美ActiveMQ、
- 行爲跟蹤：屬於發佈訂閱的擴展應用，當我們需要跟蹤用戶瀏覽行爲時，可以將所有的瀏覽記錄以發佈訂閱的方式將數據實時記錄到topic裏，那這些被訂閱者獲取後做進一步處理。
- 元數據監控：通常用於操作記錄監控模塊，記錄操作信息，可理解爲運維性質的監控。
- 日誌收集：可讓數據進行流動起來，比起傳統以文件爲中心處理系統例如ELK。
- 流處理：保存收集上游的流數據對接到下游的計算/存儲。
- 事件源：將狀態轉移按事件排列的序列，可以回溯事件狀態變更。
- 持久性日誌(commit log)系統之外持久性記錄，故障恢復的以一種機制。
五、Kafka簡單案例(命令行)
解壓與安裝【本章略過該方式】
Zookeeper下載：http://zookeeper.apache.org/releases.html#download
Kafka下載：http://kafka.apache.org/downloads
安裝見此篇： https://www.cnblogs.com/wonglu/p/8687488.html
Docker啓動【本章使用該方式】
[root@zan71 ~]# docker run -d --name zookeeper -p 2181:2181 -t wurstmeister/zookeeper
[root@zan71 ~]# docker run --name kafka01 -p 9092:9092 -e KAFKA_BROKER_ID=0 -e KAFKA_ZOOKEEPER_CONNECT=192.168.91.66:2181 -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://192.168.91.66:9092 -e KAFKA_LISTENERS=PLAINTEXT://0.0.0.0:9092 -d wurstmeister/kafka
簡單生產者
1.進入kafka容器
[root@zan71 ~]# docker exec -it kafka01 /bin/bash
2.創建主題，副本爲1(無副本)，分區爲3
bash-4.4# /opt/kafka/bin/kafka-topics.sh --create --zookeeper 192.168.245.128:2181 --replication-factor 1 --partitions 3 --topic test-topic
3.列出當前的主題
bash-4.4# /opt/kafka/bin/kafka-topics.sh --list --zookeeper 192.168.245.128:2181
4.啓動生產者交互終端：
bash-4.4# /opt/kafka/bin/kafka-console-producer.sh --broker-list 192.168.245.128:9092 --topic test-topic
簡單消費者
5.1：啓動從頭消費終端(之前消費過的再次消費)[添加參數–from-beginning]
bash-4.4# /opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test-topic --from-beginning
5.2: 啓動消費未被消費的終端(只會消費剩下沒被消費過的消息)
bash-4.4# /opt/kafka/bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test-topic
5.3 測試，往生產者交互終端輸入數據，查看消費終端屏幕打印
六、Kafka代碼案例
Django+Celery+Kafka+Prometheus打造高性能日誌處理平臺【敬請等待】
七、Kafka高級特性
7.1 消息事務
爲什麼要支持事務？
- 滿足 "讀取-處理-寫入” 模式，即數據一致性，類似SQL的comit，比如說你往ATM打錢，直到將金額寫入數據庫中，纔算成功。否則中間只要有錯誤，將給你退錢；避免出現你存了錢但是沒有寫進數據庫。
- 流處理需求的不斷增強
- 不準確的數據處理的容忍度在不斷降低。提供數據的準確性
數據傳輸的事務定義：
- 最多一次：消息不會被重複發送，最多被傳輸一次，但也有可能一次不傳輸。
- 最少一次：消息不會被漏發送，最少被傳輸一次，但也有可能被重複傳輸
- 精確的一次(Exactly once)：不會漏傳輸也不會重複傳輸，每個消息都被傳輸一次而且僅僅被傳輸一次，這是大家所期望的
事務保證：
內部重試問題： Procdure冪處理。
多分區原子寫入：要麼被寫入，要被被丟棄。
避免殭屍實例：
- 每個事務Producer分配一個transactional.id，在進程重寫啓動時能夠識別相同的Producer實例
- Kafka增加了一個與transactional.id相關的epoch，存儲每個transactional.id內部元數據。
- 一旦epoch被觸發，任何具有相同的transactional.id和更舊的epoch的Producer被視爲殭屍，Kafka會拒絕來自這些Procedure的後續事務性寫入
kafka如何實現多分區原子的操作？
原子是讀取處理寫入的過程，假如topic1的偏移量X處讀取消息A，然後它對消息進行處理之後，將這個消息命名爲B，並寫入到topic2這一整個過程。整個操作是原子的。
如何認爲讀取寫入是原子的？成功消費並且發佈，或者不發佈，那前提是成功消費。
如何判斷一個消息是成功消費？當讀取A時，偏移量會被標記爲已消費。
何時判斷已消費？Kafka會將偏移量寫入offsets topic內部的kafka topic來記錄offsets commit。所以當偏移量被提交offsets topic時才認定是成功消費
7.2零拷貝
網絡傳輸持久性日誌塊：例如日常的生產和消費的消息就是日誌塊，傳輸這個的時候本身很消耗性能，kafka是如何提供性能？-零拷貝技術。使用Java Nio channel.transforTo()方法即可實現零拷貝數據傳輸過程，底層是Linux sendfile系統調用。
零拷貝是怎樣提供數據傳輸性能？
文件傳輸到網絡的公共數據路徑： 把磁盤上的一個日誌塊發送到網絡上，要經歷：
1.操作系統將數據從磁盤讀入到內核空間的頁緩存(頁緩存基於磁盤上第一層緩存，只有讀取到該層緩存上，系統才能快速地拷貝到其他地方)
2.應用程序將數據從內核空間讀入到用戶空間緩存中(對於Linux來說，內核空間是應用程序無法直接操作的，應用程序能操作的是當前用戶空間，因此應用程序需要將數據從內核空間讀入到用戶空間緩存中)
3.應用程序將數據寫回到內核空間的socket緩存中(因爲要發到網絡上，所以要發到socket緩存中)
4.操作系統將數據從socket緩衝區複製到網卡緩衝區，以便將數據經網絡發出。
總結：磁盤->網絡需要經4次拷貝
零拷貝過程
1.操作系統將數據從磁盤讀入到內核空間的頁緩存(該過程是省不掉的，無論如何都需將數據讀取到頁緩存中)
2.將數據的位置和長度的信息的描述符增加到內核空間(socker緩衝區)
3.操作系統通過描述符將數據從內核拷貝到網卡緩衝區，以便數據經網絡發出
總共2次拷貝，零拷貝的意思是內核空間和用戶空間的交互拷貝次數爲0，所以稱之爲零拷貝。
文件傳輸到網絡的公共數據路徑演變
