kafka是apache基金會管理的開源流處理平臺(官網http://kafka.apache.org/)，但國內大多數人對其認知基本都是消息隊列，所以我們先來了解下什麼是消息隊列。
消息隊列
消息隊列顧名思義就是存儲消息的一個隊列，消息生產者(producer) 往消息隊列中投放消息， 消費者(consumer)讀取消息隊列中的內容。在消息隊列中的每條消息都會有個位置，就好比數組中的下標(index)，在kafka中我們稱之爲offset。對於生產者而言，有個特殊的offset——LEO(log end offset) ，指向的是消息隊列中下一個將被存放消息的位置。
這裏重點說下消費者(consumer)，一個消息隊列當然可以被多個消費者(consumer)讀取，每個消費者(consumer)都有唯一一個group-id將其區分開來。kafka也會記錄下來每個消費者(consumer)已經讀到哪個位置了(offset)。
問：爲什麼消費者消費的offset是由kafka記錄，而不是由消費者自己記錄？
主題(Topic)
上文我們以一份數據爲例，講了什麼是消息隊列。如果有多份數據（多個隊列）該怎麼辦？ 也很簡單，kafka中我們可以使用不同的主題(Topic)將不同的數據區分開。不同的生產者(producer)可以往不同的Topic中存放數據，不同的消費者(consumer)也可以從不同的Topic中讀取數據。
分區(Partation)
當一份數據非常大的情況下怎麼辦？ 當然是考慮拆分了。在kafka中，你可以設置將一個主題(Topic)拆分成多個不同的分區(Partation)，然後以分區(Partation)的維度來管理、生產和消費數據。 拆分帶來最明顯的好處就是提升吞吐性能，多個分區(Partation)之間並行，互不干擾。
至於怎麼拆分，kafka有提供幾個默認分區策略 輪詢、隨機、hash，當然你可以自己實現自己的分區策略，這裏就不過多展開了。
消費者組(Consumer-group)
主題(Topic)做完分區以後，消費者如何消費？ 這裏就不得不提到消費者組(Consumer-group)的概念，在kafka中，爲了保證數據的一致性，同一個分區(Partation)同時只能被一個消費者(consumer)實例消費，爲了提升消費者(consumer)的吞吐量，一般都會設置多個消費者(consumer)實例來消費不同的分區(Partation)，這些實例共同組成一個消費者組(Consumer-group) ，他們共用一個Group-id。
注意：
- 由於同一個分區(Partation)同時只能被一個消費者(consumer)實例消費，所以超過分區(Partation)數量的消費者(consumer)實例個數沒有任何意義，多餘的消費者(consumer)實例也會被閒置。
- 如果消費者組(Consumer-group) 中有實例發生變化（上下線），或者分區(Partation)數量發生變化，都會觸發消費者組rebalence。
副本(Replication)
kafka如何解決數據高可用的問題？在分佈式環境下，要想保證數據儘可能不丟失，唯一的方法就是多複製幾份放到不同的機器上，複製出來的數據就叫做副本(Replication)。
這裏有幾個關鍵詞。
HW： high-water，一個特殊的offset，只有在這個offset以下的消息才能被消費者(consumer)讀到，高水位的具體值取決於主從副本數據同步的狀態，這裏不再展開。
ISR: in-sync-replica，處於同步狀態的副本集合，是指副本數據和主副本數據相差在一定返回（時間範圍或數量範圍）之內的副本，當然主副本肯定是一直在ISR中的。 當主副本掛了之後，新的主副本將從ISR中被選出來接替它的工作。
OSR: 和IRS相對應 out-sync-replica，其實就是指那些不在ISR中的副本。
副本主從同步
當一份數據比複製出多份副本後，肯定得涉及到主從副本的同步在，從副本會定期從主副本拉去最新的數據。 另外需要注意kafka中，只有主副本纔會對外提供讀和寫(高版本kafka從副本提供了有限的讀功能)，從副本的唯一作用就是給主副本當備胎。
說到主從同步，順帶提一下kafka的ack設置。
kafka中生產者(producer)，可以通過request.required.acks參數來設置數據可靠性的級別：
- 0: 生產者(producer) 不等待來自主副本的確認，發出去即認爲發送成功，這種情況效率最高但可能有丟失數據的風險。
- 1: （默認）生產者(producer) 發出數據後會等待主副本確認收到後，才認爲消息發送成功，這種情況下主副本宕機時可能會丟失消息。
- -1: (或者是all)：生產者(producer) 等待ISR中的所有副本都確認接收到數據後才任務消息發送成功，可靠性最高，但因爲需要等從副本拉去和確認，效率最低。
Broker
Kafka是以副本(Replica)維度管理數據的，管理這些數據肯定是需要管理者的，這個管理者就是Broker。Broker會將同一份數據的不同副本(Replication) 調度到不同的機器上，並且在副本(Replication) 數不足時生成新的副本，從而保證在部分Broker宕機後也能保證數據不丟失。
所有的Broker之間也會做一些元數據的相互同步，比如某份主數據在誰哪，從副本要從誰哪去拉取數據……
結語
第一次嘗試手繪風講解kafka入門知識，講的很粗淺，確實很多細節都沒有展開，見諒。