一.安裝
本文采用的安裝方式是Ubuntu:16.04 版本的Linux安裝。
先找個目錄準備wget下載kafka的安裝包 kafka下載地址是這http://kafka.apache.org/downloads.html
cd /home
wget http://mirrors.tuna.tsinghua.edu.cn/apache/kafka/2.3.0/kafka_2.11-2.3.0.tgz //直接wget拿壓縮包了。
mkdir kafka //把壓縮包解壓到這裏了。爲啥要解壓到這裏，或許只是強迫症。
當前目錄執行 tar -zxvf kafka_2.11-2.3.0.tgz -C kafka 解壓到 kafka目錄下了。
cd /home/kafka/kafka_2.11-2.3.0/bin //接下來就是執行可執行文件來運行kafka的消費者和生產者。
sh zookeeper-server-start.sh ../config/zookeeper.properties & //kafka必須有zookeeper調度。
sh kafka-server-start.sh ../config/server.properties & //起kafka 注意這個properties不同版本的位置可能不一樣
netstat -tunlp|egrep "(2181|9092)" 看是否啓動成功了。
像下面這樣就行了。端口號是默認的。要改就改配置文件。可以改但沒必要。
二.運行
下面創建一個生產者。
sh kafka-console-producer.sh --broker-list localhost:9092 --topic testKafka 創建生產者。此時你的界面是讓你輸入的界面。如下所示，隨便寫點啥。
然後再創建一個消費者。這時需要注意的是重建一個窗口(如果你是xshell這種遠程連的也重建一個連接)，這個窗口也不要關。在新建的窗口的bin文件夾下 /home/kafka/kafka_2.11-2.3.0/bin 執行下面這句命令。
sh kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic testKafka --from-beginning
接下來就會看到testKafka的topic被我消費掉了。
如上就是安裝及運行測試需要的整個過程。
三. 爬坑
其實網上有的教程是有一些細節沒說明白的。
在創建消費者時，有的教程可能是像下面這麼讓你執行的。
sh kafka-console-consumer.sh --topic test --zookeeper localhost:2181 --from-beginning
然後你會得到下面的這個錯誤。zookeeper 不認識這個執行選項、
zookeeper is not a recognized option
那是因爲你的kafka下載的版本與網上某些博主不同。下載最新的穩定版執行下面這個命令就ok了。舊版本我就不探究了。
sh kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test --from-beginning
四. 學習kafka設想的幾個問題
0.爲什麼使用消息隊列?消息隊列的作用是什麼?
1.kafka裏面都使用的啥對象？
2.kafka數據如何存儲的？
3.kafka有topic爲啥還要引入partition ？
4.消息消費完是刪掉還是怎麼滴？
5.消息存在哪？
6.kafka如何實現分佈式存儲，還能正確消費？
7.kafka爲啥高效，高吞吐？
8.kafka配置文件怎麼配置？
9.kafka與其他消息隊列相比的優劣。
0.爲什麼使用消息隊列?消息隊列的作用是什麼?
答：參考了這篇文章。https://blog.csdn.net/cws1214/article/details/52922267
消息隊列的特性: 容災，業務無關，提高性能。
這兩個問題也可以合成一個: 消息隊列的使用場景
1.異步處理2.應用解耦3.流量削峯4.日誌處理5.消息通訊(websocket)
1.異步處理是將重要級相對低的操作寫入隊列。有消費者常駐進程不停的消費這個消息。這樣系統就能快速響應了。
消息寫入到隊列中，常駐進程拿消息調一些發短信，發郵件之類的接口。
2.應用解耦
如果有訂單模塊和庫存模塊。
用戶下單後，訂單系統將消息寫到消息隊列裏。返回用戶處理中。然後此時庫存系統從消息隊列拿消息進而處理返回給顯示界面處理結果。
如果沒有消息隊列的存在。 訂單調庫存系統時，庫存系統宕機了。那麼此時頁面返回的就是500這種了。
首先消息隊列肯定是沒問題的。即使單節點宕機，也會有副本再變成主節點。 那麼當你庫存系統恢復了就可以正常消費了。
3.流量削峯
秒殺和搶購活動中。防止流量過大導致應用程序down掉。
用戶請求會寫入消息隊列的對應topic中。 假如消息隊列長度超過了最大數量，就直接拋棄用戶請求或跳轉錯誤頁面。
然後對應邏輯系統根據消息隊列中順序來執行秒殺數量的請求。
當然你程序裏面寫一個值來控制秒殺數量從而解決併發請求也是可以的。
4.日誌處理
解決大量日誌傳輸的問題
日誌寫到kafka logstash做日誌解析，統一成JSON 輸出到 ElasticSearch
在用kibana可視化查看ES日誌就行了。
5.消息通訊(這個就用websocket就行了)
1.kafka裏面使用的對象。
答：摘自文章：https://blog.csdn.net/tflasd1157/article/details/81985722
消息記錄(record): 由一個key，一個value和一個時間戳構成，消息最終存儲在主題下的分區中, 記錄在生產者中稱爲生產者記錄(ProducerRecord), 在消費者中稱爲消費者記錄(ConsumerRecord)，Kafka集羣保持所有的消息，直到它們過期， 無論消息是否被消費了，在一個可配置的時間段內，Kafka集羣保留所有發佈的消息，不管這些消息有沒有被消費。比如，如果消息的保存策略被設置爲2天，那麼在一個消息被髮布的兩天時間內，它都是可以被消費的。之後它將被丟棄以釋放空間。Kafka的性能是和數據量無關的常量級的，所以保留太多的數據並不是問題。
生產者(producer): 生產者用於發佈(send)消息
消費者(consumer): 消費者用於訂閱(subscribe)消息
消費者組(consumer group): 相同的group.id的消費者將視爲同一個消費者組, 每個消費者都需要設置一個組id, 每條消息只能被 consumer group 中的一個 Consumer 消費,但可以被多個 consumer group 消費
主題(topic): 消息的一種邏輯分組，用於對消息分門別類，每一類消息稱之爲一個主題，相同主題的消息放在一個隊列中
分區(partition): 消息的一種物理分組， 一個主題被拆成多個分區，每一個分區就是一個順序的、不可變的消息隊列，並且可以持續添加，分區中的每個消息都被分配了一個唯一的id，稱之爲偏移量(offset),在每個分區中偏移量都是唯一的。每個分區對應一個邏輯log，有多個segment組成。
偏移量(offset): 分區中的每個消息都一個一個唯一id，稱之爲偏移量，它代表已經消費的位置。可以自動或者手動提交偏移量(即自動或者手動控制一條消息是否已經被成功消費)
代理(broker): 一臺kafka服務器稱之爲一個broker
副本(replica)：副本只是一個分區(partition)的備份。 副本從不讀取或寫入數據。 它們用於防止數據丟失。
領導者(leader)：Leader 是負責給定分區的所有讀取和寫入的節點。 每個分區都有一個服務器充當Leader， producer 和 consumer 只跟 leader 交互
追隨者(follower)：跟隨領導者指令的節點被稱爲Follower。 如果領導失敗，一個追隨者將自動成爲新的領導者。 跟隨者作爲正常消費者，拉取消息並更新其自己的數據存儲。replica 中的一個角色，從 leader 中複製數據。
zookeeper：Kafka代理是無狀態的，所以他們使用ZooKeeper來維護它們的集羣狀態。ZooKeeper用於管理和協調Kafka代理
kafka功能
發佈訂閱：生產者(producer)生產消息(數據流), 將消息發送到到kafka指定的主題隊列(topic)中，也可以發送到topic中的指定分區(partition)中，消費者(consumer)從kafka的指定隊列中獲取消息，然後來處理消息。
流處理(Stream Process): 將輸入topic轉換數據流到輸出topic
連接器(Connector) : 將數據從應用程序(源系統)中導入到kafka，或者從kafka導出數據到應用程序(宿主系統sink system), 例如：將文件中的數據導入到kafka，從kafka中將數據導出到文件中
kafka中的消息模型
隊列：同名的消費者組員瓜分消息
發佈訂閱：廣播消息給多個消費者組(不同名)
消費模型。消費模型有兩種，push和pull 這個push是適用消息代理，將消息從kafka(broker)主動推給消費者進程。消費時標記爲已消費，並將消息處理掉、
如果消費者進程掛掉會導致消息永久丟失。很一些問題，所以不採用。
還有一種消費類型是pull 這種是消費者進程主動從broker中拉消息。 由消費者自己控制消費的進度，可以按照offset任意獲取消息。採用這種。
網絡模型。 kafka的客戶端(producer/consumer)可以使用單線程的selector還可以使用多線程的selector
2.kafka數據如何存儲的？
答：摘自簡書：https://www.jianshu.com/p/4bf007885116
高性能的分佈式存儲模型
在kafka中保證高可靠模型依靠的是副本機制，有了副本機制之後，計算機器宕機也不會發生數據丟失。
高性能的日誌存儲。 (一股jdk7的concurrentHashMap氣息)
每一個partition都會對應一個日誌目錄。一個目錄下有多個logSegement 一個logSegement分爲三部分: xxx.index xxxxx.log xxx.timeindex
兩個文件的命名規則爲：每個partition的第一個全局segement 從0開始。後續每個segement文件名爲上一個segement文件最後一條消息的Offset值。
沒有數字用0填充。 下面白話文補充說明一下、
索引和存儲數據的log文件名稱是一樣的，只是拓展名不一樣。 00000100.index 00000100.log 這種。 爲key:value
其中 00000000.index 存儲的是本分區offset的稀疏索引。例如 100條消息，index裏面可能只存了7條 這7條消息根據算法爲步增很高的值。例 7,20,34,55,77,100
然後查找 00000000.index這個索引文件(文件存儲類似步增的真實消息位置) 比如111 111-100=11 通過二分法查找index中key爲小於等於最接近11的、也就是7 然後找log文件中 offset等於107的開始往後找，直到找到111 遍歷log文件就不是O(n)了，向後直到找到111的key。此時就獲取到了 111的offset值。
上述是一個查找到指定offset處消息的過程。 正常情況就是順序讀的，順序讀就很快了，不用這麼費勁，就從0開始往後讀
3.kafka有topic爲啥還要引入partition ？
topic是邏輯的概念，partition是物理的概念，對用戶來說是透明的。
producer只需要關心消息發往哪個topic，而consumer只關心自己訂閱哪個topic，並不關心每條消息存於整個集羣的哪個broker。
若沒有分區，一個topic對應的消息集在分佈式集羣服務組中，就會分佈不均勻。
即可能導致某臺服務器A記錄當前topic的消息集很多，若此topic的消息壓力很大的情況下，服務器A就可能導致壓力很大，吞吐也容易導致瓶頸。
有了分區後，假設一個topic可能分爲10個分區，kafka內部會根據一定的算法把10分區儘可能均勻分佈到不同的服務器上。
比如：A服務器負責topic的分區1，B服務器負責topic的分區2，在此情況下，Producer發消息時若沒指定發送到哪個分區的時候，kafka就會根據一定算法上個消息可能分區1，下個消息可能在分區2。
4.消息消費完是刪掉還是怎麼滴？
答：摘自：https://blog.csdn.net/gdkyxy2013/article/details/86644919
跟配置文件有關，消息會過期自動刪除，消費者消費消息超時也會導致消息堆積。
消費者進程消費一個消息後，消息所在分區的offset會進行位移。
由於分區segement中記錄的是真實消息的物理地址。這樣下次消費就從另一個offset指定的物理地址進行尋址了。
使用消費者組會增加消息消費的速度。
啓動多個組，相同的數據會被不同組的消費者消費多次。 因此多個消費者組消費同一個topic消息沒必要
5.消息存在哪？
消息存儲在了 000000xxxxx.log文件中。 首先找到server.properties文件 看日誌要往哪寫。默認是/tmp/kafka-logs/
然後可以使用下面這條命令來查看消息。在kafka的bin目錄下執行。 testzy-0根據你的topic來調整。
sh kafka-run-class.sh kafka.tools.DumpLogSegments --files /tmp/kafka-logs/testzy-0/00000000000000000000.log --print-data-log
6.kafka如何實現分佈式存儲，還能正確消費？
答：參考：https://blog.csdn.net/lizhitao/article/details/51718185 & https://www.jianshu.com/p/4bf007885116
副本機制
kafka的副本機制是多個服務端節點對其他節點的主題分區的日誌進行復制。
當集羣中的某個節點發生故障時，訪問故障節點的請求會被轉移到其他正常節點。(reblance) 也就是多個broker使用zookeeper的意義。
kafka每個主題的每個分區都有一個主副本和多個副本。 副本保持與主副本同步，當主副本出現故障時就會被替換。
kafka中也不是所有的副本都可以成爲主副本。 維護這兩個集合 ISR(In Sync Replicas)同步中集合，包括主副本(leader)和沒有落後太多的副本
replica.lag.max.messages : 4 就是落後主副本4個消息才從ISR移除。 replica.lag.time.max : 500ms follow向leader發送請求超時時間間隔
副本機制與zookeeper也有通信。
需要滿足兩個條件1.節點必須要與zookeeper保持連接。2.在同步的過程中這個副本不能落後主副本太多。
AR(Assigned Replicas)副本的集合 AR = ISR + 落後太多的副本。
HW(高水位)是consumer能夠看到的此partition的位置，LEO是每個partition的log最後一條message的位置。
HW能保證leader所在的broker宕機，該消息仍然可以從新選舉的leader中獲取，不會造成信息丟失。
當 Producer 向 Leader 發送數據時，可以通過 request.required.acks 參數來設置數據可靠性的級別：
• 1(默認)：這意味着 Producer 在 ISR 中的 Leader 已成功收到的數據並得到確認後發送下一條 Message。如果 Leader 宕機了，則會丟失數據。
• 0：這意味着 Producer 無需等待來自 Broker 的確認而繼續發送下一批消息。這種情況下數據傳輸效率最高，但是數據可靠性卻是最低的。
• -1：Producer 需要等待 ISR 中的所有 Follower 都確認接收到數據後纔算一次發送完成，可靠性最高。
1.是正常情況下的，屬於一個適中的可靠級別。 -1是非常可靠的，但是可想而知，效率比較低。 0 是效率高，但是沒有可靠性、
高可用模型及冪等
冪等：就是多次執行，結果是一樣的。
使用事務來保證冪等。
exactly-once語義
剛好一次，即使 Producer 重試發送消息，消息也會保證最多一次地傳遞給 Consumer。該語義是最理想的，也是最難實現的。
保證操作的原子性，要麼全部成功，要麼全部失敗。
7.kafka爲啥高效，高吞吐？
(1)順序讀寫
kafka的消息是不斷追加到文件中的，這個特性使kafka可以充分利用磁盤的順序讀寫性能
順序讀寫不需要硬盤磁頭的尋道時間，只需很少的扇區旋轉時間，所以速度遠快於隨機讀寫
Kafka官方給出了測試數據( Raid-5，7200rpm )：
順序 I/O: 600MB/s
隨機 I/O: 100KB/s
(2)零拷貝
沒有用戶緩衝區。減少上下文切換
"零拷貝(zero-copy)"系統調用機制，就是跳過“用戶緩衝區”的拷貝，建立一個磁盤空間和內存的直接映射，數據不再複製到“用戶態緩衝區”
(3)文件分段
topic分爲多個partition partition 分爲多個logsegment
(4)批量發送
Kafka允許進行批量發送消息，先將消息緩存在內存中，然後一次請求批量發送出去
比如可以指定緩存的消息達到某個量的時候就發出去，或者緩存了固定的時間後就發送出去
如100條消息就發送，或者每5秒發送一次
這種策略將大大減少服務端的I/O次數
(5)數據壓縮
Kafka還支持對消息集合進行壓縮，Producer可以通過GZIP或Snappy格式對消息集合進行壓縮
壓縮的好處就是減少傳輸的數據量，減輕對網絡傳輸的壓力
Producer壓縮之後，在Consumer需進行解壓，雖然增加了CPU的工作，但在對大數據處理上，瓶頸在網絡上而不是CPU，所以這個成本很值得。
8.kafka配置文件怎麼配置？
答：參考：https://www.cnblogs.com/ashaff/p/11446267.html 太多了。
9.kafka與其他消息隊列相比的優劣
https://blog.csdn.net/u013939918/article/details/70947669
https://blog.csdn.net/ChenRui_yz/article/details/86154132
https://blog.csdn.net/lifaming15/article/details/79942793