关键不是单独调大retries，而是让retries、retry.backoff.ms、delivery.timeout.ms和request.timeout.ms协同工作：retries需设为3或5（不可为0），retry.backoff.ms按网络环境设50–500ms，delivery.timeout.ms显式设120000（风控场景可降为30000），request.timeout.ms设30000且须小于前者。
配置 Kafka 生产者的重试次数与超时时间，关键不是单独调大 retries，而是让 retries、retry.backoff.ms、delivery.timeout.ms 和 request.timeout.ms 协同工作，避免无限重试或过早放弃。
重试次数（retries）不能设为 0
retries 控制可恢复异常（如网络抖动、leader 切换）下的最大重试尝试次数。Kafka 2.0+ 默认值是 Integer.MAX_VALUE，等效于“无限重试”，但实际受超时参数限制。业务中建议显式设置：
- 普通场景：设为 3 或 5，兼顾可靠性与响应性
- 强一致性要求（如金融类）：可保留默认（即不显式设为 0），但必须配好 delivery.timeout.ms 防兜底失控
- 绝对不要设为 0 —— 这等于放弃对临时故障的自动恢复能力，ack=all 也救不回一次瞬断
重试间隔用 retry.backoff.ms 控制基础节奏
它定义第一次重试前等待多久，后续按带抖动的指数退避增长（比如设 200ms → 实际可能 180ms、230ms、410ms…）。这个值影响重试密集度和集群压力：
- 内网稳定环境：可设 50–100ms
- 跨机房或公网链路：推荐 200–500ms
- 避免设太小（如 10ms）——易引发雪崩式重试；也别太大（如 5000ms）——拖慢故障恢复
真正决定“重试多久”的是 delivery.timeout.ms
这是 Kafka 2.1+ 引入的核心兜底参数，默认 120000（2 分钟），覆盖从发起到最终确认/失败的全过程。它比旧版靠 request.timeout.ms + retries 组合更可靠：
- 建议显式设为 120000（2 分钟），防止因 retries 无限导致线程卡死或内存积压
- 实时风控等低延迟场景可降至 30000（30 秒），但需接受少量不可恢复失败
- 该值必须大于 request.timeout.ms（通常设为 30000 左右），否则后者会先超时触发重试，而前者还没到上限
request.timeout.ms 是单次请求的等待上限
它控制生产者向 broker 发一个请求后，最多等多久响应。超时即触发一次重试（如果还有剩余次数）：
- 一般设为 30000（30 秒）较稳妥，需略小于 delivery.timeout.ms
- 若 broker 副本同步慢（如 replica.lag.time.max.ms 设得高），此值应比它大，否则会误判为失败并重发
- 注意：它不控制整个发送流程，只管单次网络往返
