Kafka/Zookeeper宕机后消息丢失问题求助（Offset:-1001）

问题根源 #

Offset=-1001对应Kafka的UNKNOWN_TOPIC_OR_PARTITION错误，核心原因如下：

• Kafka/ZK宕机期间，生产者无法获取主题元数据，消息发送请求持续失败
• 结合幂等生产者（EnableIdempotence=true）的特性，长时间Broker不可用会导致生产者会话状态失效，恢复后无法正确重试积压的消息
• 你使用的Confluent Kafka 1.8.2版本较旧，存在幂等生产者在故障恢复场景下的消息丢失已知问题

具体优化建议 #

1. 调整超时与重试配置，避免无限等待 #

• 将MessageTimeoutMs设置为合理值（例如300000，即5分钟），避免消息无限制占用内存等待重试。超时后生产者会抛出异常，你可捕获异常并将消息落地到本地存储（如文件、数据库），待Broker恢复后手动重发。
• 保留MessageSendMaxRetries=int.MaxValue，配合MessageTimeoutMs确保超时前尽力重试，超时后主动处理失败消息。

2. 优化元数据刷新策略 #

• 降低MetadataMaxAgeMs值（例如30000，即30秒），让生产者在Broker恢复后更快刷新元数据，及时感知主题/分区的可用状态。
• 捕获到UNKNOWN_TOPIC_OR_PARTITION错误时，主动调用生产者的GetMetadataAsync方法刷新元数据，或调用Flush()强制处理积压请求。

3. 升级Confluent Kafka NuGet包 #

1.8.2版本存在多个幂等生产者相关的可靠性问题，建议升级到最新稳定版本（如2.2.x及以上），新版本修复了故障恢复场景下的消息丢失、元数据同步等问题，显著提升可靠性。

4. 本地消息持久化兜底 #

• 实现消息发送失败的本地持久化逻辑：捕获ProduceException且错误码为-1001时，将消息序列化后存储到本地可靠存储（如SQLite、本地文件）。
• 编写定时任务，定期检查Broker状态，待Broker恢复后批量重发本地存储的消息，确保消息不丢失。

5. 幂等生产者配置权衡（可选） #

• 若业务对消息顺序要求不极端严格，可考虑关闭EnableIdempotence，但会失去幂等性保障，需根据业务场景权衡。
• 若保留幂等性，确保Acks=All配置不变，这是消息不丢失的基础保障。

调整后的配置示例 #

new ProducerConfig
{
    BootstrapServers = <BROKET_END_POINT>,
    MessageMaxBytes = 20971520,
    MessageCopyMaxBytes = 20971520,
    LogConnectionClose = false,    
    BrokerAddressFamily = BrokerAddressFamily.V4,
    ConnectionsMaxIdleMs = 0,
    SocketKeepaliveEnable = true,
    MetadataMaxAgeMs = 30000, // 缩短元数据刷新间隔
    RequestTimeoutMs = 60000,
    MessageTimeoutMs = 300000, // 设置5分钟超时
    MessageSendMaxRetries = int.MaxValue,
    RetryBackoffMs = 100,
    EnableIdempotence = true,
    Acks = Acks.All,
    BatchSize = 2000000,
    LingerMs = 0,
    CompressionType = CompressionType.Gzip,
    SocketNagleDisable = true
};

内容的提问来源于stack exchange，提问作者Vishnu Kumar K S D