Kafka原理——fabric1.0版本中的節點排序方法
Kafka原理
可參考Zookeeper一起理解，後續自己在專案中實現，會再來補充一些實踐的內容。
Zookeeper整理:https://blog.csdn.net/yangwei256/article/details/83786917
目錄
2.1 主題Topic、分割槽partion和偏移量offset 4
2.3 分割槽（partion）和broker叢集... 6
概述
Kafka和Zookeeper是經常一起使用的，不可分割的一對好基友好朋友。詳細瞭解Zookeeper請參考：https://blog.csdn.net/yangwei256/article/details/83786917
Kafka使用Zookeeper進行以下操作（Zookeeper在kafka中的作用）：
1、選擇控制器。控制器是一個Broker，負責維護所有分割槽的領導者（leader）/跟隨者(follower)關係。當節點關閉時，控制器會告訴其他副本成為分割槽領導者，以替換正在消失的節點上的分割槽領導者。Zookeeper用於選擇控制器，確保只有一個控制器，如果它崩潰，則選擇一個新控制器。
2、管理叢集成員資格 - 哪些Broker還活著並且是叢集的一部分？這也是通過ZooKeeper管理的。
3、主題配置 - 存在哪些主題，每個主題有多少個分割槽，副本在哪裡，誰是首選領導者，為每個主題設定了哪些配置。
4、配額管理 - 允許每個客戶端讀取和寫入多少資料
5、ACLs(訪問控制列表) - 允許讀取和寫入哪個主題。
6、管理老的多級別消費者（old level consummer） - 存在哪些消費者群體，誰是他們的成員以及每個群組從每個分割槽獲得的最新偏移量。ZooKeeper是一種服務，它允許客戶端訪問客戶端到類似樹的結構，
（1）樹中的每個節點稱為zNode
（2）樹中的每個zNode都有路徑
（3）標識.zNode型別 - 持久和短暫
（4）每個zNode將儲存一個值或資料，可能是子節點
（5）無法重新命名 zNodes
（6）我們可以新增/刪除WATCH到zNode。
Zookeeper在Kakfa中扮演的角色細節：
1、Kafka將元資料資訊儲存在Zookeeper中，但是傳送給Topic本身的資料是不會發到Zk上的。
2、kafka使用zookeeper來實現動態的叢集擴充套件，不需要更改客戶端（producer和consumer）的配置。
3、broker會在zookeeper註冊並保持相關的元資料（topic，partition資訊等）更新。而客戶端會在zookeeper上註冊相關的watcher。
一旦zookeeper發生變化，客戶端能及時感知並做出相應調整。這樣就保證了新增或去除broker時，各broker間仍能自動實現負載均衡。
這裡的客戶端指的是Kafka的訊息生產端(Producer)和訊息消費端(Consumer)端使用zookeeper用來"發現"broker列表,以及和Topic下每個partition的leader建立socket連線併發送訊息。
也就是說每個Topic的partition是由Leader角色的Broker端使用zookeeper來註冊broker資訊,以及監測partition leader存活性。Consumer端使用zookeeper用來註冊consumer資訊,其中包括consumer消費的partition列表等,同時也用來發現broker列表,並和partition leader建立socket連線,並獲取訊息.
1 Kafka的基本原理
1.1 什麼是kafka
Kafka是一個分散式的，基於釋出/訂閱（pub-sub）的訊息傳遞系統，具有快速，高度可擴充套件、高可靠的特性。
1.2 kafka有什麼優點？
Kafka的分散式設計賦予它幾個優點。
- Kafka允許大量永久或臨時消費者。
- Kafka具有高效能、高可用性和對節點故障的彈性，並支援自動恢復。在現實世界的資料系統中，這些特性使Kafka成為大規模資料系統元件之間通訊和整合的理想選擇。
1.3 kafka架構由什麼組成？
（1）Broker
Kafka叢集包含一個或多個伺服器，這種伺服器被稱為broker
（2）Producer（生產者）
訊息生成者，負責釋出訊息到Kafka broker
（3）Consumer（消費者）
訊息消費者，向Kafka broker讀取訊息的客戶端。
（4）Topic（主題）
每條釋出到Kafka叢集的訊息都有一個類別，這個類別被稱為Topic。（物理上不同Topic的訊息分開儲存，邏輯上一個Topic的訊息雖然保存於一個或多個broker上，但使用者只需指定訊息的Topic即可生產或消費資料而不必關心資料存於何處）。
（5）Partition（分割槽）
Parition是物理上的概念，每個Topic包含一個或多個Partition.
（6）Consumer Group
每個Consumer屬於一個特定的Consumer Group（可為每個Consumer指定group name，若不指定group name則屬於預設的group）。
kafka基本組成架構如圖1所示，其中 Broker，Topic、Partion都屬於kafka cluster內部的東東。
圖1 kafka基本組成架構
Kafka叢集的拓撲結構如圖2所示，實際就是把圖1擴充套件開來，包含若干Producer（可以是web前端產生的Page View，或者是伺服器日誌，系統CPU、Memory等），若干broker（Kafka支援水平擴充套件，一般broker數量越多，叢集吞吐率越高），若干Consumer Group，以及一個Zookeeper叢集。（關於Zookeeper可以參考另一篇介紹） Kafka通過Zookeeper管理叢集配置，選舉leader，以及在Consumer Group發生變化時進行rebalance。Producer使用push模式將訊息釋出到broker，Consumer使用pull模式從broker訂閱並消費訊息。
圖2 kafka叢集拓撲結構
2 kafka的成員解析、原理和工作流程
2.1 主題Topic、分割槽partion和偏移量offset
一個主題包含多個分割槽，每個分割槽可以放在單獨的機器上，允許多個使用者並行地從主題中讀取。消費者也可以並行化，以便多個消費者可以從主題中的多個分割槽讀取，從而允許非常高的訊息處理吞吐量。
如何設定partition值？一個partition只能被一個消費者消費（一個消費者可以同時消費多個partition），因此，如果設定的partition的數量小於consumer的數量，就會有消費者消費不到資料。所以，推薦partition的數量一定要大於同時執行的consumer的數量。另外一方面，建議partition的數量大於叢集broker的數量，這樣leader partition就可以均勻的分佈在各個broker中，最終使得叢集負載均衡需要注意的是，kafka需要為每個partition分配一些記憶體來快取訊息資料，如果partition數量越大，就要為kafka分配更大的heap space。
分割槽中的每條訊息都有一個稱為其偏移量（offset）的識別符號。消費者可以從特定偏移量開始讀取訊息，並允許從他們選擇的任何偏移點讀取訊息，允許消費者在他們認為合適的任何時間點加入群集。鑑於這些約束，Kafka叢集中的每個特定訊息都包含主題（topic），分割槽(partion)和分割槽內的偏移量(offset)。結構如圖2-1所示。
2-1 一個主題的組成圖
2.2 分割槽寫入和讀取訊息
每個分割槽都是一個有序的，不可變的記錄序列，不斷附加到結構化的提交日誌中。分割槽中的記錄每個都分配了一個稱為偏移（offset）的順序ID號，它唯一地標識分割槽中的每個記錄。
資料保留多久？Kafka叢集持久使用可配置的保留期儲存所有已釋出的記錄 ，無論是否已使用 。例如，如果保留策略設定為兩天，則在釋出記錄後的兩天內，它可供使用，之後將被丟棄以釋放空間。Kafka的效能在資料大小方面實際上是恆定的，因此長時間儲存資料不是問題。
實際上，基於每個消費者保留的唯一元資料是該消費者在日誌中的偏移或位置。這種偏移由消費者控制：通常消費者在讀取記錄時會線性地提高其偏移量（讀完一條繼續讀下一條），但事實上，由於該位置由消費者控制（消費者可以改變offset，從而指向不同的訊息），因此它可以按照自己喜歡的任何順序消費記錄。例如，消費者可以重置為較舊的偏移量來重新處理過去的資料，或者跳到最近的記錄並從“現在”開始消費。
日誌中的分割槽有多種用途。首先，它們允許日誌擴充套件到超出適合單個伺服器的大小。每個單獨的分割槽必須適合託管它的伺服器，但主題可能有許多分割槽，因此它可以處理任意數量的資料。其次，它們充當了並行的單元。在圖4中，生產者正在寫入日誌，而消費者A和B正在以不同的偏移量從日誌中讀取資料。
圖4 寫入和讀取訊息
2.3 分割槽（partion）和broker叢集
每個broker都擁有許多分割槽，每個分割槽可以是主題的領導者（leader）或副本(replica)。訊息的寫入和讀取都需要通過領導者，且領導者負責與副本協調更新資料。如果領導者失敗，副本將作為新領導者接管。
圖5 分割槽領導者和副本
2.4 生產者(producer)
生產者將訊息寫入到領導者，同一時刻只能有一個領導者，以便每個寫入可以由單獨的代理和機器提供服務。在下影象中，生產者負責將訊息寫入到主題的分割槽0，而分割槽0複製到其他可用副本。
圖6、生產者寫入分割槽
在圖6中，生產者正在寫入主題的分割槽0，分割槽0複製訊息寫入到其他broker的可用副本分割槽。
圖7、生產者寫入第二個分割槽。
在圖7中，生產者正在寫入主題的分割槽1，分割槽1複製訊息寫入到其他broker的可用副本分割槽。
由於每次是由不同的伺服器即broker寫入，因此整個系統的吞吐量增加。
2.5 消費者和消費者群體
（1）單主題單消費者群的情況
消費者從任何單個分割槽讀取，允許您以與訊息生成類似的方式擴充套件訊息吞吐量。消費者也可以被組織成針對給定主題的消費者群組 - 群組中的每個消費者從唯一分割槽讀取，並且整個群組消耗來自整個主題的所有訊息。如果您擁有的消費者多於分割槽，那麼一些消費者將處於空閒狀態，因為他們沒有可讀取的分割槽。如果您有比消費者更多的分割槽，那麼消費者將從多個分割槽接收訊息。如果您擁有相同數量的使用者和分割槽，則每個使用者從一個分割槽中按順序讀取訊息。下邊引用的一組圖可以形象的說明情況。
圖8系列 消費者群組讀取分割槽訊息類別
（2）單個主題的多分割槽多消費者群
單個主題的多分割槽多消費者群的kafka叢集如圖9所示。伺服器1儲存分割槽0和3，伺服器2儲存分割槽1和2。我們有兩個消費者組，A和B。A由兩個消費者組成，B由四個消費者組成。消費者組A有兩個兩個分割槽的消費者 ，每個消費者從兩個分割槽讀取。另一方面，消費者組B與分割槽具有相同數量的消費者，並且每個消費者從一個分割槽中讀取。
圖9 多群組的kafka叢集
2.6 一致性和可用性
在開始討論一致性和可用性之前，請記住，只要您生成一個分割槽並從一個分割槽讀取訊息，就能保證一致性和可用性。如果您使用兩個消費者從同一分割槽讀取或使用兩個生產者寫入同一分割槽，則一致性和可用性都不能保證。
Kafka通過以下幾點確保資料一致性和可用性：
（1）傳送到主題分割槽的訊息將按傳送順序附加到提交日誌中。
（2）單個消費者例項將按照它們出現的順序檢視訊息日誌，
（3）當所有同步副本已將其應用於其日誌時，訊息被“提交”，
（4）任何已提交的訊息都不會丟失，只要至少有一個同步副本處於活動狀態。
第一和第二保證確保為每個分割槽保留訊息排序。請注意，無法保證整個主題的訊息排序。第三和第四個保證確保可以檢索已提交的訊息。在Kafka中，選舉領導者的分割槽負責將收到的任何訊息同步到副本。一旦副本確認了該訊息，該副本就被認為是同步的。為了進一步理解這一點，讓我們仔細看看寫入過程中會發生什麼。
2.7 處理訊息寫入
與Kafka群集通訊時，所有訊息都將傳送到分割槽的負責人。領導者負責將訊息寫入自己的同步副本中，並且一旦提交了該訊息，負責將訊息傳播到不同代理上的其他副本。每個副本都確認已收到訊息，現在可以同步呼叫。
圖10 領導者寫入副本
當叢集中的每個broker都可用時，消費者和生產者可以愉快地從主題的主要分割槽讀取和寫入而不會出現問題。不幸的是，無論是領導者還是副本都可能出現問題（如宕機），我們需要處理這些情況。
2.8 處理出問題情況
副本出錯時會發生什麼？寫入將不再到達有問題的副本，它將不再接收訊息，進而與領導者不同步。在下圖11中，副本3不再接收來自領導者的訊息。
圖11 一個副本掛掉
當第二個副本掛掉時會發生什麼？第二個副本也將不再接收訊息，它也會與領導者不同步。
圖12 二個副本掛掉
此時，只有領導者同步。在Kafka術語中，我們仍然有一個同步副本，即使該副本恰好是此分割槽的領導者。
如果領導者死了怎麼辦？我們留下了三個死亡的複製品。
圖13 三副本都掛掉
副本1實際上仍處於同步狀態 - 它無法接收任何新資料，但它與可能接收的所有內容同步。副本二缺少一些資料，副本三（第一個下降）缺少更多資料。鑑於這種狀態，有兩種可能的解決方案。第一個也是最簡單的方案是等到領導者重新開始後再繼續。一旦領導者回來，它將開始接收和寫入訊息，並且當副本重新聯機時，它們將與領導者同步。第二種情況是選出一個Broker作為新的領導者回來。這個Broker將與現有的領導者不同步，並且在該經紀人倒閉和被選舉之間所寫的所有資料都將丟失。隨著其他Broker的迴歸，他們會看到他們已經提交了新領導者不存在的訊息並刪除了這些訊息。通過儘快選舉新的領導者可能會丟棄訊息但我們將最小化停機時間，因為任何新機器都可以成為領導者。
退一步，我們可以檢視領導者在同步副本仍然存在的情況下發生故障的情況。
圖14 領導者掛掉
在這種情況下，Kafka控制器將檢測領導者掛掉並從同步副本池中選出新的領導者。這可能需要幾秒鐘，並導致客戶端出錯Leader Not Available。但是，只要生產者和消費者處理這種可能性並適當地重試，就不會發生資料丟失。
2.9 作為Kafka客戶端的一致性
Kafka的客戶端有兩種：生產者和消費者。這些中的每一個都可以配置為不同的一致性級別。
對於生產者，我們有三種選擇。在每條訊息上，我們可以（1）等待所有同步副本以確認訊息，（2）僅等待領導者確認訊息，或（3）不等待確認。這些方法中的每一種都有它們的優點和缺點，系統實現者可以根據一致性和吞吐量等因素來決定系統的適當策略。
在消費者方面，我們只能讀取已提交的訊息（即，已經寫入所有同步副本的訊息）。鑑於此，我們有三種方法作為消費者提供一致性：（1）最多接收一次訊息，（2）至少接收一次訊息，或（3）接收每個訊息一次。這些方案中的每一個都值得討論它自己的方案。
對於最多一次訊息傳遞，消費者從分割槽讀取資料，提交它已讀取的偏移量，然後處理訊息。如果消費者在提交偏移和處理訊息之間崩潰，它將從下一個偏移重新開始，而不處理訊息。這將導致潛在的不期望的訊息丟失。
更好的選擇是至少一次訊息傳遞。對於至少一次傳遞，消費者從分割槽讀取資料，處理訊息，然後提交它已處理的訊息的偏移量。在這種情況下，消費者可能在處理訊息和提交偏移之間崩潰，並且當消費者重新啟動它時將再次處理訊息。這會導致下游系統中出現重複訊息，但不會丟失資料。
通過讓消費者處理訊息並將訊息的輸出與偏移一起提交給事務系統，可以確保一定交付。如果消費者崩潰，它可以重新讀取最後提交的事務並從那裡恢復處理。這不會導致資料丟失，也不會導致資料重複。然而，在實踐中，這樣做意味著顯著降低系統的吞吐量，因為每個訊息和偏移都被提交為事務。
實際上，大多數Kafka消費者應用程式至少選擇一次交付，因為它提供了吞吐量和正確性之間的最佳平衡。下游系統將以自己的方式處理重複的訊息。
3 Kafka問題彙總
1、該共識機制的原理是什麼？
Kafka是一種分散式的、基於訊息釋出/訂閱的訊息處理模式。
2、該機制解決什麼問題？
解決分散式系統中，訊息的一致性和快速處理的問題。
3、該機制如何在區塊鏈系統中應用？
Fabric1.0系統中選用該機制提高系統的吞吐量，相比0.6版本的PBFT，該機制不會隨著節點的增加而降低系統吞吐量。（可以隨著節點增加增加Broker的數量，雖然成本有所增加，但總比效能太差好太多）
4、該共識機制分為哪些步驟？
- Push過程：Producer客戶端發起寫入請求，Broker根據訊息分類將訊息寫入到一個Topic中的一個Partion中。
- Pull過程：Consummer客戶端發起訪問請求，Broker根據訪問訊息的Topic、Partion和Offset找到對應的訪問訊息讀取。
5、該共識機制的特徵有哪些，需要滿足哪些前提條件？
特徵：支援多執行緒處理，提高系統吞吐量。
同時提供離線處理和實時處理，達到效能和需求的平衡。
6、該共識機制的優點和缺點有哪些,與其他共識機制對比呢（最好表現在表格上）？
Kafka的分散式設計賦予它幾個優點。
- Kafka允許大量永久或臨時消費者，節點允許隨時加入和退出，不影響系統。
- Kafka支援多執行緒處理，具有可水平擴充套件、非同步通訊、高效能、高可用性和對節點故障的彈性，並支援自動恢復。在現實世界的資料系統中，這些特性使Kafka成為大規模資料系統元件之間通訊和整合的理想選擇。
7、該共識機制的過程中可能出現哪些問題，如何處理？
- 在消費者獲取訊息時，需要讓消費者處理訊息並將訊息的輸出與偏移一起提交給事務系統，確保不會丟失未處理的訊息，但這樣需要再做一次事務提交，降低了系統性能。
- 只能對同一個Topic中同一個Partion的訊息進行排序，且具有唯一性，不支援跨Partion跨Topic的排序處理。
8、該共識機制可能存在哪些攻擊，該如何處理？
- 偽裝Consummer或者Producer進行訊息讀取和寫入。
引入安全認證，如CA等，保證節點身份可靠。
引入許可權控制（Authorization）：設計並實現Topic級別的許可權模型。Topic的許可權分為READ（從Topic拉取資料）、WRITE（向Topic中生產資料）、CREATE（建立Topic）和DELETE（刪除Topic）。
Producer（或Consumer）啟動後需要經過如下步驟與Broker建立安全的Socket連線，如下圖所示。
（1）Producer向KDC認證身份，通過則得到TGT（票證請求票證），否則報錯退出。
（2）Producer使用TGT向KDC請求Kafka服務，KDC驗證TGT並向Producer返回SessionKey（會話金鑰）和ServiceTicket（服務票證）。
（3）Producer使用SessionKey和ServiceTicket與Broker建立連線，Broker使用自身的金鑰解密ServiceTicket，獲得與Producer通訊的SessionKey，然後使用SessionKey驗證Producer的身份，通過則建立連線，否則拒絕連線。
引用：
1、官方文件http://kafka.apache.org/documentation/
- https://sookocheff.com/post/kafka/kafka-in-a-nutshell/
- https://zhuanlan.zhihu.com/p/37405836
- http://www.infoq.com/cn/articles/kafka-analysis-part-1
- https://blog.csdn.net/suifeng3051/article/details/48053965
- https://blog.csdn.net/u012501054/article/details/80241921
- https://ask.hellobi.com/blog/transwarp/6229
- https://www.jianshu.com/p/8a61bb2a9219（Zookeeper在kafka中的角色）
- https://www.quora.com/What-is-the-actual-role-of-Zookeeper-in-Kafka-What-benefits-will-I-miss-out-on-if-I-don%E2%80%99t-use-Zookeeper-and-Kafka-together（Zookeeper在kafka中的作用）