我遇到了两个关于订购的短语，
生产者发送到特定主题分区的消息将按发送顺序追加。也就是说，如果记录m1由与记录m2相同的生产者发送，并且首先发送m1，那么m1的偏移量将低于m2，并且在日志中出现得更早。
另一个
（config param）max.in.flight.requests.per.connection—客户端在阻塞之前在单个连接上发送的未确认请求的最大数目。请注意，如果将此设置设置为大于1并且存在失败的发送，则存在由于重试而导致消息重新排序的风险（即，如果启用了重试）。
问题是，如果有像上面提到的#2那样的失败发送，那么顺序是否仍会保留到特定分区？如果一条消息存在潜在问题，则将删除每个分区的以下所有消息“以保留顺序”，或者将发送“正确”的消息，并将失败的消息通知应用程序？
1条答案
按热度按时间0wi1tuuw1#
“如果出现如#2所述的失败发送，顺序是否仍会保留到特定分区？”
如您复制的文档部分所述，存在更改订单的风险。
想象一下，你有一个主题，例如一个分区。你设置了
retries100和max.in.flight.requests.per.connection到大于1的5。请注意，只有设置acks到1或“全部”。如果您计划按k1、k2、k3、k4、k5的顺序生成以下消息，并且您的生产者需要一些时间才能完成
实际创建批和
向经纪人提出请求
等待经纪人的确认
您最多可以有5个并行请求（基于
max.in.flight.request.per.connection). 现在，产生“k3”有一些问题，它进入重试循环，消息k4和k5可以产生，因为请求已经在运行。您的主题将以以下顺序结束：k1、k2、k4、k5、k3。
如果您在kafka生产者中启用了幂等性，那么在使用幂等kafka生产者时，仍然可以按照订购保证中的说明保证订购