2020-09-29

问题描述：线上业务出现推送延迟，启动测试工具订阅topic，能看到数据正常时间能对上（数据写进去了），用kafka自带的也能对上，
通过分析后发现工具记录的日志在9点41分启动-9点50分之间出现了秒级延迟（最多延迟16秒）。通过阿里云监控发现有台kafka磁盘IO是38M，检查高效云盘磁盘IO吞吐量上限是140M/s，说明IO没问题。
进一步发现网络流出带宽达到850M/s，和运维确认带宽上限是800M/s，确认是出口带宽引起读取延迟。

用工具订阅一个topic，打印数据和日志时间，发现一开始不延迟，但是慢慢出现数据内的时间戳（应用层加的）比日志时间小！！

1.运维规范：前段时间运维因成本原因对kafka规格降级，对应的带宽也降低了，成本允许下服务器配置应该按峰值来预估，按需分配是值得商榷的，多少是需呢，拿最近半个月看就是需了吗，没有足够的历史数据参考，这个需对吗？
2.开发规范：随着业务发展，新增topic订阅变多，存在增加一个小功能就订阅一次topic的现象，这种情况需要杜绝。
3.部署规范：按业务分开部署，多个集群

解决：
1.关于topic订阅，有些topic数据量比较大，应用功能能合的，合在一起，一次订阅多次计算，以免流量暴涨。
2.生产写数据时指定key，在多分区时，同一个key会落在相同的分区，这样可以保证单个股票数据顺序性。3个broker，设置3个分区，均衡资源并提高吞吐量。

扩展：
消息分配到分区有三种模式，分别是RandomPartitioner, RoundRobinPartitioner and HashPartitioner，sarama默认配置用HashPartitioner，同样的key会落在相同的分区。

往kafka写数据时指定KEY：
msg := &sarama.ProducerMessage{
   Topic: "real-" + time.Now().Format("20060102"),
   Key:   code,
   Value: sarama.StringEncoder(string(data)),
}
conn.KafkaProducer.Input() <- msg