Kafka 1.0.0-cp1集群：单分区无重试时是否需设max.in.flight为1？

Great question—let's unpack this clearly based on how Kafka handles message ordering and producer behavior, since there's a common misconception around this setup.

Core Background First #

Let's quickly recap the key pieces that matter here:

• Single-partition topic: A single partition guarantees messages are consumed in offset order, but this doesn't automatically mean offset order matches the producer's send order—that depends on how requests are processed.
• max.in.flight.requests.per.connection: This controls how many unacknowledged requests the producer can fire off to a broker at the same time.
• retries: When enabled, failed requests get retried, which can create out-of-order messages if multiple requests are in flight (since a retry might land after subsequent successful requests).

Your Scenario: Single Partition + retries=0 #

Let's break down the two guarantees you're targeting:

1. Strict Message Order (Send Order = Storage/Consume Order)

The advice you read ("only set max.in.flight to 1 when using retries") is incomplete. Here's why:
Even with retries=0, if you set max.in.flight > 1, the producer sends multiple requests concurrently. Kafka brokers use multiple I/O threads to process requests, so a later-sent request could arrive at the broker first and get processed before an earlier one. This would result in messages being written to the partition in a different order than you sent them.

To strictly ensure that the order of messages in the partition matches exactly the order your producer sent them, you do need to set max.in.flight.requests.per.connection=1 here. This forces the producer to wait for each request to be acknowledged before sending the next, so the broker processes requests in the exact send order.

2. No Data Loss

Setting max.in.flight to 1 isn't directly tied to preventing data loss. To guarantee no data loss, focus on:

• Setting acks=all (or -1) to ensure messages are acknowledged by all in-sync replicas.
• Handling send failures explicitly: since retries=0 means failed requests won't auto-retry, you'll need custom logic to retry or resolve failures if losing data is unacceptable.

Throughput vs. Strict Order Trade-off #

Since you're benchmarking for maximum throughput while maintaining guarantees, note that max.in.flight=1 will reduce producer throughput (it removes concurrency from the request pipeline). If strict send-order is non-negotiable, this setting is required even with retries=0 and a single partition. If you only care about messages being consumed in offset order (not matching the exact send order), you can increase max.in.flight to boost throughput without breaking partition-level ordering.

Content sourced from Stack Exchange, question author: Quentin Geff