Kafka线上常见问题及性能优化

消息丢失问题

1）消息发送端

1. acks=0: 表示producer不需要等待broker确认收到消息的回复就可以继续发送下一条消息；该方式性能最高，但最容易丢消息，适用于大数据报表等对性能要求较高对数据丢失不敏感等场景。
2. acks=1: 表示producer至少要等待leader分区副本成功将消息写入本地log之后不需要等待所有follower分区副本写入成功就可以继续发送下一条消息；该方式若follower副本没有成功备份数据但leader副本宕机了，此时消息会丢失。
3. acks=-1或all: 表示producer需要等待所有分区副本(参数 min.insync.replicas 配置的副本备份个数)都成功写入log之后就可以发送下一条消息；该方式会保证只要有一个备份副本所在的broker存活就不会丢失消息，此方式最不容易丢消息，一般用于金融行业等消息安全性高的场景。若参数 min.insync.replicas 配置的副本备份个数为1则与acks=1类似。

2）消息消费端

消费端配置的是offset自动提交时，若消费到的消息还没处理完就自动提交offset，此时consumer直接宕机，则未执行完的消息就会丢失，下次也不会消费到。

消息重复消费问题

1）消息发送端

发送消息若配置重试机制，如网络抖动时间过长导致发送端发送超时，实际broker可能已经接收到消息，但发送端会重复发送消息

2）消息消费端

消费消息若配置自动提交，拉取的一批消息处理了一部分后还未来得及提交offset 服务宕机，下次重启又会重复拉取相同的一批消息处理；一般来说消费端需要做消息幂等处理

消息乱序问题

若发送端配置重试且acks=0机制，当发送1,2,3三条消息时第一条消息发送超时，接着发送2,3消息成功，后续第一条消息重试发送成功，那么在broker端写入消息log的顺序为2,3,1；
可以通过配置发送端同步发送消息且acks!=0的方式保证消息发送时的有序性。
注意：kafka全链路