有幸公司已有搭建好的kafka伺服器，這裡和大家邊學邊看

springboot2

kafka基礎：摘錄的別人介紹

 Replication & Leader election（涉及到zookeeper核心問題，不是很明白）

 Kafka通過Zookeeper管理叢集配置，選舉leader，以及在consumer group發生變化時進行rebalance。producer使用push模式將訊息釋出到broker，consumer使用pull模式從broker訂閱並消費訊息。

重要1點，kafka傳送訊息通道不會被馬上清除，可以使用kafkaTool2直觀看到資料

• Broker
  Kafka叢集包含一個或多個伺服器，這種伺服器被稱為broker
• Topic
  每條釋出到Kafka叢集的訊息都有一個類別，這個類別被稱為topic。（物理上不同topic的訊息分開儲存，邏輯上一個topic的訊息雖然保存於一個或多個broker上但使用者只需指定訊息的topic即可生產或消費資料而不必關心資料存於何處）
• Partition
  parition是物理上的概念，每個topic包含一個或多個partition，建立topic時可指定parition數量。每個partition對應於一個資料夾，該資料夾下儲存該partition的資料和索引檔案
• Producer
  負責釋出訊息到Kafka broker
• Consumer
  消費訊息。每個consumer屬於一個特定的consuer group（可為每個consumer指定group name，若不指定group name則屬於預設的group）。使用consumer high level API時，同一topic的一條訊息只能被同一個consumer group內的一個consumer消費，但多個consumer group可同時消費這一訊息。
•  

Consumer group（訊息組）

這個我剛遇到的坑，所以比較瞭解：分組可確保同組的一個topic只能被一個同組組員所消費（分散式常用到）,一個topic可以被不同分組的的consumer分別消費

Consumer Rebalance

分散式中可能有多個kafka伺服器，實際上一個消費者只能消費一個伺服器的topic,要保證所有kafka裡相同的topic都能被消費,所以需要增加控制策略

• Herd effect
  　　任何broker或者consumer的增減都會觸發所有的consumer的rebalance
• Split Brain
  　　每個consumer分別單獨通過Zookeeper判斷哪些partition down了，那麼不同consumer從Zookeeper“看”到的view就可能不一樣，這就會造成錯誤的reblance嘗試。而且有可能所有的consumer都認為rebalance已經完成了，但實際上可能並非如此。

 訊息Deliver guarantee

  這訊息的幾種方式

• At most once 訊息可能會丟，但絕不會重複傳輸
• At least one 訊息絕不會丟，但可能會重複傳輸
• Exactly once 每條訊息肯定會被傳輸一次且僅傳輸一次，很多時候這是使用者所想要的。