kafka_offset

目录

offset保存位置的演化

zookeeper保存offset的劣势 

Kafka-topic保存优势

消费者消费情况

消息丢失：

多次消费：

一次消费：

---

offset保存位置的演化

zookeeper保存offset的劣势 

利用 Zookeeper 来存储记录每个消费者/组的消费进度，在使用过程当中，JVM帮助我们完成了一些优化，但是消费者需要频繁的去与 Zookeeper 进行交互，而利用ZKClient的API操作Zookeeper频繁的Write其本身就是一个比较低效的Action，对于后期水平扩展也是一个比较头疼的问题。如果期间 Zookeeper 集群发生变化，那 Kafka 集群的吞吐量也跟着受影响。

Kafka-topic保存优势

利用 Kafka 自身的 Topic，以消费的Group，Topic，以及Partition做为组合 Key。所有的消费offset都提交写入到上述的Topic中。因为这部分消息是非常重要，以至于是不能容忍丢数据的，所以消息的 acking 级别设置为了 -1，生产者等到所有的 ISR 都收到消息后才会得到 ack（数据安全性极好，当然，其速度会有所影响）。 

 Kafka 又在内存中维护了一个关于 Group，Topic 和 Partition 的三元组来维护最新的 offset 信息，消费者获取最新的offset的时候会直接从内存中获取。

消费者消费情况

在 consumer 端，大家都知道可以控制 offset，所以可以控制消费，其实 offset 只有在重启的时候才会用到。在机器正常运行时我们用的是 position，我们实时消费的位置也是 position 而不是 offset。我们可以得到每一条消息的 position。

消息丢失：

在处理消息之前就将当前消息的 position 保存到 zk 上即 offset，offset保存成功后，消费者服务宕掉，消息没有消费掉但是offset已经保存；

多次消费：

先消费消息然后保存 position 到 zk 上即 offset，因为我们可能在消费完消息后offset 没有保存成功。

一次消费：

(不是特别理解，其他人写的内容)

让 position的保存和消息的消费成为原子性操作，比如将消息和 position 同时保存到 hdfs 上 ，此时保存的 position 就称为 offset，当机器重启后，从 hdfs重新读入offset，这就是精确一次。

可以通过将提交分为两个阶段来解决：保存了offset后提交一次，消息处理成功之后再提交一次。但是还有个更简单的做法：将消息的offset和消息被处理后的结果保存在一起。比如用Hadoop ETL处理消息时，将处理后的结果和offset同时保存在HDFS中，这样就能保证消息和offser同时被处理了。