我们经常出现这个问题,除了上次修复完后,正常跑也总有这种问题。因为我们的场景是文件扫描,文件扫描的处理方式是很重的,消费时间长。所以经常触发重平衡。
那么又回到了原始问题。第一性原理,运维和架构,就是要做工程上的最佳实践,而不是什么技术新旧。最佳实践就是最佳适配。
kafka的consumer重平衡机制,注定了它不适合做长逻辑耗时业务的处理。(它的背景本身是无逻辑处理,只是传输日志)
-----------------------------------------------------------------
20220419复现:
参数
config.Consumer.Group.Session.Timeout = time.Second * 120
config.Consumer.Group.Heartbeat.Interval = time.Second * 20
调整成
config.Consumer.Group.Session.Timeout = time.Second * 30 config.Consumer.Group.Heartbeat.Interval = time.Second * 5
就复现:
{"Level":"panic","Time":"2022-04-19T20:01:14.874530508+08:00","LoggerName":"","Message":
"Error from consumer: read tcp :33178-\u003e:9093: i/o timeout",
"Caller":{"Defined":true,"PC":8910019,"File":"/data/share//golang/cloudscan/pubsub/groupconsumer.go","Line":147,
"Function":"cloudscan/pubsub.(*GroupConsumer).StartConsume.func1"},"Stack":"cloudscan/pubsub.(*GroupConsumer).StartConsume.func1\n\t
/data/share//golang/cloudscan/pubsub/groupconsumer.go:147"
----------------------------------------------------------------
为了应对这种情况,我们调大了Sarama 的参数config.Consumer.Group.Session.Timeout = time.Second * 120,也就是心跳超时时间,但我们的网络超时时间很小,默认30秒,30秒我们的场景,文件扫描消费时间长,30秒是可能处理不完数据的。最终配置:
config