启动融合的dotnet使用者时,在调用订阅和随后的轮询之后,似乎需要很长时间才能从服务器接收到“分配的分区”事件,并因此收到消息(大约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台中低端规格机器组成.
是否可以调整代理或客户端设置以减少启动时间？

编辑：使用“分配”而不是“订阅”自己分配分区会导致大约2秒的启动时间

解决方法:

Kafka使用者是按小组设计工作的-您看到的延迟是小组协调员(驻留在群集上,而不是客户端),等待任何现有/先前的会话超时,并允许该组中的任何其他使用者使用在将分区分配给具有活动连接的所有使用者之前启动同一组.

实际上,如果您以足够快的速度重新启动测试使用者,则会看到延迟跃升至将近30秒,因为session.timeout.ms的默认值为30000,并且群集仍未“注意到”前一个消费者已经走了,直到超时时间到来.同样,如果您在两次重启之间更改group.id,则您将看到延迟急剧下降,因为群集将不会等待属于另一个组的现有消费者.

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

似乎可以将session.timeout.ms降低到6000以减少任何现有使用者组连接的超时,但是不能降低.

即使一切开始都“干净”,您似乎仍然会延迟7秒钟(我猜是标准连接设置,还要等待同一组中的所有其他使用方开始).如果使用Assign()而不是Subscribe(),则您选择自己将分区分配给使用者,并且自动组平衡不适用.