在Kafka中，发送模式与ack机制紧密相关，它们共同影响着消息发送的可靠性和性能。

Kafka的发送模式

• 发后即忘（Fire and Forget）：生产者发送消息后不等待任何来自服务器的确认，继续处理下一条消息，实现简单、低延迟，但可能会有消息丢失。

• 同步发送（Sync）：生产者发送消息后，会阻塞等待服务器的确认响应，确保消息发送成功，可靠性高，但会降低发送速度，影响吞吐量。

• 异步发送（Async）：生产者发送消息后，通过回调函数处理服务器的响应，消息发送后可继续执行其他操作，能提高吞吐量，也可通过回调函数处理发送结果。

Kafka的ack机制

• ack=0：生产者发送消息后，无需等待服务器确认，服务器可能没收到消息就认为发送完成，可能导致消息丢失，延迟最低但可靠性差，适用于允许少量消息丢失且追求极致性能的场景。

• ack=1：生产者发送消息后，只要分区的leader副本成功写入消息，就会收到确认，若leader副本写入后follower副本同步前leader故障，可能丢失消息，性能和可靠性较平衡。

• ack=-1或all：生产者发送消息后，需等待所有同步中的副本都成功写入消息才会收到确认，保证消息不丢失，可靠性最高，但可能因等待所有副本确认而增加延迟，降低吞吐量。

发送模式与ack的关联

• 发后即忘：通常搭配ack=0，以追求最大的发送性能和最低延迟，不在乎消息是否丢失。

• 同步发送：常与ack=1或ack=-1搭配，需确保消息可靠到达服务器，若对消息可靠性要求极高选ack=-1，若能容忍一定程度数据丢失以换取性能选ack=1。

• 异步发送：可与各种ack值搭配，根据业务场景选择。如对实时性要求高但能接受少量消息丢失可选ack=1搭配异步发送，通过回调函数处理发送结果；若要保证消息可靠性，可将ack=-1与异步发送结合，通过回调函数确保消息处理。

重试次数

retries参数用来配置生产者重试的次数，默认值为0，即在发生异常的时候不进行任何重试动作。消息在从生产者发出到成功写入服务器之前可能发生一些临时性的异常，比如网络抖动、leader副本的选举等，这种异常往往是可以自行恢复的，生产者可以通过配置retries大于0的值，以此通过内部重试来恢复而不是一味地将异常抛给生产者的应用程序。如果重试达到设定的次数，那么生产者就会放弃重试并返回异常。不过并不是所有的异常都是可以通过重试来解决的，比如消息太大，超过max.request.size参数配置的值时，这种方式就不可行了。

重试还和另一个参数retry.backoff.ms有关，这个参数的默认值为100，它用来设定两次重试之间的时间间隔，避免无效的频繁重试。在配置retries和retry.backoff.ms之前，最好先估算一下可能的异常恢复时间，这样可以设定总的重试时间大于这个异常恢复时间，以此来避免生产者过早地放弃重试。

Kafka可以保证同一个分区中的消息是有序的。如果生产者按照一定的顺序发送消息，那么这些消息也会顺序地写入分区，进而消费者也可以按照同样的顺序消费它们。对于某些应用来说，顺序性非常重要，比如MySQL的binlog传输，如果出现错误就会造成非常严重的后果。如果将acks参数配置为非零值，并且max.in.flight.requests.per.connection参数配置为大于1的值(这部分在kafka生产端之架构及工作原理中会详细讲解该配置)，那么就会出现错序的现象：如果第一批次消息写入失败，而第二批次消息写入成功，那么生产者会重试发送第一批次的消息，此时如果第一批次的消息写入成功，那么这两个批次的消息就出现了错序。一般而言，在需要保证消息顺序的场合建议把参数max.in.flight.requests.per.connection配置为1，而不是把acks配置为0，不过
这样也会影响整体的吞吐。

总结

通过上面的讲解我们应该可以知道如何尽可能的保障生产者消息不丢失。