gpt4 book ai didi

c# - Kafka 消费者启动延迟融合 dotnet

转载 作者:行者123 更新时间:2023-12-05 00:49:08 26 4
gpt4 key购买 nike

启动 confluent-dotnet 消费者时,在调用 subscribe 和随后的轮询之后,似乎需要很长时间才能从服务器接收“已分配分区”事件以及消息(大约 10-15 秒)。

一开始我以为有自动创建主题的开销,但是不管消费者的主题/消费者组是否已经存在,时间都是一样的。

我用这个配置启动我的消费者,其余的代码与融合的高级消费者示例中的相同:

            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 秒

最佳答案

Kafka 消费者按设计成组工作 - 您看到的延迟是组协调器(驻留在集群上,而不是客户端)等待任何现有/先前 session 超时并允许任何其他消费者在在将分区分配给具有事件连接的所有消费者之前要启动的同一组。

事实上,如果你足够快地重新启动你的测试消费者,你会看到延迟跳到几乎 30 秒,因为 session.timeout.ms有一个默认值 30000 并且集群仍然没有“注意到”前一个消费者已经离开,直到这个超时开始。同样如果你改变 group.id在重新启动之间,您会看到延迟急剧下降,因为集群不会等待属于不同组的现有使用者。

最后,在再次启动之前尝试干净地退出您的消费者(调用 Unsubscribe() 并确保消费者已被处理)。

看来session.timeout.ms可以降低到 6000 以减少任何现有消费者组连接的超时,但不能降低。

即使一切都开始“干净”,看起来您仍然会延迟最多 7 秒(我猜是标准连接设置加上等待同一组中的任何其他消费者开始)。如果您使用 Assign() 而不是 Subscribe() ,那么您选择自己将分区分配给您的消费者,并且自动组平衡不适用。

关于c# - Kafka 消费者启动延迟融合 dotnet,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/48223765/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com