初學Kafka工做原理流程介紹

Apache kafka 工做原理介紹

• 消息隊列技術是分佈式應用間交換信息的一種技術。消息隊列可駐留在內存或磁盤上, 隊列存儲消息直到它們被應用程序讀走。經過消息隊列，應用程序可獨立地執行--它們不須要知道彼此的位置、或在繼續執行前不須要等待接收程序接收此消息。在分佈式計算環境中，爲了集成分佈式應用，開發者須要對異構網絡環境下的分佈式應用提供有效的通訊手段。爲了管理須要共享的信息，對應用提供公共的信息交換機制是重要的。經常使用的消息隊列技術是 Message Queue。

• Message Queue 的通信模式

1. 點對點通信：點對點方式是最爲傳統和常見的通信方式，它支持一對1、一對多、多對多、多對一等多種配置方式，支持樹狀、網狀等多種拓撲結構。

2. 多點廣播：MQ 適用於不一樣類型的應用。其中重要的，也是正在發展中的是"多點廣播"應用，即可以將消息發送到多個目標站點 (Destination List)。可使用一條 MQ 指令將單一消息發送到多個目標站點，並確保爲每一站點可靠地提供信息。MQ 不只提供了多點廣播的功能，並且還擁有智能消息分發功能，在將一條消息發送到同一系統上的多個用戶時，MQ 將消息的一個複製版本和該系統上接收者的名單發送到目標 MQ 系統。目標 MQ 系統在本地複製這些消息，並將它們發送到名單上的隊列，從而儘量減小網絡的傳輸量。

3. 發佈/訂閱 (Publish/Subscribe) 模式：發佈/訂閱功能使消息的分發能夠突破目的隊列地理指向的限制，使消息按照特定的主題甚至內容進行分發，用戶或應用程序能夠根據主題或內容接收到所須要的消息。發佈/訂閱功能使得發送者和接收者之間的耦合關係變得更爲鬆散，發送者沒必要關心接收者的目的地址，而接收者也沒必要關心消息的發送地址，而只是根據消息的主題進行消息的收發。

4. 羣集 (Cluster)：爲了簡化點對點通信模式中的系統配置，MQ 提供 Cluster(羣集) 的解決方案。羣集相似於一個域 (Domain)，羣集內部的隊列管理器之間通信時，不須要兩兩之間創建消息通道，而是採用羣集 (Cluster) 通道與其它成員通信，從而大大簡化了系統配置。此外，羣集中的隊列管理器之間可以自動進行負載均衡，當某一隊列管理器出現故障時，其它隊列管理器能夠接管它的工做，從而大大提升系統的高可靠性。

Kafka的基本術語和概念

1. Kafka中有如下一些概念。
2. Broker：任何正在運行中的Kafka示例都稱爲Broker。
3. Topic：Topic其實就是一個傳統意義上的消息隊列。
4. Partition：即分區。一個Topic將由多個分區組成，每一個分區將存在獨立的持久化文件，任何一個Consumer在分區上的消費必定是順序的；當一個Consumer同時在多個分區上消費時，Kafka不能保證整體上的強順序性（對於強順序性的一個實現是Exclusive Consumer，即獨佔消費，一個隊列同時只能被一個Consumer消費，而且從該消費開始消費某個消息到其確認纔算消費完成，在此期間任何Consumer不能再消費）。
5. Producer：消息的生產者。
6. Consumer：消息的消費者。
7. Consumer Group：即消費組。一個消費組是由一個或者多個Consumer組成的，對於同一個Topic，不一樣的消費組都將能消費到全量的消息，而同一個消費組中的Consumer將競爭每一個消息（在多個Consumer消費同一個Topic時，Topic的任何一個分區將同時只能被一個Consumer消費）。

Kafka的特性

1. 高吞吐量、低延遲：kafka每秒能夠處理幾十萬條消息，它的延遲最低只有幾毫秒，每一個topic能夠分多個partition, consumer group 對partition進行consume操做；
2. 可擴展性：kafka集羣支持熱擴展；
3. 持久性、可靠性：消息被持久化到本地磁盤，而且支持數據備份防止數據丟失；
4. 容錯性：容許集羣中節點失敗（若副本數量爲n,則容許n-1個節點失敗）；
5. 高併發：支持數千個客戶端同時讀寫；
6. 支持實時在線處理和離線處理：可使用Storm這種實時流處理系統對消息進行實時進行處理，同時還可使用Hadoop這種批處理系統進行離線處理；

Kafka的Leader的選舉機制

• Kafka的Leader是什麼

1. 首先Kafka會將接收到的消息分區（partition），每一個主題（topic）的消息有不一樣的分區。這樣一方面消息的存儲就不會受到單一服務器存儲空間大小的限制，另外一方面消息的處理也能夠在多個服務器上並行。
2. 其次爲了保證高可用，每一個分區都會有必定數量的副本（replica）。這樣若是有部分服務器不可用，副本所在的服務器就會接替上來，保證應用的持續性。

• 可是，爲了保證較高的處理效率，消息的讀寫都是在固定的一個副本上完成。這個副本就是所謂的Leader，而其餘副本則是Follower。而Follower則會按期地到Leader上同步數據。
• Leader選舉

1. 若是某個分區所在的服務器除了問題，不可用，kafka會從該分區的其餘的副本中選擇一個做爲新的Leader。以後全部的讀寫就會轉移到這個新的Leader上。如今的問題是應當選擇哪一個做爲新的Leader。顯然，只有那些跟Leader保持同步的Follower才應該被選做新的Leader。
2. Kafka會在Zookeeper上針對每一個Topic維護一個稱爲ISR（in-sync replica，已同步的副本）的集合，該集合中是一些分區的副本。只有當這些副本都跟Leader中的副本同步了以後，kafka纔會認爲消息已提交，並反饋給消息的生產者。若是這個集合有增減，kafka會更新zookeeper上的記錄。
3. 若是某個分區的Leader不可用，Kafka就會從ISR集合中選擇一個副本做爲新的Leader。
4. 顯然經過ISR，kafka須要的冗餘度較低，能夠容忍的失敗數比較高。假設某個topic有f+1個副本，kafka能夠容忍f個服務器不可用。

• 爲何不用少數服從多數的方法

1. 少數服從多數是一種比較常見的一致性算法和Leader選舉法。它的含義是隻有超過半數的副本同步了，系統纔會認爲數據已同步；選擇Leader時也是從超過半數的同步的副本中選擇。這種算法須要較高的冗餘度。譬如只容許一臺機器失敗，須要有三個副本；而若是隻容忍兩臺機器失敗，則須要五個副本。而kafka的ISR集合方法，分別只須要兩個和三個副本。

• 若是全部的ISR副本都失敗了怎麼辦

1. 此時有兩種方法可選，一種是等待ISR集合中的副本復活，一種是選擇任何一個當即可用的副本，而這個副本不必定是在ISR集合中。這兩種方法各有利弊，實際生產中按需選擇。
2. 若是要等待ISR副本復活，雖然能夠保證一致性，但可能須要很長時間。而若是選擇當即可用的副本，則極可能該副本並不一致。

kafka集羣partition分佈原理分析

1. 在Kafka集羣中，每一個Broker都有均等分配Partition的Leader機會。
2. 上述圖Broker Partition中，箭頭指向爲副本，以Partition-0爲例:broker1中parition-0爲Leader，Broker2中Partition-0爲副本。
3. 上述圖種每一個Broker(按照BrokerId有序)依次分配主Partition,下一個Broker爲副本，如此循環迭代分配，多副本都遵循此規則。
4. 副本分配算法以下：
5. 將全部N Broker和待分配的i個Partition排序.
6. 將第i個Partition分配到第(i mod n)個Broker上.
7. 將第i個Partition的第j個副本分配到第((i + j) mod n)個Broker上.

Zookeeper在kafka的做用

1. 不管是kafka集羣，仍是producer和consumer都依賴於zookeeper來保證系統可用性集羣保存一些meta信息。
2. Kafka使用zookeeper做爲其分佈式協調框架，很好的將消息生產、消息存儲、消息消費的過程結合在一塊兒。
3. 同時藉助zookeeper，kafka可以生產者、消費者和broker在內的因此組件在無狀態的狀況下，創建起生產者和消費者的訂閱關係，並實現生產者與消費者的負載均衡。