什麼是Kafka？有什麼優勢

Kafka

Kafka是一個分佈式消息隊列，具備高性能、持久化、多副本備份、橫向擴展能力.(pub-sub模型)

維基百科

Kafka 是由Apache軟件基金會開發的一個開源流處理平臺，由Scala和JAVA編寫.該項目的目標是爲處理實時數據提供一個統1、高吞吐、低延遲的平臺。其持久化層本質是一個"按照分佈式事務日誌架構的大規模發佈/訂閱消息隊列".Kafka能夠經過Kafka Connect鏈接到外部系統(用於數據輸入/輸出),並提供了Kafka Streams ———— 一個Java流式處理庫.

基於kafka-zookeeper 的分佈式消息隊列系統整體架構以下：

Kafka 架構說明

一個典型的Kafka集羣包含若干Producer，若干Broker，若干Consumer，以及一個Zookeeper集羣。Kafka經過Zookeeper管理集羣配置，選舉Leader，以及在Consumer Group發送變化時進行Rebalance(負載均衡)。Producer 使用push(推)模式將消息發佈到Broker；Consumer 使用pull(拉)模式從Broker訂閱並消費消息。

Kafka 四大核心

• 生產者API：容許應用程序發佈記錄流至一個或多個kafka的主題(Topics)
  
• 消費者API：容許應用程序訂閱一個或多個主題，並處理這些主題接收到的記錄流
  
• Streams API: 容許應用程序充當流處理器(stream processor)，從一個或多個主題獲取輸入流，並生產一個輸出流至一個或多個的主題，可以有效地變換輸入流爲輸出流
  
• Connector API: 容許構建和運行可重用的生產者或消費者，可以把kafka主題鏈接到現有的應用程序或數據系統

Kafka 基礎概念

• 不管是kafka集羣，仍是consumer都依賴於zookeeper集羣保存一些meta信息，來保證系統可用性
• Producer 採用推(push)模式將消息發佈到broker，每條消息都被追加(append)到分區(partition)中，屬於順序寫磁盤(順序寫磁盤效率比隨機寫內存要高，保障kafka吞吐率)
• Producer
• • 發送消息者稱爲 Producer

• 生產者組件圖

• 建立Kafka生產者
• • 要往Kafka寫入信息，首先要建立一個生產者對象，並設置一些屬性。Kafka生產者有3個必選屬性
• bootstrap.servers
• • 該屬性指定broker的地址清單，地址的格式爲host:port。清單裏不須要包含全部的broker地址，生產者會從給定的broker裏查找到其餘的broker的信息。(建議提供兩個broker信息，一旦其中一個宕機，生產者仍然可以鏈接到集羣上)
• key.serializer
• • broker 但願接受到的消息的鍵和值都是字節數組.生產者接口容許使用參數化類型，所以能夠把java對象做爲鍵和值發送給broker。
• value.serializer
• • value.serializer 指定的類會將值序列化。若是鍵和值都是字符串，可使用key.serializer同樣的序列化器。若是鍵是整數類型而值是字符串，那麼須要使用不一樣的序列化器.

生產者的配置

參數	描述
acks	acks 參數指定了必需要有多少個分區副本收到消息，生產者纔會認爲消費寫入是成功的。acks = 0 生產者在成功寫入消息以前不會等待任何來自服務器的響應。(缺點：沒法確認消費是否成功；優勢：高吞吐量)；acks = 1 只要集羣的首領節點收到消息，生產者就會收到一個來自服務器的成功響應。若是消費沒法到達首領節點(好比首領節點奔潰，新的首領尚未被選舉處理)，生產者會收到一個錯誤響應，爲了不數據丟失，生產者會重發消息。不過，若是一個沒有收到消息的節點成爲新首領，消息仍是會丟失。acks = all 只有當全部參與複製的節點所有收到消息時，生產者纔會收到一個來自服務器的成功響應。
buffer.memory	該參數用來設置生產者緩衝區的大小，生產者用它緩衝要發送到服務器的消息。0.9.0.0 版本被替換成了 max.block.ms,表示在拋出異常以前能夠阻塞一段時間
compression.type	默認狀況下爲none，消費發送時不會被壓縮。該參數能夠設置爲snappy、gzip或lz4，它指定了消息被髮送給broker以前使用哪種壓縮算法進行壓縮。1. snappy 壓縮算法有Google發明，它佔用較少的CPU，卻能提供較好的性能和至關可觀的壓縮比(比較關注性能和網路帶寬) 2. gzip 壓縮算法通常會佔用較多的CPU，但會提供更高的壓縮比(網絡帶寬有限次採用)
retries	生產者從服務器收到的錯誤有多是臨時性的錯誤(好比分區找不到首領)。在這中狀況下，retries參數是值決定了生產者能夠重發消息的次數，若是達到這個次數，生產者會放棄重試並返回錯誤。默認狀況下，生產者會在每次重試之間等待100ms，能夠經過retry.backoff.ms參數來改變這個時間間隔.
batch.size	當有多個消息須要被髮送到同一個分區時，生產者會把它們放在同一個批次裏。該採納數指定了一個批次可使用的內存大小，按照字節數計算(而不是消息個數)。1. 批次設置很大 不會形成延遲，只會佔用更多的內存 2. 批次設置很小 由於生產者須要更頻繁地發送消息，會增長一些額外的開銷
linger.ms	該參數指定了生產者在發送批次以前等待更多消息加入批次的時間。
client.id	該參數能夠是任意的字符串，服務器會用它來識別消息的來源，還能夠用在日誌和配額指標裏
request.timeout.ms	指定了生產者在發送數據時等待服務器返回響應的時間
max.block.ms	該參數指定了在調用send()方法或使用partitionsFor()方法獲取元數據時生產者的阻塞時間。當生產者的發送緩衝區已滿，或者沒有可用的元數據時，這些方法就會阻塞。在阻塞時間達到max.block.ms時，生產者會拋出超時異常
max.request.size	該參數用於控制生產者發送的請求大小。它能夠指能發送的單個消息的最大值，能夠指單個請求裏全部消息總的大小。

• Consumer
• • 消息接收者稱爲Consumer
• • consumer 採用pull(拉)模式從broker中讀取數據
• • push(推) 模式很難適應消費速率不一樣的消費者，由於消息發送速率是由broker決定的。它的目標是儘量以最快速度傳遞消息，可是這樣很容易形成consumer來不及處理消息，典型的表現就是拒絕服務以及網絡擁塞。而pull模式則能夠根據consumer的消費能力以適當的速率消費消息
• • 對於Kafka而言,pull模式更合適，它可簡化broker的設計，consumer可自主控制消費消息的速率，同時consumer能夠本身控制消費方式——便可批量消費也可逐條消費， 同時還能選擇不一樣的提交方式從而實現不一樣的傳輸語義
• • pull 模式不足之處是，若是kafka沒有數據，消費者可能會陷入循環中，一直等待數據到達。爲了不這種狀況，咱們在拉請求中有參數，容許消費者請求在的等待數據到達的"長輪詢"中進行阻塞(而且可選地等待到給定的字節數，以確保打的傳輸大小)
• Consumer Group (CG)
• • 這是kafka用來實現一個topic消息的廣播(發給全部的consumer)和單播(發給任意一個consumer)的手段。一個topic能夠有多個CG。topic的消息會複製(概念上的複製)到全部的CG，但每一個partition只會把消息發給該CG中的一個consumer。若是須要實現廣播，只要每一個consumer有一個獨立的CG就能夠了。要實現單播只要全部consumer在同一個CG。用CG還能夠將consumer進行自由的分組而不須要屢次發送消息到不一樣的topic
• • 每一個分區在同一時間只能由group中的一個消費者讀取，可是多個group能夠同時消費這個partition。
• • 消費者經過向被指派爲羣組協調器的broker發送心跳來維持它們和羣組的從屬關係以及它們對分區的全部權關係.
• Broker(代理)
• • 已發佈的消息保存在一組服務器中，稱之爲Kafka集羣。集羣中的每個服務器都是一個代理。
• 主題(Topic)
• • Kafka將消息以topic爲單位進行概括(一條消息必須屬於某一個主題)
• • 在Kafka集羣中，能夠有無數的主題
• • Kafka 的主題始終是支持多用戶訂閱的；也就是說，一個主題能夠有零個，一個或多個消費者訂閱寫入的

數據

• • 分區數(Partitions): 控制topic將分片成多少log。能夠顯示指定，若是不指定則會使用broker(server.properties)中的num.partitions配置的數量
• • replication-factor副本：控制消息保證在幾個broker(服務器)上，通常狀況下等於broker的個數。
• 分區(Partitions)
• • 消息發送時都被髮送到一個topic，其本質就是一個目錄，而topic是由一些Partition Logs(分區日誌)組成

• • 每一個Topic都有一個或者多個Partitions 構成
• • 每一個Partition都是有序且不可變的消息隊列
• • Topic的Partition數量能夠在建立時配置
• • Partition數量決定了每一個Consumer group中併發消費者的最大數量
• • 分區的緣由：
• • 1. 方便在集羣中擴展，每一個Partition能夠經過調整以適應它所在的機器，而一個topic又能夠有多個Partition組成，所以整個集羣就能夠適應任意大小的數據了；
• • 1. 能夠提升併發，由於能夠以Partition爲單位讀寫
• • 分區的原則：
• • 1. 指定了partition，則直接使用
• • 1. 未指定partition但指定key，經過對key的value進行hash出一個partition
• • 1. partition和key都未指定，使用輪詢選出一個partition
• 偏移量(offset)
• • 任何發佈到partition的消息都會被直接追加到log文件的尾部，每條消息在文件中的位置稱爲offset(偏移量),offset是一個long型數字，它惟一標記一條消息。消費者經過(offset、partition、topic)跟蹤記錄.

副本

• 副本因子操做的單位是以分區爲單位,每一個分區都有各自的主副本和從副本
• 主副本叫作leader，從副本叫作follower，處於同步狀態的副本叫作in-sync
• 致使副本同步失敗的緣由：
• • 網絡擁塞致使複製變慢
• • broker 發生奔潰致使複製滯後
• 持續的副本：持續請求獲得最新消息副本被稱爲同步的副本。在首領發生失效時，只有同步副本纔有可能被選爲新首領

複製

• Kafka的複製機制和分區的多副本架構是Kafka可靠性保證的核心。把消息寫入多個副本能夠是Kafka在發送奔潰時仍能保證消息的持久性。

replicas(ISR);

• • Follower 經過拉的方式從leader同步數據。消費者和生產者都是從leader讀寫數據，不與follower交互
• • 當有多個副本數時，kafka並非將多個副本同時對外提供讀取和寫入,做用是讓kafka讀取和寫入數據時的高可靠
• log 日誌
• • kafka-log 目錄下,會根據: 主題-分區 值建立目錄
• • 00000000000000000000.index -- 索引 稀疏索引
• • 00000000000000000000.log -- 數據
• • log 默認狀況下會根據1G的大小，建立一個新的segment file文件
• • 00000000000000001123.index -- 1123 offset的開始值
• • 00000000000000001123.log
• log 的優化
• • 能夠選擇刪除或者合併

集羣成員關係

• Kafka 使用Zookeeper來維護集羣成員的信息。每一個broker都有一個惟一標識符，這個標識符能夠在配置文件裏指定，也能夠自動生成。在broker啓動的時候，它經過建立臨時節點把本身的ID註冊到Zookeeper。Kafka組件訂閱Zookeeper的 /brokers/ids 路徑(broker在Zookeeper上的註冊路徑)，當有broker加入集羣或退出集羣時，這些組件就能夠得到通知。在broker停機、出現網絡分區或長時間垃圾回收停頓時，broker會從Zookeeper上斷開鏈接，此時broker在啓動時建立的臨時節點會自動從Zookeeper上移除。監聽broker列表的Kafka組件會被告知該broker已移除。在關閉broker時，它對應的節點也會消失，不過它的ID會繼續存在於其餘數據結構中

處理請求

• broker 的大部分工做是處理客戶端、分區副本和控制器發送給分區首領的請求。Kafka提供一個二進制協議(基於TCP),指定了請求信息的格式以及broker如何對請求作出響應——包括成功處理請求或在處理請求過程當中遇到錯誤。
• 客戶端發起鏈接併發送請求，broker處理請求並做出響應。broker按照請求到達的順序來處理它們——這種順序保證讓Kafka具備了消息隊列的特性，同時保證保存的消息也是有序的。
• 標誌消息頭

參數	描述
Request type	API key
Request version	broker能夠處理不一樣版本的客戶端請求，並根據客戶端版本作出不一樣的響應
Correlation ID	一個具備惟一性的數字，用於標識請求消息，同時也會出如今響應消息和錯誤日誌裏(用於診斷問題)
Client ID	用於標識發送請求的客戶端

• broker會在它所監聽的每個端口上運行一個Acceptor線程，這個線程會建立一個鏈接，並把它交給Processor線程去處理。Processor線程("網絡線程")的數量是能夠配置的 。網絡線程負責從客戶端獲取請求信息，把它們放進請求隊列，而後從響應隊列獲取響應信息，把它們發送給客戶端。
• 客戶端如何知道往哪裏發送請求
• • 客戶端使用了另外一種請求類型，也就是元數據請求。這種請求包含了客戶端感興趣的主題列表。服務器端的響應消息裏指明瞭這些主題所包含的分區、每一個分區都有哪些副本，以及哪一個副本是首領。元數據請求能夠發送給任意一個broker，由於全部broker都緩存了這些信息。

控制器

• 控制器其實就是一個broker。集羣裏第一個啓動的broker經過在Zookeeper裏建立一個臨時節點 /controller 讓本身成爲控制器。其餘broker在啓動時也會嘗試建立這個節點，不過它們會收到一個"節點已存在"的異常，而後"意識"到控制器節點已存在，也就是說集羣裏已經有一個控制器了。其餘broker在控制器節點上建立Zookeeper watch對象，這樣它們就能夠收到這個節點的變動通知。這種方式能夠確保集羣裏一次只有一個控制器存在。
• 若是控制器被關閉或者Zookeeper斷開鏈接，Zookeeper上的臨時節點就會消失。集羣裏的其餘broker經過watch對象獲得控制器節點消失的通知，它們會嘗試讓本身成爲新的控制器。第一個在Zookeeper裏成功成功建立控制器節點的broker就會成爲新的控制器，其餘節點會收到"節點已存在"的異常，而後在新的控制器節點上再次建立watch對象。每一個新選出的控制器經過Zookeeper的條件遞增操做得到一個全新的、數值更大的controller epoch。其餘broker在知道當前controller epoch後，若是收到有控制器發出的包含舊epoch的消息，就會忽略它們。
• 當控制器發現一個broker已經離開集羣(經過觀察相關的Zookeeper路徑)，它就知道，那些失去首領的分區須要一個新首領(這些分區的首領恰好在這個broker上)。控制器遍歷這些分區，並肯定誰應該成爲新首領(簡單來講就是分區副本列表裏的下一個副本)，而後向全部包含新首領或現有跟隨者的broker發送請求。該請求消息包含了誰是新首領已經誰是分區跟隨者的信息。隨後新首領開始處理來着生產者和消費者的請求，而跟隨者開始重新首領那裏複製消息。
• 當控制器發現一個broker加入集羣時，它會使用broker ID來檢查新加入的broker是否包含現有的分區副本。若是有，控制器就把變動通知發送給新加入的broker和其餘broker，新broker上的副本開始從首領那裏複製消息。

Kafka 消費過程分析

• • Kafka提供了兩套consumer API：高級Consumer API 和 低級 Consumer API
• • 高級API 優勢
• • 1. 高級API寫起來簡單
• • 1. 不須要自行去管理offset，系統經過zookeeper自行管理
• • 1. 不須要管理分區，副本等狀況，系統自動管理
• • 1. 消費者斷線會自動根據上一次記錄在zookeeper中的offset去接着獲取數據(默認設置1分鐘更新一下zookeeper中存的offset)
• • 1. 可使用group來區分對同一個topic的不一樣程序訪問分離開來(不一樣的group記錄不一樣的offset，這樣不一樣程序讀取同一個topic纔不會由於offset互相影響)
• • 高級API 缺點
• • 1. 不能自行控制offset(對於某些特殊需求)
• • 1. 不能細化控制，如分區、副本、zk等
• • 低級API
• • 低級API優勢
• • 1. 可以讓開發者本身控制offset，想從哪裏讀取就從哪裏讀取
• • 1. 自行控制鏈接分區，對分區自定義進行負載均衡
• • 1. 對zookeeper的依賴性下降(如：offset不必定非要靠zk存儲，自行存儲offset便可，好比存儲在文件或則內存中)
• • 低級API缺點
• • 太過複雜，須要自行控制offset，鏈接哪一個分區，找到分區leader等
• kafka複製原理
• • 消費的發送方式：主題value、主題keyvalue、主題分區keyvalue、主題分區時間戳

keyvalue

• • Kafka 中topic的每一個partition有一個預寫式的日誌文件，雖然partition能夠繼續細分爲若干個segment文件，可是對於上層應用來講能夠將partition當作最小的存儲單元，每一個partition都由一些列有序的、不可變的消息組成，這些消息被連續的追加到partition中。
• • LEO：LogEndOffset的縮寫，表示每一個partition的log最後一條Message的位置
• • HW： 是HighWatermark的縮寫，是指consumer可以看到的此partition的位置
• • 具體描述：Kafka每一個topic的partition有N個副本(replicas).
• • kafka 經過多副本機制實現故障自動轉移，當kafka集羣中一個broker失效狀況下仍然保證服務可用。kafka中發生複製時確保partition的日誌能有序地寫到其餘節點上，N個replicas中，其中一個replicas爲leader，其餘都爲follower，leader處理partition的全部讀寫請求，於此同時，follower會被動按期地去複製leader的數據。kafka提供了數據複製算法保證，若是leader發生故障或掛掉，一個新leader被選舉並接受客戶端的消息成功寫入。
• • leader負責維護和跟蹤ISR中全部follower滯後的狀態.
• • 當producer發送一條消息到broker後，leader寫入消息並複製到全部follower。消息提交以後才被成功複製到全部的同步副本。消息複製延遲受最慢的follower限制，重要的是快速檢測慢副本，若是follower"落後"太多或者失效，leader將會把它從ISR中刪除.
• leader 將某個follower提出ISR列表的狀況：
• • 1. 按數量——若是leader當前的offset已經到10，可是某個follower同步的數據仍是2，可是kafka對於數量的誤差設置爲6。若是當前誤差小於等於設置的誤差，那麼會將該follower提出ISR列表，進入到OSR列表[全部的副本數據 = ISR + OSR]
  1. 按時間——有新數據，多久沒有發送確認信息

• ISR(副本同步隊列)
• • ISR 是全部副本的一個子集，由leader維護ISR列表，follower從leader同步數據有一些延遲，包括延遲時間 replica.lag.time.max.ms和延遲條數replica.lag.max.messages兩個維度，當前最新的版本0.10.x中只支持replica.lag.time.max.ms這個維度）。任意一個超過閾值都會把follower剔除出ISR，存入OSR(Outof-Sync Replicas)列表，新加入的follower也會先存放在OSR中。
• • leader 新寫入的信息，consumer不能馬上消費，leader會等待該消息被全部ISR中的replicas同步後更新HW，此時消息才能被consumer消費。這樣就保證了若是leader所在的broker失效，該消息仍然能夠重新選舉的leader中獲取。對於來自內部的broker的讀取請求，沒有HW的限制。
• • 同步複製要求全部的能工做的follower都複製完，這條消息纔會被commit，這種複製方式是否極大的影響了吞吐率？
• • 異步複製方式
• • follower異步的從leader複製數據，數據只要被leader寫入log就被認爲已經commit，這種狀況下若是follower都尚未複製完，落後於leader時，忽然leader宕機，則會丟失數據。而kafka的這種使用ISR的方式則很好的均衡了確保數據不丟失已經吞吐率。
• • Kafka的管理最終都會反饋到Zookeeper節點上。
• • 具體位置：/brokers/topics/[topic]/partitions/[partition]/state.
• • 目前有兩個地方會對這個Zookeeper的節點進行維護：
• • 1. Controller維護：Controller 下的LeaderSelector會選舉新的leader，ISR和新的leader_epoch及controller_epoch寫入Zookeeper的相關節點中。同時發起LeaderAndIsrRequest通知全部的replicas。
  1. leader維護：leader有單獨的線程按期檢測ISR中follower是否脫離ISR，若是發現ISR變化，則會將新的ISR的信息返回到Zookeeper的相關節點中。
• • Kafka集羣中的其中一個Broker會被選舉爲Controller，主要負責Partition管理和副本狀態管理，也會執行相似於重分配partition之類的管理任務。
• kafka 數據可靠性
• • 數據丟失的可能:能夠採用callback的方式進行處理，判斷異常信息是否爲空，若是爲空表示正常發送了，不然就有異常，可進行特殊處理
• • 當producer向leader發送數據時，能夠經過acks參數來設置數據可靠性的級別：
• • 1. 1(默認)：這意味着producer在ISR中的leader已成功收到的數據並獲得確認後發送下一條message。若是leader宕機了，則會丟失數據。
• • 1. 0：這意味着producer無需等待來自broker的確認而繼續發送下一批消息。這種狀況下數據傳輸效率最高，可是數據可靠性是最低的
• • 1. all：leader須要等待全部備份都寫入日誌，這種策略會保證只要有一個備份存活就不會丟失數據，這是最強的保證。
• kafka 消息傳輸保障
• • Kafka確保消息在producer和consumer之間傳輸。有如下三種可能的傳輸保障
• • 1. At most once : 消息可能丟失，但毫不會重複傳輸
• • 1. At least once : 消息毫不會丟，但可能重複傳輸
• • 1. Exactly once: 每條消息確定會被傳輸一次且僅傳輸一次
• kafka leader 和 follower 如何通訊

疑問

• 一個broker服務下，是否能夠建立多個分區？
• • 能夠，broker數與分區數沒有關係
• 一個broker服務下，是否能夠建立多個副本因子?
• • 不能夠，會報錯;

  建立主題時，副本因子應該小於等於可用的broker數

  Error while executing topic command : replication factor: 3 larger than available brokers: 1
  [2019-07-23 17:34:45,963] ERROR org.apache.kafka.common.errors.InvalidReplicationFactorException: replication factor: 3 larger than available brokers: 1
  (kafka.admin.TopicCommand$)

• 在kafka中，每個分區會有一個編號，從0開始
• 當執行刪除命令以後，topic不是物理刪除，而是一個標記刪除的操做.
• 標記刪除以後的主題是否還能夠繼續生產數據？
• • 不會有影響
• 如何保證一個主題下的數據，必定是有序的(生產與消費的順序一致)
• • 讓主題下只有一個分區
• 某一個主題下的分區數，對於消費組來講，應該小於等於該主題下的分區數。
• 在使用kafka的過程當中，如何保證數據的不丟失，不重複的問題？
• 如何確保Producer不丟失數據?
• ACK (應答機制設置爲2)
• Kafka 的用途？使用場景？
• • 消息系統；實時監控或者離線處理；日誌收集
• • 異常處理、平常系統削峯、解耦、提速、廣播
• Kafka中的ISR、AR表明什麼？ISR的伸縮?
• • ISR: In-Sync Replicas 副本同步隊列
• • AR: Assigned Replicas 全部副本
• • ISR是由leader維護，follower從leader同步數據有一些延遲(包括延遲時間replica.lag.time.max.ms 和 延遲條數 replica.lag.max.message兩個維度，當前最新的版本0.10.x 中只支持replica.lag.time.max.ms這個維度),任意一個超過閾值都會把follower剔除出ISR,存入OSR(Outof-Sync Replicas)列表，新加入的follower也會存放在OSR中。AR=ISR+OSR
• Kafka中的HW、LEO、LSO、LW等分別表明什麼？
• • HW: High Watermark 高水位，取一個partition對應的ISR中最小的LEO做爲HW，consumer最多隻能消費到HW所在的位置上一條信息
• • LEO: LogEndOffset 固然日誌文件中下一條代寫信息的offset
• • HW/LEO 這兩個都是指最後一條的下一條的位置而不是最後一條的位置
• • LSO: Last Stable Offset 對未完成的事務而言，LSO的值等於事務中第一條消息的位置(firstUnstableOffset),對已完成的事務而言，它的值同HW相同
• • LW: Low Watermark 低水位，表明AR集合中最小的logStartOffset值
• Kafka 中是怎麼體現消息順序性的?
• • Kafka每一個partition中的消息在寫入是都是有序的，消費時，每一個partition只能被每個group中的消費者消費，保證了消費時也是有序的
• • 整個topic不保證有序。若是爲了保證topic整個有序，那麼將partition調整爲1
• Kafka中的分區器、序列化器、攔截器之間的處理順序是什麼?
• • 攔截器 -> 序列化器 -> 分區器
• Kafka 生產者客戶端中使用了幾個線程來處理？
• • 2個，主線程和Sender線程。主線程負責建立消息，而後經過分區器、序列化器、攔截器做用以後緩存到累加器RecordAccumulator中。Sender線程負責將RecordAccumulator中消息發送到Kafka中
• 消費者提交消費位移時提交的是當前消費到的最新消息的offset仍是offset+1？
• • offset + 1
• 形成重複消費的緣由：
• • 消費者消費後沒有commit offset(程序奔潰/強行kill/消費耗時/自動提交偏移狀況下unscrible)
• 形成消息漏消費的緣由:
• • 消費者沒有處理完消息，提交offset(自動提交偏移，未處理狀況下程序異常結束)
• KafkaConsumer 是非線程安全的，如何實現多線程消費
• • 1. 在每一個線程中建立一個KafkaConsumer
• • 1. 單線程建立KafkaConsumer，多個處理線程處理消息
• 消費者與消費組之間的關係
• • 消費者從屬於消費組，消費偏移以消費組爲單位。每一個消費組能夠獨立消費主題的全部數據，同一消費組內消費者共同消費主題數據，每一個分區只能被同一消費組內一個消費者消費
• 使用kafka-topics.sh 建立(刪除)了一個topic以後，kafka背後執行了什麼邏輯
• • 建立：在zk上 /brokers/topics/下節點 Kafka broker 會監聽節點變化建立主題
• • 刪除: 調用腳本刪除topic會在zk上將topic設置待刪除標誌，kafka後臺有定時線程會掃描全部須要刪除的topic進行刪除
• 建立topic時如何選擇合適的分區數
• • 根據集羣的機器數量和須要的吞吐量來決定適合的分區數
• Kafka 目前有哪些內部topic，特徵，做用
• • __consumer_offsets 保證消費組的偏移
• 優先副本是什麼？有什麼特殊做用
• • 默認的leader副本
• • 發送leader變化時重選舉會優先選擇優先副本做爲leader
• Kafka的Log Retention的理解
• • kafka 留存策略包括刪除和壓縮兩種
• • 刪除：根據時間和大小兩種方式進行刪除，大小是整個partition日誌文件的大小，超過的會從老到新依次刪除；時間指定日誌文件中最大時間戳而非文件的最後修改時間
• • 壓縮：相同key的value只保存一個 壓縮過的是clean 未壓縮的dirty 壓縮以後的偏移量不連續 未壓縮時連續

持續更新...