apache-kafka - Apache Kafka 灾难恢复计划

Question

我们有 10 个应用服务器和 3 个 kafka 集群来支持应用消息传递请求。最近我们遇到了一种情况，由于网络问题，kafka 集群出现故障，并且由于所有数据都丢失了，整个应用程序宕机了几个小时。当我在寻找 kafka 灾难恢复计划时，发现我们应该有 -

1. 故障转移到同一数据中心的另一个集群
2. 故障转移到附近数据中心的另一个集群
3. 故障转移到另一个区域数据中心中的另一个集群

由于我们有一些限制来拥有另一个数据中心，所以我们正在考虑采用一种方法 -

1. 所有应用服务器将数据写入文件
2. Filebeat读取文件并推送到kafka

如果在 kafka 端出现问题，数据将在文件中可用并且可以恢复。所以，我的问题是，这种方法好吗？这个架构中有什么重要的问题吗？还有什么建议吗？

标签： apache-kafka

Answer 1

虽然我没有遇到过这样的单 DC 冗余方案，但我可以看到这对某些客户来说可能很有趣。所以这是一个假设的解决方案。

在我看来，将非 Kafka 基础设施作为您的备份解决方案是一个坏主意。你的程序员会在编码时哭泣，因为 API 依赖于大量与 Kafka 相关的元数据来接收来自主题和分区的适当消息。应用程序如何从 Topic-1:Partition:27 中找到它处理的最后一条记录？由于生产者也使用 Kafka API，未来的记录会去哪里。

我将构建一个辅助 Kafka 集群，与带有隔离代理、zookeeper 和磁盘的主集群相比，它更小。使用镜像制造商或复制器 ( https://docs.confluent.io/current/multi-dc-replicator/mirrormaker.html ) 用实际数据填充此集群。您可以降低保留时间以管理磁盘空间等，但它会使您的所有实时应用程序顺利运行。

一旦您的主集群出现故障，应用程序需要使用该集群的代理进行常规处理。

消费者应用程序需要在 Kafka 之外保存偏移量，以便能够简单地从上一个检查点重新启动。生产者应用程序只需要更改代理 ID。如果您想达到该级别，可以在代理或维护 Kafka 连接的独立微服务中对此开关进行编程。