基礎概念、架構和新版的升級-Kafka知識體系（一）
概念
- Kafka 是一種高吞吐量、分布式、基于發布/訂閱的消息系統，最初由 LinkedIn 公司開發，使用 Scala (JAVA)語言編寫，目前是Apache 的開源項目。
- 主要解決應用解耦、異步消息、流量削峰等問題。
- Kafka實際上也是一個主從架構，有一個Controller角色即控制器，協調管理整個集群。
關鍵術語
broker
Kafka 服務器，負責消息存儲和轉發。
topic
消息類別，Kafka 按照topic 來分類消息;似于關系型數據庫的表。
partition
topic 的分區，一個 topic 可以包含多個 partition ，topic 消息保存在各個 partition 上。
offset
消息在日志中的位置，可以理解是消息在partition 上的偏移量，也是代表該消息的唯一序號。
Producer
消息生產者，將消息push到Kafka集群中的Broker。
Consumer
消息消費者，從Kafka集群中pull消息，消費消息。
Consumer Group
消費者分組，每個Consumer 必須屬于一個group
Zookeeper
保存著集群broker、topic、partition 等meta 數據;另外，還負責broker 故 障發現，partition leader 選舉，負載均衡等功能。
從抽象到具體理解Kafka架構設計
從宏觀的層面來理解，它就是一個存儲系統。
細分一下，又有多個生產者，多個消費者，Broker 集群和Kafka 組成。
再次細分，broker有一個controller角色，每一個broker 可能存多個Topic的不同partion，每個partion 都有 leader 和follower 。這些信息都會注冊到zk上。
集群架構的理解及新版優化
控制器 controller
我們熟知一個規律：在大數據分布式文件系統里面，95%的都是主從式的架構，個別是對等式的架構，比如ElasticSearch。
kafka也是主從式的架構，主節點就叫controller，其余的為從節點，controller是需要和zookeeper進行配合管理整個kafka集群。
作用
協調與管理整個集群。
職責
- 主題增刪改
- 分區重分配
- leader選舉
- 元數據管理
- broker成員管理，宕機或加入
控制器選舉
基于zookeeper實現，利用了zookeeper的znode模型與監聽機制。
控制器故障轉移
存在單點故障，但是每個broker節點都可以成為controller;
故障轉移即failover也是基于zookeeper實現的，znode模型與監聽機制，/controller節點。
kafka和zookeeper如何配合工作
- kafka嚴重依賴于zookeeper集群。
- 所有的broker在啟動的時候都會往zookeeper進行注冊，目的就是選舉出一個controller
- 選舉過程非常簡單粗暴，就是一個誰先誰當的過程，不涉及什么算法問題。
- 成為controller之后，它會監聽zookeeper里面的多個目錄.
- 注冊時各個節點必定會暴露自己的主機名，端口號等等的信息，此時controller就要去讀取注冊上來的從節點的數據(通過監聽機制)，生成集群的元數據信息，之后把這些信息都分發給其他的服務器，讓其他服務器能感知到集群中其它成員的存在。
新版Kafka將要拋棄ZooKeeper!!!!!!
2021年3月30日，Kafka背后的企業Confluent發布博客表示，在即將發布的 2.8 版本里，用戶可在完全不需要 ZooKeeper 的情況下運行 Kafka，該版本將依賴于 ZooKeeper 的控制器改造成了基于 Kafka Raft 的 Quorm 控制器。
在之前的版本中，如果沒有 ZooKeeper，Kafka 將無法運行。但管理部署兩個不同的系統不僅讓運維復雜度翻倍，還讓 Kafka 變得沉重，進而限制了 Kafka 在輕量環境下的應用，同時 ZooKeeper 的分區特性也限制了 Kafka 的承載能力。
第一次，用戶可以在沒有 ZooKeeper 的情況下運行 Kafka。
這是一次架構上的重大升級，讓一向“重量級”的 Kafka 從此變得簡單了起來。輕量級的單進程部署可以作為 ActiveMQ 或 RabbitMQ 等的替代方案，同時也適合于邊緣場景和使用輕量級硬件的場景。
為什么要拋棄使用了十年的 ZooKeeper?
zk的缺點：
- zookeeper 的一個缺點就是 同步數據不能太大。
- zookeeper集群中leader和follower同步數據的極限值是500M，這500M的數據，加載到內存中，大約占用3個G的內存。
- 數據過大，在每次選舉之后，需要從server同步到follower，容易造成下面2個問題：
- 觸發重新選舉
- io 太久
ZooKeeper 充當 Kafka 的領導者，以更新集群中的拓撲更改;根據 ZooKeeper 提供的通知，生產者和消費者發現整個 Kafka 集群中是否存在任何新 Broker 或 Broker 失敗。大多數的運維操作，比如說擴容、分區遷移等等，都需要和 ZooKeeper 交互。
也就是說，Kafka 代碼庫中有很大一部分是負責實現在集群中多個 Broker 之間分配分區(即日志)、分配領導權、處理故障等分布式系統的功能。而早已經過業界廣泛使用和驗證過的 ZooKeeper 是分布式代碼工作的關鍵部分。
假設沒有 ZooKeeper 的話，Kafka 甚至無法啟動進程，但嚴重依賴 ZooKeeper，也給 Kafka 帶來了掣肘。
不過目前大部分用的還是和zk結合版本的kafka。
