1.概述
目前，Kafka 官網(wǎng)最新版[0.10.1.1]，已默認將消費的 offset 遷入到了 Kafka 一個名為 __consumer_offsets 的Topic中。其實，早在 0.8.2.2 版本，已支持存入消費的 offset 到Topic中，只是那時候默認是將消費的 offset 存放在 Zookeeper 集群中。那現(xiàn)在，官方默認將消費的offset存儲在 Kafka 的Topic中，同時，也保留了存儲在 Zookeeper 的接口，通過 offsets.storage 屬性來進行設(shè)置。
2.內(nèi)容
其實，官方這樣推薦，也是有其道理的。之前版本，Kafka其實存在一個比較大的隱患，就是利用 Zookeeper 來存儲記錄每個消費者/組的消費進度。雖然，在使用過程當(dāng)中，JVM幫助我們完成了自一些優(yōu)化，但是消費者需要頻繁的去與 Zookeeper 進行交互，而利用ZKClient的API操作Zookeeper頻繁的Write其本身就是一個比較低效的Action，對于后期水平擴展也是一個比較頭疼的問題。如果期間 Zookeeper 集群發(fā)生變化，那 Kafka 集群的吞吐量也跟著受影響。
在此之后，官方其實很早就提出了遷移到 Kafka 的概念，只是，之前是一直默認存儲在 Zookeeper集群中，需要手動的設(shè)置，如果，對 Kafka 的使用不是很熟悉的話，一般我們就接受了默認的存儲（即：存在 ZK 中）。在新版 Kafka 以及之后的版本，Kafka 消費的offset都會默認存放在 Kafka 集群中的一個叫 __consumer_offsets 的topic中。
當(dāng)然，其實她實現(xiàn)的原理也讓我們很熟悉，利用 Kafka 自身的 Topic，以消費的Group，Topic，以及Partition做為組合 Key。所有的消費offset都提交寫入到上述的Topic中。因為這部分消息是非常重要，以至于是不能容忍丟數(shù)據(jù)的，所以消息的 acking 級別設(shè)置為了 -1，生產(chǎn)者等到所有的 ISR 都收到消息后才會得到 ack（數(shù)據(jù)安全性極好，當(dāng)然，其速度會有所影響）。所以 Kafka 又在內(nèi)存中維護了一個關(guān)于 Group，Topic 和 Partition 的三元組來維護最新的 offset 信息，消費者獲取最新的offset的時候會直接從內(nèi)存中獲取。
3.實現(xiàn)
延伸閱讀
- ssh框架 2016-09-30
- 阿里移動安全 [無線安全]玩轉(zhuǎn)無線電——不安全的藍牙鎖 2017-07-26
- 消息隊列NetMQ 原理分析4-Socket、Session、Option和Pipe 2024-03-26
- Selective Search for Object Recognition 論文筆記【圖片目標分割】 2017-07-26
- 詞向量-LRWE模型-更好地識別反義詞同義詞 2017-07-26
- 從棧不平衡問題 理解 calling convention 2017-07-26
- php imagemagick 處理 圖片剪切、壓縮、合并、插入文本、背景色透明 2017-07-26
- Swift實現(xiàn)JSON轉(zhuǎn)Model - HandyJSON使用講解 2017-07-26
- 阿里移動安全 Android端惡意鎖屏勒索應(yīng)用分析 2017-07-26
- 集合結(jié)合數(shù)據(jù)結(jié)構(gòu)來看看(二) 2017-07-26
學(xué)習(xí)是年輕人改變自己的最好方式