当启动合流的dotnet使用者时，在调用subscribe和随后的轮询之后，似乎需要很长时间才能从服务器接收“partition assigned”事件，从而接收消息（大约10-15秒）。
起初我以为有一个自动主题创建开销，但时间是一样的，无论主题/消费者组是否已经存在。
我使用此配置启动消费者，其余代码与confluent advanced consumer示例中的代码相同：
var kafkaConfig = new Dictionary<string, object>
{
{"group.id", config.ConsumerGroup},
{"statistics.interval.ms", 60000},
{"fetch.wait.max.ms", 10},
{"bootstrap.servers", config.BrokerList},
{"enable.auto.commit", config.AutoCommit},
{"socket.blocking.max.ms",1},
{"fetch.error.backoff.ms",1 },
{"socket.nagle.disable",true },
{"auto.commit.interval.ms", 5000},
{
"default.topic.config", new Dictionary<string, object>()
{
{"auto.offset.reset", "smallest"}
}
}
};kafka集群由远程数据中心中的3台中低规格机器组成，具有默认设置。是否有可以调整的代理或客户端设置来减少此启动时间？
编辑：用assign而不是subscribe分配分区会导致大约2秒的启动时间
1条答案
按热度按时间rfbsl7qr1#
kafka使用者按设计分组工作—您看到的延迟是组协调器（驻留在集群上，而不是客户端）等待任何现有/以前的会话超时，并允许同一组中的任何其他使用者启动，然后再将分区分配给具有活动连接的所有使用者。
事实上，如果您足够快地重新启动您的测试消费者，您将看到延迟跳到近30秒，因为
session.timeout.ms有一个默认值30000，集群仍然没有“注意到”上一个消费者已经离开，直到这个超时开始。如果你改变了group.id在重启之间，您将看到延迟急剧下降，因为集群不会等待属于不同组的现有使用者。最后，在再次启动之前，请尝试干净地退出使用者（调用unsubscribe（），并确保已释放该使用者）。
看来
session.timeout.ms可以降低到6000以减少任何现有消费组连接的超时，但不能降低。即使一切开始“干净”，它似乎仍然会得到高达7秒的延迟（我猜标准连接设置加上等待同一组中的任何其他消费者开始）。如果您使用assign（）而不是subscribe（），那么您选择自己将分区分配给您的使用者，而自动组平衡不适用。