（ 一 ）、Kafka 介紹
官方中文文檔： https://kafka.apachecn.org/intro.html
3.0 文檔: https://kafka.apache.org/documentation/
下載：https://kafka.apachecn.org/downloads.html
一、簡介
Kafka是最初由Linkedin公司開發，是一個分布式、支持分區的（partition）、多副本的（replica），基於zookeeper協調的分布式消息系統，它的最大的特性就是可以實時的處理大量數據以滿足各種需求場景：比如基於hadoop的批處理系統、低延遲的實時系統、storm/Spark流式處理引擎，web/nginx日志、訪問日志，消息服務等等，用scala語言編寫，Linkedin於2010年貢獻給了Apache基金會並成為頂級開源 項目。
二、Kafka的特性
- 高吞吐量、低延遲： kafka每秒可以處理幾十萬條消息，它的延遲最低只有幾毫秒，每個topic可以分多個partition, consumer group 對partition進行consume操作。Kafka 在數據寫入及數據同步采用了零拷貝（ zero-copy ）技術，采用sendFile()函數調用，sendFile ()函數是在兩個文件描述符之間直接傳遞數據，完全在內核中操作，從而避免了內核緩沖區與用戶緩沖區之間數據的拷貝，操作效率極高。Kafka 還支持數據壓縮及批量發送，同時Kafka 將每個主題划分為多個分區，這一系列的優化及實現方法使得Kafka 具有很高的吞吐量。經大多數公司對Kafka 應用的驗證， Kafka 支持每秒數百萬級別的消息
- 可擴展性： kafka集群支持熱擴展。Kafka 依賴ZooKeeper來對集群進行協調管理，這樣使得Kafka 更加容易進行水平擴展，生產者、消費者和代理都為分布式，可配置多個。同時在機器擴展時無需將整個集群停機，集群能夠自動感知，重新進行負責均衡及數據復制。
- 持久性、可靠性：消息被持久化到本地磁盤，並且支持數據備份防止數據丟失。因為是順序追加，所以Kafka 在設計上是采用時間復雜度O(1)的磁盤結構，它提供了常量時間的性能，即使是存儲海量的信息（ TB 級）也如此。，性能和數據的大小關系也不大，同時Kafka 將數據持久化到磁盤上，這樣只要磁盤空間足夠大數據就可以一直追加，而不會像一般的消息系統在消息被消費后就刪除掉， Kafka 提供了相關配置讓用戶自己決定消息要保存多久，這樣為消費者提供了更靈活的處理方式，因此Kafka 能夠在沒有性能損失的情況下提供一般消息系統不具備的特性。
- 容錯性： 允許集群中節點失敗（若副本數量為n,則允許n-1個節點失敗）。
- 高並發：支持數千個客戶端同時讀寫。
- 安全機制:
- 通過SSL 和SASL(Kerberos), SASL/PLA時驗證機制支持生產者、消費者與代理連接時的身份認證。
- 支持代理與Zoo Keeper 連接身份驗證。
- 通信時數據加密。
- 客戶端讀、寫權限認證。
- Kafka 支持與外部其他認證授權服務的集成。
三、Kafka的使用場景：
- 消息系統：Kafka作為一款優秀的消息系統，具有高吞吐量、內置的分區、備份冗余分布式等特點，為大規模消息處理提供了一種很好的解決方案。
- 應用監控： 利用Kafka采集應用程序和服務器健康相關的指標，如CPU占用率、IO、內存、連接數、TPS、QPS等，然后將指標信息進行處理從而構建一個具有監控儀表盤、曲線圖等可視化監控系統。例如，很多公司采用Kafka 與ELK (Elastic Search、Logstash和Kibana整合構建應用服務監控系統。
- 網站用戶行為追蹤： 為了更好地了解用戶行為、操作習慣，改善用戶體驗，進而對產品升級改進，將用戶操作軌跡、內容等信息發送到Kafka 集群上，通過Hadoop 、Spark 或Strom等進行數據分析處理，生成相應的統計報告，為推薦系統推薦對象建模提供數據源，進而為每個用戶進行個性化推薦。
- 流處理： 需要將己收集的流數據提供給其他流式計算框架進行處理，用Kafka 收集流數據是一個不錯的選擇，而且當前版本的Kafka 提供了Kafka Streams 支持對流數據的處理。
- 持久性日志： Kafka 可以為外部系統提供一種持久性日志的分布式系統。日志可以在多個節點間進行備份， Kafka 為故障節點數據恢復提供了一種重新同步的機制。同時， Kafka很方便與HDFS 和Flume 進行整合，這樣就方便將Kafka 采集的數據持久化到其他外部系統。
四、Kafka基本概念
l、主題
Kafka 將一組消息抽象歸納為一個主題（Topic），也就是說，一個主題就是對消息的一個分類。生產者將消息發送到特定主題，消費者訂閱主題或主題的某些分區進行消費。
2、消息
消息是Kafka 通信的基本單位，由一個固定長度的消息頭和一個可變長度的消息體構成。在老版本中，每一條消息稱為Message ：在由Java 重新實現的客戶端中，每一條消息稱為Record 。
3、分區和副本
Kafka將一組消息歸納為一個主題，而每個主題又被分成一個或多個分區（Partition）。每個分區由一系列有序、不可變的消息組成，是一個有序隊列。每個分區在物理上對應為一個文件夾，分區的命名規則為主題名稱后接“一”連接符，之后再接分區編號，分區編號從0開始，編號最大值為分區的總數減l 。每個分區又有一至多個副本（Replica），分區的副本分布在集群的不同代理上，以提高可用性。從存儲角度上分析，分區的每個副本在邏輯上抽象為一個日志（Log）對象，即分區的副本與日志對象是一一對應的。每個主題對應的分區數可以在Kafka啟動時所加載的配置文件中配置，也可以在創建主題時指定。當然，客戶端還可以在主題創建后修改主題的分區數。分區使得Kafka在井發處理上變得更加容易，理論上來說，分區數越多吞吐量越高，但這要根據集群實際環境及業務場景而定。同時，分區也是Kafka 保證消息被順序消費以及對消息進行負載均衡的基礎。Kafka 只能保證一個分區之內消息的有序性，並不能保證跨分區消息的有序性。每條消息被追加到相應的分區中，是順序寫磁盤，因此效率非常高，這是Kafka 高吞吐率的一個重要保證。同時與傳統消息系統不同的是， Kafka 並不會立即刪除已被消費的消息，由於磁盤的限制消息也不會一直被存儲（事實上這也是沒有必要的），因此Kafka提供兩種刪除老數據的策略，一是基於消息己存儲的時間長度，二是基於分區的大小。這兩種策略都能通過配置文件進行配置。
我們說 kafka 是一個分布式消息系統，所謂的分布式，實際上我們已經大致了解。消息保存在 Topic 中，而為了能夠實現大數據的存儲，一個 topic 划分為多個分區，每個分區對應一個文件，可以分別存儲到不同的機器上，以實現分布式的集群存儲。另外，每個 partition 可以有一定的副本，備份到多台機器上，以提高可用性。
總結起來就是：
- 一個 topic 對應的多個 partition 分散存儲到集群中的多個 broker 上，存儲方式是一個 partition 對應一個文件，每個 broker 負責存儲在自己機器上的 partition 中的消息讀寫。
- 從整體考慮，有多少個 partition 就意味着會有多少個leader，kafka 會將 leader 分散到不同的 broker 上，確保整體的負載均衡。
4、Leader 副本和 Follower 副本
由於Kafka 副本的存在，就需要保證一個分區的多個副本之間數據的一致性，Kafka會選擇該分區的一個副本作為Leader副本，而該分區其他副本即為Follower 副本，只有Leader 副本才負責處理客戶端讀／寫請求， Follower 副本從Leader 副本同步數據。如果沒有Leader 副本，那就需要所有的副本都同時負責讀／寫請求處理，同時還得保證這些副本之間數據的一致性，假設有n個副本則需要有n×n條通路來同步數據，這樣數據的一致性和有序性就很難保證。引入Leader 副本后客戶端只需與Leader 副本進行交互，這樣數據一致性及順序性就有了保證。Follower 副本從Leader 副本同步消息，對於n個副本只需n-1條通路即可，這樣就使得系統更加簡單而高效。副本Follower與Leader的角色並不是固定不變的，如果Leader 失效，通過相應的選舉算法將從其他Follower 副本中選出新的Leader 副本。
5. 偏移量
任何發布到分區的消息會被直接追加到日志文件（分區目錄下以＂.log”為文件名后綴的數據文件〉的尾部，而每條消息在日志文件中的位置都會對應一個按序遞增的偏移量。偏移量是一個分區下嚴格有序的邏輯值，它並不表示消息在磁盤上的物理位置。由於Kafka幾乎不允許對消息進行隨機讀寫，因此Kafka 並沒有提供額外索引機制到存儲偏移量，也就是說並不會給偏移量再提供索引。消費者可以通過控制消息偏移量來對消息進行消費，如消費者可以指定消費的起始偏移量。為了保證消息被順序消費，消費者己消費的消息對應的偏移量也需要保存。需要說明的是，消費者對消息偏移量的操作並不會影響消息本身的偏移量。舊版消費者將消費偏移量保存到ZooKeeper 當中，而新版消費者是將消費偏移量保存到Kafka 內部一個主題當中。當然，消費者也可以自己在外部系統保存消費偏移量，而無需保存到Kafka 中。
6、 代理
Kafka 集群就是由一個或多個Kafka 實例構成，我們將每一個Kafka 實例稱為代理（ Broker ），通常也稱代理為Kafka 服務器( KafkaServer ） 。每一個代理都有唯一的標識id，這個id是一個非負整數。在一個Kafka集群中，每增加一個代理就需要為這個代理配置一個與該集群中其他代理不同的id, id值可以選擇任意非負整數即可，只要保證它在整個Kafka 集群中唯一，這個id 就是代理的名字，也就是在啟動代理時配置的broker.id 對應的值。
7、生產者
生產者（ Producer ）負責將消息發送給代理，也就是向Kafka 代理發送消息的客戶端。
8、消費者和消費組
消費者（ Comsumer ）以拉取（ pull ）方式拉取數據，它是消費的客戶端。在Kafka中每一個消費者都屬於一個特定消費組（ConsumerGroup ），我們可以為每個消費者指定一個消費組，以groupld 代表消費組名稱，通過group.id 配置設置。如果不指定消費組，則該消費者屬於默
認消費組test-consumer-group 。同時，每個消費者也有一個全局唯一的id ， 通過配置項client.id指定，如果客戶端沒有指定消費者的id, Kafka會自動為該消費者生成一個全局唯一的id，格式為${groupld}-${hostName}-${timestamp}-${UUID前8位字符｝。同一個主題的一條消息只能被同一個消費組下某一個消費者消費，但不同消費組的消費者可同時消費該消息。消費組是Kafka用來實現對一個主題消息進行廣播和單播的手段，實現消息廣播只需指定各消費者均屬於不同的消費組，消息單播則只需讓各消費者屬於同一個消費組。
9、 ISR
Kafka 在ZooKeeper 中動態維護了一個ISR (In-sync Replica ），即保存同步的副本列表，該列表中保存的是與Leader副本保持消息同步的所有副本對應的代理節點id。如果一個Follower副本岩機，則該Follower副本節點將從ISR 列表中移除。
10、 ZooKeeper
這里我們並不打算介紹ZooKeeper 的相關知識，只是簡要介紹ZooKeeper 在Kafka 中的作用。Kafka 利用ZooKeeper 保存相應元數據信息， Kafka 元數據信息包括如代理節點信息、Kafka集群信息、舊版消費者信息及其消費偏移量信息、主題信息、分區狀態信息、分區副本分配方案信息、動態配置信息等。Kafka 在啟動或運行過程當中會在ZooKeeper上創建相應節點來保存元數據信息，Kafka通過監昕機制在這些節點注冊相應監聽器來監昕節點元數據的變化，從而由ZooKeeper負責管理維護Kafka集群，同時通過ZooKeeper我們能夠很方便地對Kafka集群進行水平擴展及數據遷移。
通過以上Kafka 基本概念的介紹，我們可以對Kafka 基本結構圖進行完善，如圖1-2 所示：
（1）數據生產過程（Produce）
對於生產者要寫入的一條記錄，可以指定四個參數：分別是 topic、partition、key 和 value，其中 topic 和 value（要寫入的數據）是必須要指定的，而 key 和 partition 是可選的。
對於一條記錄，先對其進行序列化，然后按照 Topic 和 Partition，放進對應的發送隊列中。如果 Partition 沒填，那么情況會是這樣的：1、Key 有填。按照 Key 進行哈希，相同 Key 去一個 Partition。 2、Key 沒填。Round-Robin 來選 Partition。
producer 將會和Topic下所有 partition leader 保持 socket 連接，消息由 producer 直接通過 socket 發送到 broker。其中 partition leader 的位置( host : port )注冊在 zookeeper 中，producer 作為 zookeeper client，已經注冊了 watch 用來監聽 partition leader 的變更事件，因此，可以准確的知道誰是當前的 leader。
producer 端采用異步發送：將多條消息暫且在客戶端 buffer 起來，並將他們批量的發送到 broker，小數據 IO 太多，會拖慢整體的網絡延遲，批量延遲發送事實上提升了網絡效率。
（2）數據消費過程（Consume）
對於消費者，不是以單獨的形式存在的，每一個消費者屬於一個 consumer group，一個 group 包含多個 consumer。特別需要注意的是：訂閱 Topic 是以一個消費組來訂閱的，發送到 Topic 的消息，只會被訂閱此 Topic 的每個 group 中的一個 consumer 消費。
如果所有的 Consumer 都具有相同的 group，那么就像是一個點對點的消息系統；如果每個 consumer 都具有不同的 group，那么消息會廣播給所有的消費者。
具體說來，這實際上是根據 partition 來分的，一個 Partition，只能被消費組里的一個消費者消費，但是可以同時被多個消費組消費，消費組里的每個消費者是關聯到一個 partition 的，因此有這樣的說法：對於一個 topic,同一個 group 中不能有多於 partitions 個數的 consumer 同時消費,否則將意味着某些 consumer 將無法得到消息。
同一個消費組的兩個消費者不會同時消費一個 partition。
消息傳送機制
Kafka 支持 3 種消息投遞語義,在業務中，常常都是使用 At least once 的模型。
- At most once：最多一次，消息可能會丟失，但不會重復。
- At least once：最少一次，消息不會丟失，可能會重復。
- Exactly once：只且一次，消息不丟失不重復，只且消費一次