1、以事务方式发送 Kafka 消息

在自 2016 年以来，Mirakl 开始使用 Kafka 作为消息服务，以支持在微服务环境中的异步驱动架构。

Kafka的恰好一次
每条消息都精确传递一次，它为流处理应用程序等读取-处理-写入任务提供端到端的精确一次保证。为了支持这种保证，Kafka 依赖于两个特性：

• 幂等传递：允许生产者只发送一次消息（属于同一生产者的重复消息被代理忽略）
• 事务交付：允许生产者以原子方式将数据发送到多个分区，这意味着要么所有事件都成功交付，要么没有一个。

您应该注意，此语义仅在 Kafka Streams 内部处理范围内得到保证，其中包括使用事件、更新状态存储和生成事件。尝试更新 Kafka 外部的状态，例如更新数据库中的行或进行 API 调用，将导致较弱的保证。

尝试一次更新两个系统在设计和实现方面都极具挑战性，尤其是对于我们知道 Kafka 不支持分布式事务的案例。在 Mirakl，我们决定一次只更新一个系统，首先我们更新数据库，然后使用异步过程将这些更新从数据库驱动到 Kafka。
这就是通常所说的发件箱模式。

2、Apache Kafka重试和维护重试事件的顺序

重试非常重要，尤其是在 微服务 系统中，这些服务必须经常协作才能处理请求。如果一个服务只中断了几秒钟会发生什么？其他服务应该在放弃之前向客户抛出错误或重试多次。

使用更多重试主题和死信队列主题使我们能够在不阻塞主要消费者的情况下重试请求。开发人员将轻松监控 DLQ 中一直失败的事件并手动删除或重新处理它。

这种方法的一个缺点是，如果我们想多次重试，它会创建多个主题。所以我们应该限制重试的次数。

另一个需要考虑的问题是在需要时中断事件的重试流程。我们可以删除 Kafka 的重试主题（墓碑）中的记录。

3、Udemy在Apache Kafka上引入热重试和冷重试

Udemy 平台上有超过 4600 万学生和 64400 万课程注册，每天都有许多用户通过结帐流程来访问内容。这会产生大量流量，同时也会导致许多支付交易。

让我们从定义一些术语开始讨论。我们将在接下来的部分中大量提及它们，最好事先澄清它们。

1. 热重试：这是一种在使用消息时遇到错误后立即重试消息的策略。例如，您可以考虑这样一种场景，即您的消费者由于套接字超时而无法连接到您的数据存储。或者，您执行了 API 调用来获取一些资源。但是，该资源丢失了，您只需要一些额外的时间来引用该资源。这可能是大多数最终一致的分布式系统的常见原因。如您所见，由于立即重试，您的消费者可以从这些类型的错误中恢复过来。
2. 冷重试：这种类型的重试策略是指您需要一些时间（可能超过几秒钟）才能解决根本原因的方式。例如，假设您的 MySQL 集群中有很高的复制延迟。您的消费者无法从副本中获取必要的记录。因此，您的消费者将失败，直到复制完成。在这种情况下，您将需要一个冷重试机制并以某种方式延迟您的主题以在解决时刻重试它