0.11.x擁有的特性:
傳統消息隊列及副本容災功能
支持exactly once 恰好一次語義
事務支持.
kafka stream支持.
consumer 消息拉取線程和心跳線程分開
截止到0.11.x,kafka作為傳統的發布訂閱功能基本完善,建議至少升級到該版本.
1.0.x
新增磁盤故障轉移
新增跨副本路徑遷移
2.x
2.1.x支持ZStandard的壓縮,提高吞吐性能
優化生產者和消費者
當前最新穩定版本如下:
2.7.0,2.6.1,2.6.0
Kafka中的每個partition都由一系列有序的、不可變的消息組成，這些消息被連續的追加到partition中。partition中的每個消息都有一個連續的序號，用於partition唯一標識一條消息。
Offset記錄着下一條將要發送給Consumer的消息的序號。
Offset從語義上來看擁有兩種：Current Offset和Committed Offset。
Current Offset
Current Offset保存在Consumer客戶端中，它表示Consumer希望收到的下一條消息的序號。它僅僅在poll()方法中使用。例如，Consumer第一次調用poll()方法后收到了20條消息，那么Current Offset就被設置為20。這樣Consumer下一次調用poll()方法時，Kafka就知道應該從序號為21的消息開始讀取。這樣就能夠保證每次Consumer poll消息時，都能夠收到不重復的消息。
Committed Offset
Committed Offset保存在Broker上，它表示Consumer已經確認消費過的消息的序號。主要通過commitSync和commitAsync
API來操作。舉個例子，Consumer通過poll() 方法收到20條消息后，此時Current Offset就是20，經過一系列的邏輯處理后，並沒有調用consumer.commitAsync()或consumer.commitSync()來提交Committed Offset，那么此時Committed Offset依舊是0。
Committed Offset主要用於Consumer Rebalance。在Consumer Rebalance的過程中，一個partition被分配給了一個Consumer，那么這個Consumer該從什么位置開始消費消息呢？答案就是Committed Offset。另外，如果一個Consumer消費了5條消息（poll並且成功commitSync）之后宕機了，重新啟動之后它仍然能夠從第6條消息開始消費，因為Committed Offset已經被Kafka記錄為5。
在Kafka 0.9前，Committed Offset信息保存在zookeeper的[consumers/{group}/offsets/{topic}/{partition}]目錄中（zookeeper其實並不適合進行大批量的讀寫操作，尤其是寫操作）。而在0.9之后，所有的offset信息都保存在了Broker上的一個名為__consumer_offsets的topic中。
計算Lag值
在計算Lag之前先普及幾個基本常識
LEO(LogEndOffset): 這里說的和官網說的LEO有點區別，主要是指對consumer可見的offset.即HW(High Watermark)
CURRENT-OFFSET: consumer消費到的具體位移
知道以上信息后，可知Lag=LEO-CURRENT-OFFSET。計算出來的值即為消費延遲情況。
Kafka 2.8.0 出爐了，此版本有一項重大改進：
實現了 Raft 分布式一致性機制，意味着可以脫離 ZooKeeper 獨立運行了。
ZooKeeper 在 Kafka 中扮演着重要的角色，用來存儲 Kafka 的元數據。
ZooKeeper 存儲着 Partition 和 Broker 的元數據 ，同時也負責 Kafka Controller 的選舉工作。
對於 Kafka 來講，ZooKeeper 是一套外部系統，要想部署一套 Kafka 集群，就要同時部署、管理、監控 ZooKeeper。
ZooKeeper 有自己的配置方式、管理工具，和 Kafka 完全不一樣，所以，一起搞兩套分布式系統，自然就提升了復雜度，也更容易出現問題。有時工作量還會加倍，例如要開啟一些安全特性，Kafka 和 ZooKeeper 中都需要配置。
除了復雜度，外部存儲也會降低系統效率。
例如 Kafka 集群每次啟動的時候，Controller 必須從 ZooKeeper 加載集群的狀態信息。
再比如選舉出一個新的 Controller 之后也會比較麻煩，因為需要加載元數據，而此時元數據的量可能已經非常大了，這就產生了效率問題。
所以，ZooKeeper 帶來的復雜度、系統效率這兩個問題已經成為 Kafka 的痛點，Kafka 團隊一直在努力去除對 ZooKeeper 的依賴。Kafka 2.8.0 這個版本終於實現了。
使用 Raft 模式之后，元數據、配置信息都會保存在 @metadata 這個 Topic 中，自動在集群中復制。這樣 Kafka 就會簡單輕巧很多。
但需要注意的是，Zookeeper-less Kafka 還屬於早期版本，並不完善，所以，現在不要應用在線上產品環境中。