本文探讨了Kafka中消息日志Offset的概念，通过实验验证了Offset并非绝对位置，而是基于消息日志文件和内部offset的组合。当Kafka根据log.retention.hours清理日志后，新消息的Offset会从之前的最高位开始，确保消费者能继续正常消费。这一理解有助于解决Storm整合Kafka时可能遇到的消费问题。
之前在做Kafka 整合Storm的时候，因为对Kafka 不是很熟，考虑过这样的一个场景问题，针对一个Topic,Kafka消息日志中有个offset信息来标注消息的位置，Storm每次从kafka 消费数据，都是通过zookeeper存储的数据offset，来判断需要获取消息在消息日志里的起始位置。
那么我们想，这个Offset 是消息在日志里是一个什么样的位置，是绝对位置还是相对位置？而Kafla 有个参数log.retention.hours会根据设定的小时，来清理日志文件。这样就可能会有这样的一个问题，针对一个Topic，Kafka 生产数据后，消费者消费信息后，此时的消息的offset是一个高位，比如100，消费者在消费完会记录这个offset准备下个数据的获取。而当系统时间达到参数log.retention.hours设定的时间后，kafka会自动删除这个Topic的缓存日志，那么这个时候新加入10条消息，消息的offset 是重新开始还是从删除日志前的Offset 开始？如果是前者，这个时候消费者因为记录消费这个Topic信息的Offset 仍在高位，那么他就获取不到在这个Offset前的新加入数据，这样就比较麻烦了。而后者，offset又是怎么记录消息相对位置的从而消费者一直消费到数据，无论系统怎么处理日志。这个是Storm 消费Kafla数据的时候必须要确认的问题。
所以做了一个针对性测试。
将
最低0.47元/天 解锁文章
扫一扫
1877
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
