Kafka入門系列（一）：Kafka概述
文章目錄
1. Kafka概述
1.1. 定義
Kafka 是一個分佈式的基於發佈/訂閱模式的消息隊列（Message Queue） ， 主要應用於大數據實時處理領域。
1.2. 消息隊列
1.2.1. 傳統消息隊列的應用場景
1.2.2. 使用消息隊列的好處
1） 解耦
允許你獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。
2）靈活性 & 峯值處理能力 – 削峯
在訪問量劇增的情況下，應用仍然需要繼續發揮作用，但是這樣的突發流量並不常見。
如果爲以能處理這類峯值訪問爲標準來投入資源隨時待命無疑是巨大的浪費。使用消息隊列能夠使關鍵組件頂住突發的訪問壓力，而不會因爲突發的超負荷的請求而完全崩潰。
3） 異步通信
很多時候，用戶不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但並不立即處理它。想向隊列中放入多少消息就放多少，然後在需要的時候再去處理它們。
4）緩衝
有助於控制和優化數據流經過系統的速度，解決生產消息和消費消息的處理速度不一致的情況。
5） 可恢復性
系統的一部分組件失效時，不會影響到整個系統。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統恢復後被處理。
1.3. 消息隊列的兩種模式
1.3.1. 點對點模式
（一對一，消費者主動拉取數據，消息收到後消息清除）
消息生產者生產消息發送到 Queue中，然後消息消費者從 Queue中取出並且消費消息。消息被消費以後， queue 中不再有存儲，所以消息消費者不可能消費到已經被消費的消息。Queue 支持存在多個消費者，但是對一個消息而言，只會有一個消費者可以消費。
1.3.2. 發佈/訂閱模式
（一對多，消費者消費數據之後不會清除消息）
消息生產者（發佈）將消息發佈到 topic 中，同時有多個消息消費者（訂閱）消費該消息。和點對點方式不同，發佈到 topic 的消息會被所有訂閱者消費。
有點像訂閱微信公衆號
兩種：1）微信公衆號類型：生產者主動推送數據
2）kafka類型:消費者主動拉取數據；
缺點：有點浪費資源，需要一直去Topic詢問是否有消息。
1.4. Kafka架構
- Producer
消息生產者，就是向 kafka broker 發消息的客戶端； - Consumer
消息消費者，向 kafka broker 取消息的客戶端； - Consumer Group （CG）：
消費者組，由多個 consumer 組成。 消費者組內每個消費者負責消費不同分區的數據，一個分區只能由一個組內消費者消費；消費者組之間互不影響。 所有的消費者都屬於某個消費者組，即消費者組是邏輯上的一個訂閱者。 - Broker
一臺 kafka 服務器就是一個 broker。一個集羣由多個 broker 組成。一個 broker可以容納多個 topic。 - Topic
可以理解爲一個隊列， 生產者和消費者面向的都是一個 topic； - Partition
爲了實現擴展性，一個非常大的 topic 可以分佈到多個 broker（即服務器）上，一個 topic 可以分爲多個 partition，每個 partition 是一個有序的隊列； - Replica
副本，爲保證集羣中的某個節點發生故障時， 該節點上的 partition 數據不丟失，且 kafka 仍然能夠繼續工作，kafka 提供了副本機制，一個 topic 的每個分區都有若干個副本，一個 leader 和若干個 follower。 - leader
每個分區多個副本的“主”，生產者發送數據的對象，以及消費者消費數據的對象都是 leader。 - leader
每個分區多個副本中的“從”，實時從 leader 中同步數據，保持和 leader 數據的同步。 leader 發生故障時，某個 follower 會成爲新的 leader。
【說明】
一個分區只能被同一個消費者組裏面的一個消費者消費。（可以被其他消費者組裏面的某一個消費者消費）
0.9版本之前：
offset存儲在ZK中
消費者消費到第幾條數據（數據的位置），會保存在zookeeper裏。
0.9版本之後：
offset存儲在kafka本地（存在磁盤，保存7天）。