Apache kafka 在处理来自Kafka的消息时避免数据丢失

寻找设计我的卡夫卡消费者的最佳方法。基本上，我想看看在有任何数据丢失的情况下，避免数据丢失的最佳方法是什么 处理消息期间出现异常/错误

我的用例如下

a） 我使用服务处理消息的原因是——将来我计划编写一个错误处理器应用程序，该应用程序将在一天结束时运行，它将尝试再次处理失败的消息（不是所有消息，而是由于任何依赖项（如父项缺失）而失败的消息）

b） 我想确保没有消息丢失，因此我会将消息保存到文件中，以防在将消息保存到DB时出现任何问题

c） 在生产环境中，可能会有多个消费者和服务实例在运行，因此，多个应用程序很有可能尝试写入该实例 相同的文件

问题1）写入文件是避免数据丢失的唯一选项吗

Q-2）如果这是唯一的选项，如何确保多个应用程序同时写入同一文件和读取？请在以后考虑错误处理器 在构建时，它可能正在读取来自同一文件的消息，而另一个应用程序正在尝试写入该文件

---

错误处理器-我们的消息来源遵循事件驱动机制，有时依赖事件（例如，某事物的父实体）可能会延迟几天。因此，在这种情况下，我希望我的错误处理器多次处理相同的消息

我以前也遇到过类似的事情。所以，直接进入你的问题：

• 不一定，您可以用一个新主题（比如-

  错误主题

  ）将这些消息发送回卡夫卡。因此，当您的错误处理器准备就绪时，它可以只收听this

  错误主题

  ，并在收到这些消息时使用它们

• 我认为这一问题是针对第一个问题提出的。因此，Kafka可能是一个更好的选择，因为它是为此类问题而设计的，而不是使用一个文件进行写入和读取，并同时打开多个文件句柄

注意：基于我对您的问题领域的有限理解，以下几点只是一些值得思考的问题。因此，您可以选择安全地忽略这一点

<> P>一个值得考虑的问题：<代码>服务组件——您不妨考虑将所有的错误消息发送回卡夫卡，从而合并点4和5。这将使您能够以一致的方式处理所有错误消息，而不是将一些消息放在错误数据库中，另一些放在Kafka中

编辑：根据有关错误处理器要求的附加信息，以下是解决方案设计的图解

我现在故意保留错误处理器的输出摘要，只是为了保持它的通用性

---

我希望这有帮助

如果在写入数据库之前不提交已消费的消息，则在Kafka保留消息时不会丢失任何内容。这样做的折衷是，如果使用者确实提交到数据库，但卡夫卡偏移量提交失败或超时，那么您最终将再次使用记录，并可能在您的服务中处理重复的记录

即使您确实写入了一个文件，也不能保证顺序，除非您在每个分区打开一个文件，并确保所有使用者只在一台机器上运行（因为您在那里保留状态，这是不容错的）。重复数据消除仍然需要处理

---

此外，您可以研究Kafka Connect框架，而不是将自己的消费者写入数据库。为了验证消息，您可以类似地部署Kafka Streams应用程序，将输入主题中的错误消息过滤到要发送到DB

Lalit的主题中，我最初也有类似的想法，但在我的情况下，我不希望错误处理器再次处理所有失败的消息。理想情况下，我的错误处理器会在出现任何由于验证问题/解析错误而失败的消息时向生成应用程序发出警报。它应该重新处理由于依赖性问题而失败的消息（例如，可能是依赖实体从源系统延迟到达）。另外，我希望将来会有很多类似的用例，所以我希望错误处理器是通用的。您是说错误处理器将位于服务组件之后吗？而且，在将每条消息发送到错误处理器之前，都需要经过服务中的处理？如果ERRPR处理器和服务可以并行运行，那么您仍然可以通过使错误处理器成为一个独立的微服务来实现通用功能，该微服务使用该错误主题。如果您计划在将来通读各种错误，那么可以在消息头或分区级别中进行区分，以使错误处理器能够以不同的方式处理它们。我已更新了我的问题，以包括错误处理器的要求。我正在寻找处理错误的最佳选项-我想确保我这边没有遗漏任何信息。不确定移动到数据库或移动到错误主题是最佳选择。如果我们使用错误主题选项，将来，错误处理器可能必须处理来自20多个错误主题的消息；而且，该消息需要处理器多次处理；嗯，你不需要创建20多个主题。相反，您可以在同一主题中编写所有类型的错误。然后，让错误消息具有处理所有错误的逻辑。我认为这将是一个更干净的设计，即服务接收信息，