分類導(dǎo)航

Kafka Offset Storage

發(fā)布時(shí)間：2017年01月10日作者：文章轉(zhuǎn)自網(wǎng)絡(luò)，版權(quán)歸原作者所有，反饋可立刻刪除 (該文來自筆記，點(diǎn)擊查看原文)

1.概述

　　目前，Kafka 官網(wǎng)最新版[0.10.1.1]，已默認(rèn)將消費(fèi)的 offset 遷入到了 Kafka 一個(gè)名為 __consumer_offsets 的Topic中。其實(shí)，早在 0.8.2.2 版本，已支持存入消費(fèi)的 offset 到Topic中，只是那時(shí)候默認(rèn)是將消費(fèi)的 offset 存放在 Zookeeper 集群中。那現(xiàn)在，官方默認(rèn)將消費(fèi)的offset存儲(chǔ)在 Kafka 的Topic中，同時(shí)，也保留了存儲(chǔ)在 Zookeeper 的接口，通過 offsets.storage 屬性來進(jìn)行設(shè)置。

2.內(nèi)容

　　其實(shí)，官方這樣推薦，也是有其道理的。之前版本，Kafka其實(shí)存在一個(gè)比較大的隱患，就是利用 Zookeeper 來存儲(chǔ)記錄每個(gè)消費(fèi)者/組的消費(fèi)進(jìn)度。雖然，在使用過程當(dāng)中，JVM幫助我們完成了自一些優(yōu)化，但是消費(fèi)者需要頻繁的去與 Zookeeper 進(jìn)行交互，而利用ZKClient的API操作Zookeeper頻繁的Write其本身就是一個(gè)比較低效的Action，對(duì)于后期水平擴(kuò)展也是一個(gè)比較頭疼的問題。如果期間 Zookeeper 集群發(fā)生變化，那 Kafka 集群的吞吐量也跟著受影響。

　　在此之后，官方其實(shí)很早就提出了遷移到 Kafka 的概念，只是，之前是一直默認(rèn)存儲(chǔ)在 Zookeeper集群中，需要手動(dòng)的設(shè)置，如果，對(duì) Kafka 的使用不是很熟悉的話，一般我們就接受了默認(rèn)的存儲(chǔ)（即：存在 ZK 中）。在新版 Kafka 以及之后的版本，Kafka 消費(fèi)的offset都會(huì)默認(rèn)存放在 Kafka 集群中的一個(gè)叫 __consumer_offsets 的topic中。

　　當(dāng)然，其實(shí)她實(shí)現(xiàn)的原理也讓我們很熟悉，利用 Kafka 自身的 Topic，以消費(fèi)的Group，Topic，以及Partition做為組合 Key。所有的消費(fèi)offset都提交寫入到上述的Topic中。因?yàn)檫@部分消息是非常重要，以至于是不能容忍丟數(shù)據(jù)的，所以消息的 acking 級(jí)別設(shè)置為了 -1，生產(chǎn)者等到所有的 ISR 都收到消息后才會(huì)得到 ack（數(shù)據(jù)安全性極好，當(dāng)然，其速度會(huì)有所影響）。所以 Kafka 又在內(nèi)存中維護(hù)了一個(gè)關(guān)于 Group，Topic 和 Partition 的三元組來維護(hù)最新的 offset 信息，消費(fèi)者獲取最新的offset的時(shí)候會(huì)直接從內(nèi)存中獲取。

3.實(shí)現(xiàn)

我想了解如何學(xué)習(xí)