我的 Kafka 旅程 – broker
broker在kafka的服務端運行，一台伺服器相當於一個broker；每個broker下可以有多個topic，每個topic可以有多個partition，在producer端可以對消息進行分區，每個partiton可以有多個副本，可以使得數據不丟失。
通常以集群模式，下面來闡述一下broker的幾個狀況。
分區數據與副本
kafka的partition有一個leader的數據區域，是為了接收producer端發送的數據；也可以通過克隆leader的方式創建副本，leader與副本保持數據同步，也就是為了在極端情況下的數據備份，每個分區的副本交錯的存在於其它分區中，盡量以平均方式存放於各分區中，也可以手動指定存放的分區（假設是因伺服器硬體的配置不同），當極端情況下，leader宕機後，自動啟用副本作為新leader角色，負責接收消息。
leader與副本保持通訊，副本持續向leader發送健康請求，超過30秒無連接的副本，從關聯的副本中刪除關係；副本數據默認為1個，通常我們至少設置為2個。
# 副本數量配置項（默認為1）
mis.insync.replicas
broker的應答機制
在上一章闡述過，broker是對producer的應答，它會告訴producer，對接收到的數據處理情況；
應答等級：(配置項為 acks)
- 0：不用等落地磁碟，直接應答
- 1：leader落地磁碟後應答
- all：leader和副本都落地磁碟後再應答（默認）
精準數據
數據的不重複
- broker單次啟動運行，會有一個唯一的運行編號
- 每個分區都會有一個唯一的分區編號
- producer發送的每條消息都會有一個唯一的消息編號
像以上這種，對每個環節都會有唯一編號，kafka很方便的區分出每條消息的歸屬，為冪等性。
# 冪等性（默認開啟）
enable.idempotence=true
數據防丟失
通過以上內容的了解，為防止數據的丟失，這裡可以這樣做：
1、應答機制設為-1，確保leader和副本都保存完成
2、分區副本至少有兩個，確保隨時有可啟用的副本數據
當做到 數據不重複 + 數據防丟失，體現出數據的完整性、安全性、一致性。
數據的按序
broker中的leader在接收數據時，分區快取按序最多可存5個請求數據，成功的消息請求會落地，消息請求按序落地磁碟，若一次消息請求失敗，producer會嘗試重發，此時leader分區的數據落地動作會暫停，但會快取新收到的請求數據，積滿5個後暫停接收，直至之前失敗的消息請求成功後，再從此消息處，重新開始按序落地磁碟。多分區按發送序號落地磁碟。
leader分區快取接收消息示意圖：
這裡認為：開啟冪等性 + 接收積壓個數 + 按序落地磁碟，可以確保單個topic多分區消息不亂序。
leader partition 的自動平衡
假如，個別broker中的分區過多，個別broker中的分區過少，這不符合負載均衡。
kafka默認開啟了每間隔一段時間，自動檢測分區分布的差異值是否超過了警戒值，當超過設定的警戒值時，自動觸發平均分布的動作。
# 開啟自動平衡分布（默認）
auto.leader.rebalance.enable=true
# 不平衡警戒觸發值（默認1%）
leader.imbalance.per.broker.percentage
# 檢測間隔時間（默認300秒）
leader.imbalance.check.interval.seconds=300
通常不建議開啟，或者把警戒觸發值調大，或者把間隔時間設長，為減少被觸發的次數；頻繁性的觸發平均分配，造成不必要的資源消耗。
管理節點(broker)
通常是向集群中添加新節點；每個broker啟動後，會先向ZK註冊，每個broker有個選舉leader的controller，按註冊的順序為leader角色的替代者，leader的contraller負責監聽ZK的broker.Ids並管理。以下闡述對節點(broker)的管理操作。
註冊新節點
首先確保各IP及主機名的對應，便於後續節點相關的配置。
再次確保一個全新的節點，broker.id的設置、zookeeper.connect的配置、數據及日誌目錄為空。
啟動該節點（自動註冊並加入集群中）
手動設定節點分區
# 指定成員節點，重新分配分區，自動將數據同步到其它節點
bin/kafka-reassign-partitions.sh --broker-list '0,1,2'
減少/刪除節點，同上，改變 –broker-list 的成員節點，數據將自動同步到其它節點
宕機後的數據同步
leader(broker)宕機恢復後，以當前leader數據為準，這裡為了數據的一致性。
副本(broker)宕機恢復後，向leader請求同步數據。
