什么是客户端接入三板斧?

用户在第一次接入消息队列 for Apache Kafka 时,通常会被以下三个问题困扰:

  • 网络连通问题

  • 客户端版本问题

  • 配置问题

从上述三个方向,一步一步排查,基本上可以解决 99% 的问题。

为什么会出现 Not authorized to access group?

如果您的 Consumer Group 没有创建,则会遇此报错信息。您可在控制台或调用管控 API 创建 Consumer Group。具体步骤请参见步骤二:创建 Consumer GroupCreateConsumerGroup

哪里可以找到消费最佳实践?

请参见订阅者最佳实践

如何查看哪些 IP 在消费消息?

在控制台根据 Consumer Group 查看消费状态,单击详情,可以看到各个分区的 owner,进而看到对应的 IP。

如果看到 owner 为空,说明客户端不在线或者处于 Rebalance 中。

控制台看到的“最近消费时间”是什么意思?

是指最近消费的一条消息的存储时间。

如果消费没有堆积,那么这个时间,应该和发送时间比较接近。

为何删除了 Consumer Group 还会收到堆积告警?

删除了 Consumer Group,只是从控制台逻辑删除,并不会实际删除服务端消费位点等信息。

消息队列 for Apache Kafka 的消费位点保存在一个内部 Topic 里面,无法直接删除,只能等待其过期。位点在超过消息保留期限后仍然没有任何更新,就会被过期清理。

注意 较早购买的用户,没有开启这个清理机制,请先在实例详情页,升级服务端版本到最新。

堆积告警的原理是根据位点进行处理的。

如果删除了 Consumer Group 还收到告警,您可以选择:

  • 禁用这个告警

  • 等待位点过期

消息堆积了怎么办?

消息队列 for Apache Kafka 的消息是客户端主动去服务端拉取的,一般来说,因为是批量拉取机制,服务端拉取都不会是消费的瓶颈。

消息堆积一般都是消费速度过慢或者消费线程阻塞造成的。

建议打印消费消息的耗时,或者查看堆栈信息以查看线程执行情况。

注意 Java 进程可以用 Jstack 打印消费者进程的堆栈信息。

为什么消费客户端频繁出现 Rebalance?

消息队列 for Apache Kafka 的 Consumer 没有独立线程维持心跳,而是把心跳维持与 poll 接口耦合在一起,其结果就是如果用户消费出现卡顿会导致心跳超时,引发 rebalance。

解决方案:

首先您需要了解:

  • session.timeout.ms 配置控制心跳的超时时间,可以由客户端自行设置

  • max.poll.records 控制每次 poll 返回的最大消息数量

  • 消息队列 for Apache Kafka 的心跳是通过 poll 接口来实现的,没有内置的独立线程

所以,避免心跳超时主要依靠:

  • max.poll.records 设置小一点

  • session.timeout.ms 设置大一点

  • 尽力提高消费速度

其中:

  • session.timeout.ms 不要超过 30s,建议设置成 25s。

  • max.poll.records 要小于(最好是远小于) "单个线程每秒消费的条数" x "消费线程的个数" x "session.timeout 的秒数"。

Consumer 在读取消息的时候因为异常发生中断,解决异常之后,如果想管理 Consumer 的 offset,是否可以直接在控制台上操作?

消费消息并不保证会提交消费位点,Broker 记录的是客户端提交的消费位点,提交就是消费确认的意思。

提交的机制取决于您使用的客户端 SDK,一般支持以下两种机制:

  • 自动提交:按照时间间隔,SDK 把消费过的最新消息的位点 + 1 提交上去。

  • 手动提交:应用程序里,把消费过的最新消息的位点 + 1 提交上去。

正常的话,可以在控制台的 Consumer Group 管理页面,单击消费状态,这是您的 Consumer 提交的最新位点。Consumer 消费时,就是从这个位点继续消费。具体的操作指导请参见查看消费状态

在管理控制台上操作,可以人工移动 Broker 记录的消费位点。可以往前移动,重复消费,也可以往后移动,跳过消费。

注意 在控制台上重置消费位点,需要先停止消费客户端。否则,重置的结果很可能被消费端覆盖掉。