最近项目中用到了Kafka0.9，在使用0.9的Consumer API的时候遇到了poll()方法阻塞的问题。程序没有报任何错误，只是持续在poll()方法处阻塞。深入poll()方法可以看到是在AbstractCoordinator.ensureCoordinatorKnown()方法中出现了死循环。在循环中不停地输出如下DEBUG日志： 需要关注的是这处信息： 看样子是kafka的连接出了问题。不过我的Producer向kafka写数据是没问题的，使用kafka提供的消费工具kafka-console-consumer.sh执行消费也是没问题的。 在网上找到了一些关于这个现象的解释：在客户端进行消费之前会为ConsumerGroup向Kafka集群申请coordinater节点。kafka集群在配置或分配coordinater节点的时候可能会短暂的报这个错误。 我这里不是短暂的报错，而是陷入了死循环。目前可以想到的就是我的kafka集群配置出现问题了。在简单粗暴地将zookeeper上kafka的配置完全删掉再重启Kafka后，消费可以正常执行了。至于问题具体出在哪儿还没有找到。目前只能是持续关注，等问题再次出现了。 就这样。 还有一点，在查询解决方案的过程中看到：如果kafka是部署在Docker上，出现了这样的问题需要检查有没有配置环境变量ADVERTISE.HOST.NAME和ADVERTISE.HOST.PORT。 ######

从kafka的0.8.11版本开始，它会将consumer的offset提交给ZooKeeper。然而当offset的数量（consumer数量 * partition的数量）的很多的时候，ZooKeeper的适应性就可能会出现不足。幸运的是，Kafka现在提供了一种理想的机制来存储Consumer的offset。Kafka现在是将Consumer的offset写入到一个分布式持久化的、高可用的topic中。开发者可以通过消费这个topic的方式来获取Consumer的offset。为了提升访问速度，kafka还提供了offset的内存缓存。也就是说，现在提交offset是通过普通的生产者请求（代价并不高）来完成的，而获取offset则是通过在内存中的快速查询完成的。 Kafka的官方文档描述了这个特性是如何工作的，以及如何将offset从zookeeper迁移到kafka。下面的代码演示了如何利用基于kafka存储offset的特性。 第一步：通过发送consumer元数据请求到任意Broker来发现并连接offset manager： 第二步：发送OffsetCommitRequest 或者 OffsetFetchRequest到offset manager： 原文：https://cwiki.apache.org/confluence/display/KAFKA/Committing+and+fetching+consumer+offsets+in+Kafka ####