上一階段給大家講的是Redis，接下來這一階段，我給你大家更新Kafka的知識分享哦!!!
企業中離線業務場景實時業務場景都需要使用到kafka
Kafka具備數據的計算能力和存儲能力，但是兩個能力相對（MR/SPARK，HDFS）較弱.
Kafka角色的角色與hbase比較像，層級關係比較多。
1、消息隊列的介紹
消息：是指在應用之間傳送的數據，消息可以非常簡單，比如只包含文本字符串，也可以更復雜，可能包含嵌入對象。
消息隊列（Message Queue）：是一種應用間的通信方式，消息發送後可以立即返回，由消息系統來確保信息的可靠專遞，消息發佈者只管把消息發佈到MQ中而不管誰來取，消息使用者只管從MQ中取消息而不管誰發佈的，這樣發佈者和使用者都不用知道對方的存在
2、消息隊列的應用場景
消息隊列在實際應用中包括如下四個場景：
應用耦合：多應用間通過消息隊列對同一消息進行處理，避免調用接口失敗導致整個過程失敗；
異步處理：多應用對消息隊列中同一消息進行處理，應用間併發處理消息，相比串行處理，減少處理時間；
限流削峯：廣泛應用於秒殺或搶購活動中，避免流量過大導致應用系統掛掉的情況；
消息驅動的系統：系統分爲消息隊列、消息生產者、消息消費者，生產者負責產生消息，消費者(可能有多個)負責對消息進行處理；
3、消息隊列的兩種模式
消息隊列包括兩種模式，點對點模式（point to point， queue）和發佈/訂閱模式（publish/subscribe，topic）
3.1 點對點模式
點對點模式下包括三個角色：
消息隊列
發送者 (生產者)：生產數據的程序/人/對象
接收者（消費者）：處理隊列內的數據的程序/人/對象
消息發送者生產消息發送到queue中，然後消息接收者從queue中取出並且消費消息。消息被消費以後，queue中不再有存儲，所以消息接收者不可能消費到已經被消費的消息。
點對點模式特點：
• 每個消息只有一個接收者（Consumer）(即一旦被消費，消息就不再在消息隊列中)；
• 發送者和接收者間沒有依賴性，發送者發送消息之後，不管有沒有接收者在運行，都不會影響到發送者下次發送消息；
• 接收者在成功接收消息之後需向隊列應答成功，以便消息隊列刪除當前接收的消息；
3.2 發佈/訂閱模式
發佈/訂閱模式下包括三個角色：
角色主題（Topic）：消息得分類，分組（王者榮耀，QQ飛車）
發佈者(Publisher)：生產者
訂閱者(Subscriber)：消費者
發佈者將消息發送到Topic,系統將這些消息傳遞給多個訂閱者。
發佈/訂閱模式特點：
• 每個消息可以有多個訂閱者；
• 發佈者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須創建一個訂閱者之後，才能消費發佈者的消息。
• 爲了消費消息，訂閱者需要提前訂閱該角色主題，並保持在線運行；
4、kafka的基本介紹
4.1 kafka的基本介紹
官網：http://kafka.apache.org/
kafka是一個分佈式，分區的，多副本的，多訂閱者的消息發佈訂閱系統（分佈式MQ系統），可以用於搜索日誌，監控日誌，訪問日誌等。
最初由linkedin公司開發，使用scala語言編寫，
Kafka is a distributed,partitioned,replicated commit logservice。
kafka對消息保存時根據Topic進行歸類，發送消息者成爲Producer,消息接受者成爲Consumer,此外kafka集羣有多個kafka實例組成，每個實例(server)成爲broker。無論是kafka集羣，還是producer和consumer都依賴於zookeeper來保證系統可用性集羣保存一些meta信息。
Kafka:是一個分佈式的（可以多節點），分區的，多副本的，多訂閱者的消息發佈訂閱系統。
Kafka對消息分類使用topic（一個分類，一個類別）
生產者：Producer(製造數據、生產數據的，將消息推送到隊列的)
消費者：Consumer（讀取數據的，瀏覽數據的，在隊列中獲取數據）
服務器：Broker
4.2 kafka的好處
1、可靠性：分佈式的，分區，複製和容錯。
2、可擴展性：kafka消息傳遞系統輕鬆縮放，無需停機。
3、耐用性：kafka使用分佈式提交日誌，這意味着消息會盡可能快速的保存在磁盤上，因此它是持久的。
4、性能：kafka對於發佈和定於消息都具有高吞吐量。即使存儲了許多TB的消息，他也爆出穩定的性能。
kafka非常快：保證零停機和零數據丟失
Kafka的補充說明：
kafka消息保留在磁盤上，並在集羣內複製以防止數據丟失（不能提高數據的讀取效率）。
消費端爲拉模型來主動拉取數據。
1、Consumer Group：每一個Consumer屬於一個特定的Consumer Group（可以爲每個Consumer指定 groupName）
2、Broker：kafka集羣中包含一個或者多個服務實例
3、Topic：每條發佈到kafka集羣的消息都有一個類別，分類
4、Partition：Partition是一個物理上的概念，每個Topic包含一個或者多個Partition
5、segment：一個partition當中存在多個segment文件段，每個segment分爲兩部分，.log文件和.index文件，
其中.index文件是索引文件，主要用於快速查詢.log文件當中數據的偏移量位置
.log存放數據文件
4.3 分佈式的發佈與訂閱系統
apache kafka是一個分佈式發佈-訂閱消息系統和一個強大的隊列，可以處理大量的數據，並使能夠將消息從一個端點傳遞到另一個端點，kafka適合離線和在線消息消費。
kafka消息保留在磁盤上，並在集羣內複製以防止數據丟失。
kafka構建在zookeeper同步服務之上。它與apache和spark非常好的集成，應用於實時流式數據分析
4.4 kafka的主要應用場景
指標分析
kafka通常用於操作監控數據。用於接收、聚合來自多種應用程序的統計信息， 以便於向產生環境中的數據集中反饋數據
日誌聚合解決方法
kafka可用於跨組織從多個服務器收集日誌，並使他們以標準的合適提供給多個服務器。
流式處理
流式處理框架（spark，storm，flink）從主題中讀取數據，對齊進行處理，並將處理後的數據寫入新的主題，供用戶和應用程序使用，kafka的強耐久性在流處理的上下文中也非常的有用。
5、kafka的架構介紹
1、生產者API
允許應用程序發佈記錄流至一個或者多個kafka的主題（topics）。
2、消費者API
允許應用程序訂閱一個或者多個主題，並處理這些主題接收到的記錄流。
3、StreamsAPI
允許應用程序充當流處理器（stream processor），從一個或者多個主題獲取輸入流，並生產一個輸出流到一個或 者多個主題，能夠有效的變化輸入流爲輸出流。
4、ConnectAPI
允許構建和運行可重用的生產者或者消費者，能夠把kafka主題連接到現有的應用程序或數據系統。例如：一個連接到關係數據庫的連接器可能會獲取每個表的變化。
6、kafka架構內部細節剖析
從左到右流程架構圖
從上到下流程架構圖
補充說明：
kafka支持消息持久化，消費端爲拉模型來拉取數據，消費狀態和訂閱關係有客戶端負責維護，消息消費完後，不會立即刪除，會保留歷史消息。因此支持多訂閱時，消息只會存儲一份就可以了。
Broker：kafka集羣中包含一個或者多個服務實例，這種服務實例被稱爲Broker
Topic：每條發佈到kafka集羣的消息都有一個類別，這個類別就叫做Topic
Partition：Partition是一個物理上的概念，每個Topic包含一個或者多個Partition
segment：一個partition當中存在多個segment文件段，每個segment分爲兩部分，.log文件和.index文件，其中.index文件是索引文件，主要用於快速查詢.log文件當中數據的偏移量位置
Producer：負責發佈消息到kafka的Broker中。
Consumer：消息消費者,向kafka的broker中讀取消息的客戶端
Consumer Group：每一個Consumer屬於一個特定的Consumer Group（可以爲每個Consumer指定 groupName）
.log:存放數據文件
.index：存放.log文件的索引數據
7、kafka主要組件說明
7.1 kafka當中的生產者(Producer)r說明
producer主要是用於生產消息，是kafka當中的消息生產者，生產的消息通過topic進行歸類，保存到kafka的broker裏面去
7.2 kafka當中的主題（Topic）說明
1、kafka將消息以topic爲單位進行歸類
2、topic特指kafka處理的消息源（feeds of messages）的不同分類。
3、topic是一種分類或者發佈的一些列記錄的名義上的名字。kafka主題始終是支持多用戶訂閱的；也就是說，一個主題可以有零個，一個或者多個消費者訂閱寫入的數據。
4、在kafka集羣中，可以有無數的主題。
5生產者和消費者消費數據一般以主題爲單位。更細粒度可以到分區級別。
7.3 kafka當中的分區（Partition）說明
kafka當中，topic是消息的歸類，一個topic可以有多個分區，每個分區保存部分topic的數據，所有的partition當中的數據全部合併起來，就是一個topic當中的所有的數據，
一個broker服務下，是否可以創建多個分區？
可以的，broker數與分區數沒有關係； 在kafka中，每一個分區會有一個編號：編號從0開始
每一個分區的數據是有序的
說明-數據是有序 如何保證一個主題下的數據是有序的？（生產是什麼樣的順序，那麼消費的時候也是什麼樣的順序）
多個分區時無序的.分區數在創建topic時設置，並後期可以修改。
topic的Partition數量在創建topic時配置。
Partition數量決定了每個Consumer group中併發消費者的最大數量 （效率最高的情況）。
Partition = 併發度: 剛剛好，效率最高
Partition > 併發度：有部分消費者消費多個分區的數據。
Partition < 併發度 :有部分消費者閒置（任意時刻一個分區內的一條數據只能被消費組中的一個消費者消費）
例如：Consumer group A 有兩個消費者來讀取4個partition中數據；Consumer group B有四個消費者來讀取4個 partition中的數據
7.4 kafka當中partition的副本數說明
kafka分區副本數（kafka Partition Replicas)
副本數（replication-factor）：控制消息保存在幾個broker（服務器）上，一般情況下小於等於broker的個數
例如：一個broker服務下，是否可以創建多個副本因子？
不可以；創建主題時，副本因子應該小於等於可用的broker數。 副本因子過程圖
副本因子操作以分區爲單位的。每個分區都有各自的主副本和從副本；
主副本叫做leader，從副本叫做 follower（在有多個副本的情況下，kafka會爲同一個分區下的所有分區，設定角色關係：一個leader和N個 follower），處於同步狀態的副本叫做in-sync-replicas(ISR);
follower通過拉的方式從leader同步數據。
消費者和生產者都是從leader讀寫數據，不與follower交互。
副本因子的作用：讓kafka讀取數據和寫入數據時的可靠性。
副本因子是包含本身，同一個副本因子不能放在同一個Broker中。
如果某一個分區有三個副本因子，就算其中一個掛掉，那麼只會剩下的兩個中，選擇一個leader，但不會在其他的broker中，另啓動一個副本（因爲在另一臺啓動的話，存在數據傳遞，只要在機器之間有數據傳遞，就會長時間佔用網絡IO，kafka是一個高吞吐量的消息系統，這個情況不允許發生）所以不會在零個broker中啓動。
如果所有的副本都掛了，生產者如果生產數據到指定分區的話，將寫入不成功。
lsr表示：當前可用的副本（是一個列表，表示數據副本在那幾個節點上）
7.5 kafka當中的segment說明
一個partition當中有多個segment文件組成，每個segment文件，包含兩部分，一個是.log文件，另外一個是.index文件，其中.log文件包含了我們發送的數據存儲，.index文件，記錄的是我們.log文件的數據索引值，以便於我們加快數據的查詢速度
索引文件與數據文件的關係
既然它們是一一對應成對出現，必然有關係。索引文件中元數據指向對應數據文件中message的物理偏移地址
比如：索引文件中3,497代表：數據文件中的第三個message,它的偏移地址爲497。再來看數據文件中，
Message 368772表示：在全局partiton中是第368772個message。
注：segment index file採取稀疏索引存儲方式，它減少索引文件大小，通過mmap可以直接內存操作，稀疏索引爲數據文件的每個對應message設置一個元數據指針,它比稠密索引節省了更多的存儲空間，但查找起來需要消耗更多的時間。
7.6 kafka當中的partition的offset
任何發佈到此partition的消息都會被直接追加到log文件的尾部，每條消息在文件中的位置稱爲offset（偏移量），
offset是一個long類型數字，它唯一標識了一條消息，消費者通過（offset，partition，topic）跟蹤記錄。
7.7 kafka分區與消費組的關係
消費組： 由一個或者多個消費者組成，同一個組中的消費者對於同一條消息只消費一次。
某一個主題下的分區數，對於消費組來說，消費者應該小於等於該主題下的分區數。如下所示：
如：某一個主題有4個分區，那麼消費組中的消費者應該小於4，而且最好與分區數成整數倍1 2 4同一個分區下的數據，在同一時刻，不能同一個消費組的不同消費者消費
總結：分區數越多，同一時間可以有越多的消費者來進行消費，消費數據的速度就會越快，提高消費的性能
7.8 kafka當中的consumer
consumer是kafka當中的消費者，主要用於消費kafka當中的數據，任何一個消費者都必定需要屬於某一個消費組當中。
任意時刻，一個分區當中的數據，只能被kafka當中同一個消費組下面的一個線程消費
8、consumer消費者消費數據流程
流程描述
Consumer連接指定的Topic partition所在leader broker，採用pull方式從kafkalogs中獲取消息。對於不同的消費模式，會將offset保存在不同的地方
1、 Consumer連接指定的Topic partition所在leader broker
2、 採用pull方式從kafkalogs中獲取消息。
高階API: 隱藏Consumer與Broker細節,封裝好的接口。工程師直接使用，無需關注細節。
低階API:使用靈活，用戶自己維護連接Controller Broker，存儲，更新offset。
實時計算：實時成產-實時傳遞-實時計算-實時存儲-實時展現
官網關於high level API 以及low level API的簡介
http://kafka.apache.org/0100/documentation.html#impl_consumer
9、kafka的log-存儲機制
9.1、kafka中log日誌目錄及組成
kafka在我們指定的log.dir目錄下，會創建一些文件夾；名字是【主題名字-分區名】所組成的文件夾。 在【主題名字-分區名】的目錄下，會有兩個文件存在，如下所示：
#索引文件
00000000000000000000.index
#日誌內容
0000000000000000000.log
在目錄下的文件，會根據log日誌的大小進行切分，.log文件的大小爲1G的時候，就會進行切分文件；
在kafka的設計中，將offset值作爲了文件名的一部分
比如：topic的名字爲：test，有三個分區，生成的目錄如下如下所示：
test-0
test-1
test-2
kafka日誌的組成
segment file組成：由兩個部分組成，分別爲index file和data file，此兩個文件一一對應且成對出現； 後綴.index和.log分別表示爲segment的索引文件、數據文件。
segment文件命名規則：partion全局的第一個segment從0開始，後續每個segment文件名爲上一個全局 partion的最大offset（偏移message數）。數值最大爲64位long大小，19位數字字符長度，沒有數字就用0 填充。
通過索引信息可以快速定位到message。通過index元數據全部映射到memory，可以避免segment file的IO磁盤操作；
通過索引文件稀疏存儲，可以大幅降低index文件元數據佔用空間大小。 稀疏索引：爲了數據創建索引，但範圍並不是爲每一條創建，而是爲某一個區間創建；
好處：就是可以減少索引值的數量。
不好的地方：找到索引區間之後，要得進行第二次處理。
10、kafka的offset查找過程
比如：要查找絕對offset爲7的Message：
上圖的左半部分是索引文件，裏面存儲的是一對一對的key-value，其中key是消息在數據文件（對應的log文件）中的編號，比如“1,3,6,8……”，分別表示在log文件中的第1條消息、第3條消息、第6條消息、第8條消息……，那麼爲什麼在index文件中這些編號不是連續的呢？這是因爲index文件中並沒有爲數據文件中的每條消息都建立索引，而是採用了稀疏存儲的方式，每隔一定字節的數據建立一條索引。這樣避免了索引文件佔用過多的空間，從而可以將索引文件保留在內存中。但缺點是沒有建立索引的Message也不能一次定位到其在數據文件的位置，從而需要做一次順序掃描，但是這次順序掃描的範圍就很小了。
其中以索引文件中元數據3,4597爲例，其中3代表在右邊log數據文件中從上到下第3個消息(在全局partiton表示第4597個消息)，
其中4597表示該消息的物理偏移地址（位置）爲4597。
kafka Message的物理結構及介紹
kafka Message的物理結構，如下圖所示：
kafka中log CleanUp
kafka中清理日誌的方式有兩種：delete和compact。
刪除的閾值有兩種：過期的時間和分區內總日誌大小。
在kafka中，因爲數據是存儲在本地磁盤中，並沒有像hdfs的那樣的分佈式存儲，就會產生磁盤空間不足的情況，可以採用刪除或者合併的方式來進行處理
可以通過時間來刪除、合併：默認7天（log.retention.hours）
還可以通過字節大小、合併：默認-1 無限制（log.retention.bytes）
相同的key，保存offset值大的（最新的消息記錄）
11、kafka消息不丟失制
11.1、生產者生產數據不丟失
11.1.1、生產者數據不丟失過程圖
說明：有多少個分區，就啓動多少個線程來進行同步數據
11.1.2、發送數據方式
可以採用同步或者異步的方式-過程圖
可以採用同步或者異步的方式
同步：發送一批數據給kafka後，等待kafka返回結果
1、生產者等待10s，如果broker沒有給出ack相應，就認爲失敗。
2、生產者重試3次，如果還沒有相應，就報錯
異步：發送一批數據給kafka，只是提供一個回調函數。
1、先將數據保存在生產者端的buffer中。buffer大小是2萬條
2、滿足數據閾值或者數量閾值其中的一個條件就可以發送數據。
3、發送一批數據的大小是500條
說明：如果broker遲遲不給ack，而buffer又滿了，開發者可以設置是否直接清空buffer中的數據。
11.1.3、ack機制（確認機制）
生產者數據不抵事，需要服務端返回一個確認碼，即ack響應碼；ack的響應有三個狀態值
0：生產者只負責發送數據，不關心數據是否丟失，響應的狀態碼爲0（丟失的數據，需要再次發送 ）
1：partition的leader收到數據，響應的狀態碼爲1
-1：所有的從節點都收到數據，響應的狀態碼爲-1
說明：如果broker端一直不給ack狀態，producer永遠不知道是否成功；producer可以設置一個超時時間10s，超 過時間認爲失敗。
11.2、kafka的broker中數據不丟失
在broker中，保證數據不丟失主要是通過副本因子（冗餘），防止數據丟失
11.3、消費者消費數據不丟失
在消費者消費數據的時候，只要每個消費者記錄好offset值即可，就能保證數據不丟失。
12、kafka監控及運維
在開發工作中，消費在Kafka集羣中消息，數據變化是我們關注的問題，當業務前提不復雜時，我們可以使用Kafka 命令提供帶有Zookeeper客戶端工具的工具，可以輕鬆完成我們的工作。隨着業務的複雜性，增加Group和 Topic，那麼我們使用Kafka提供命令工具，已經感到無能爲力，那麼Kafka監控系統目前尤爲重要，我們需要觀察 消費者應用的細節。
kafka-eagle概述
爲了簡化開發者和服務工程師維護Kafka集羣的工作有一個監控管理工具，叫做 Kafka-eagle。這個管理工具可以很容易地發現分佈在集羣中的哪些topic分佈不均勻，或者是分區在整個集羣分佈不均勻的的情況。它支持管理多個集羣、選擇副本、副本重新分配以及創建Topic。同時，這個管理工具也是一個非常好的可以快速瀏覽這個集羣的工具。