kafka16-生产者的吞吐量和延迟优化2

目录

ProducerBatch优化

批处理参数优化

批处理优化策略

RecordAccumulato优化

1. buffer.memory 参数

2. max.block.ms 参数

3. 优化策略

发送请求优化

1. max.in.flight.requests.per.connection 参数

2. 发送顺序无要求的优化

3. 要求按顺序发送消息的优化

4. 启用幂等发送机制

5. 多分区精准一次写入消息

6. 示例配置

---

ProducerBatch优化

批处理参数优化

1. linger.ms：控制生产者在发送消息之前等待的毫秒数，以便将多个消息合并到同一个批次中。增加linger.ms的值可以提高吞吐量，但可能会增加消息的延迟。

   • 默认值：0（无延迟，立即发送）
   • 优化建议：设置为20毫秒或更高，以等待更多的消息加入当前批次。

2. batch.size：定义了一个ProducerBatch中包含最大字节数。增加batch.size的值可以发送更大的批次，从而减少网络请求的次数。

   • 默认值：16KB
   • 优化建议：在资源充足的情况下，增加到32KB或64KB。

批处理优化策略

1. 根据ProducerBatch填充情况调整linger.ms：

   如果大部分的ProducerBatch未被填满，增加linger.ms的值，以便在发送前填满批次

   properties.setProperty(ProducerConfig.LINGER_MS_CONFIG, "20");
   

2. 根据内存资源调整batch.size：

   如果ProducerBatch经常被填满，并且有足够的内存资源，增加batch.size的值以发送更大的批次。

   properties.setProperty(ProducerConfig.BATCH_SIZE_CONFIG, Integer.toString(32*1024));

RecordAccumulato优化

RecordAccumulator 是 Kafka 生产者中用于缓存待发送消息的核心组件。

1. buffer.memory 参数

• 作用：buffer.memory 控制生产者内存缓冲区的大小，用于缓存尚未发送到 Broker 的消息。
• 默认值：33554432 字节（32 MB）。
• 优化建议：如果生产环境的资源充足，可以适当增加 buffer.memory 的值。例如，设置为 67108864 字节（64 MB）可以增大缓存容量，减少发送阻塞的可能性。

2. max.block.ms 参数

• 作用：max.block.ms 控制生产者在 send() 方法调用时，如果 RecordAccumulator 已满，能够阻塞等待的最长时长。
• 默认值：60000 毫秒（1 分钟）。
• 超时处理：如果阻塞时长超过 max.block.ms，生产者将抛出超时异常。

3. 优化策略

• 增加缓冲区大小：适当增加 buffer.memory 可以减少 RecordAccumulator 被填满的风险，从而减少 send() 方法的阻塞。
• 调整阻塞时长：根据业务需求和系统特性，调整 max.block.ms 的值。如果业务允许，可以适当增加此值，以避免在高负载情况下发生超时。

发送请求优化

在 Kafka 生产者中，优化发送请求是提高吞吐量和确保消息顺序的关键。以下是针对 max.in.flight.requests.per.connection 参数和其他相关配置的优化建议：

1. max.in.flight.requests.per.connection 参数

• 作用：控制对每个 Broker 节点同时发送的请求数量。
• 默认值：5。
• 限制：最大值不允许超过 5。

2. 发送顺序无要求的优化

• 场景：当不需要保证消息顺序，且未开启幂等性（enable.idempotence=false）时。
• 配置建议：
  • enable.idempotence=false：关闭幂等性以允许更多的并发请求。
  • max.in.flight.requests.per.connection=5：允许每个 Broker 节点最多有 5 个并发请求。
  • acks=all（①）：确保消息被所有同步副本确认。
  • retries=30（②）：设置较高的重试次数以处理临时错误。
  • retry.backoff.ms=200（③）：设置重试间隔，减少频繁重试。
  • default.replication.factor=3（④）：设置副本数为 3，提高数据安全性。
  • min.insync.replicas=2（⑤）：至少需要 2 个副本（包括 Leader）确认消息。

3. 要求按顺序发送消息的优化

• 场景：当需要保证消息顺序，且未开启幂等性时。
• 配置建议：
  • max.in.flight.requests.per.connection=1：限制为 1，确保消息按顺序发送，但会降低吞吐量。

4. 启用幂等发送机制

• 场景：当需要保证消息顺序且希望提高吞吐量时。
• 配置建议：
  • enable.idempotence=true：开启幂等性，确保消息不会重复发送。
  • max.in.flight.requests.per.connection：可以设置为小于等于 5 的值，以提高吞吐量。

5. 多分区精准一次写入消息

• 场景：需要向多个分区精确写入一次消息。
• 配置建议：
  • enable.idempotence=true：开启幂等性。
  • transactional.id=UNIQUE-ID（①）：指定全局唯一的事务 ID。
  • transaction.timeout.ms=900000（②）：设置事务超时时间。

6. 示例配置

# 对发送顺序无要求的配置
enable.idempotence=false
max.in.flight.requests.per.connection=5
acks=all
retries=30
retry.backoff.ms=200
default.replication.factor=3
min.insync.replicas=2

# 要求按顺序发送消息的配置
enable.idempotence=false
max.in.flight.requests.per.connection=1

# 启用幂等发送机制的配置
enable.idempotence=true
max.in.flight.requests.per.connection=5
acks=all
retries=30

# 多分区精准一次写入消息的配置
enable.idempotence=true
max.in.flight.requests.per.connection=5
acks=all
retries=30
transactional.id=your_unique_transactional_id
transaction.timeout.ms=900000