版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/u013817676/article/details/86212691
Kafka offset管理
消费者在消费的过程中需要记录自己消费了多少数据，即消费 Offset。Kafka Offset 是Consumer Position，与 Broker 和 Producer 都无关。每个 Consumer Group、每个 Topic 的每个Partition 都有各自的 Offset，如下图所示。
通常由如下几种 Kafka Offset 的管理方式：
- Spark Checkpoint：在 Spark Streaming 执行Checkpoint 操作时，将 Kafka Offset 一并保存到 HDFS 中。这种方式的问题在于：当 Spark Streaming 应用升级或更新时，以及当Spark 本身更新时，Checkpoint 可能无法恢复。因而，不推荐采用这种方式。
- HBASE、Redis 等外部 NOSQL 数据库：这一方式可以支持大吞吐量的 Offset 更新，但它最大的问题在于：用户需要自行编写 HBASE 或 Redis 的读写程序，并且需要维护一个额外的组件。
- ZOOKEEPER：老版本的位移offset是提交到zookeeper中的，目录结构是 ：/consumers/<group.id>/offsets/ <topic>/<partitionId> ，但是由于 ZOOKEEPER 的写入能力并不会随着 ZOOKEEPER 节点数量的增加而扩大，因而，当存在频繁的 Offset 更新时，ZOOKEEPER 集群本身可能成为瓶颈。因而，不推荐采用这种方式。
- KAFKA 自身的一个特殊 Topic（__consumer_offsets）中：这种方式支持大吞吐量的Offset 更新，又不需要手动编写 Offset 管理程序或者维护一套额外的集群，因而是迄今为止最为理想的一种实现方式。
另外几个与 Kafka Offset 管理相关的要点如下：
- Kafka 默认是定期帮你自动提交位移的（enable.auto.commit=true）。有时候，我们需要采用自己来管理位移提交，这时候需要设置 enable.auto.commit=false。
- 属性 auto.offset.reset 值含义解释如下：
- earliest ：当各分区下有已提交的 Offset 时，从“提交的 Offset”开始消费；无提交的Offset 时，从头开始消费；
- latest ： 当各分区下有已提交的 Offset 时，从提交的 Offset 开始消费；无提交的 Offset时，消费新产生的该分区下的数
- none ： Topic 各分区都存在已提交的 Offset 时，从 Offset 后开始消费；只要有一个分区不存在已提交的 Offset，则抛出异常。
- 与 Kakfa Offset 管理相关的几条 SHELL 命令示例如下：
显示group.id为kline的consumer group的当前offset
kafka-consumer-groups –bootstrap-server host:9092 –group cgroup –describe
查将group-id为cgroup的consumer group的所有partition的当前offset指向第1000条消息
kafka-consumer-groups --bootstrap-server host:9092 --group cgroup --topic test --reset-offsets --to-offset 1000 –execute
参考：