繁体   English   中英

以降低弹性为代价经济高效地运行 Kafka

[英]Running Kafka cost-effectively at the expense of lower resilience

假设我有一个便宜但不太可靠的数据中心 A,以及一个昂贵但更可靠的数据中心 B。我想以最具成本效益的方式运行 Kafka,即使这意味着冒着数据丢失和/或停机的风险。 我可以在任一数据中心运行任意数量的代理,但请记住,成本需要尽可能低。

对于这种情况,假设如果代理不运行则不会产生任何费用。 还假设生产者/消费者完全可靠地运行而不用担心他们的成本。

我有两个想法如下:

  1. 提供两个完全独立的 Kafka 集群,每个数据中心一个,但让更昂贵的数据中心 (B) 中的集群保持关闭状态。 在检测到 A 中的中断后,启动 B 中的集群。生产者/消费者将具有在集群之间切换的逻辑。
  2. 在 B 中运行 Zookeeper 集群,在 A 中启动代理,在 B 中关闭代理。如果 A 中出现中断,那么 B 中的代理会联机从 A 停止的地方接手。

选项 1 会更便宜,但需要生产者/消费者更加复杂。 选项 2 会更昂贵,但对生产者/消费者的复杂性要求较低。

选项 2 甚至可能吗? 如果 A 中出现中断,是否有任何方法可以让 B 中的代理上线,被选为主题的领导者并让生产者/消费者无缝地开始向他们发送消息? 同样,数据丢失是正常的,切换停机时间也是正常的。 但是无论选择什么,都不需要人工干预。

我可以考虑其他方法吗?

两者都不可行。

主题及其记录对于每个集群都是唯一的。 集群中的任何 Kafka 分区只能存在一个领导分区。

有了这两条信息,示例场景包括:

  • 生产者切换到一个新的集群,并找到新的领导者,直到旧集群回来
  • 即使以上可能立即发生,或者重试次数最少,消费者也有责任从哪里读取? 他们无法在任何时候聚合来自多个bootstrap.servers的数据。
  • 因此,现在您遇到了两个集群始终都需要可用的情况,另一个集群中存在 N 个分区的 N 个消费者线程,以及原始集群中的 M 个线程
  • 同时,生产者重新写入适当的(更便宜的)集群,因此数据可能会乱序,因为您无法控制哪些消费者线程首先处理哪些数据。
  • 只有在您跟踪来自更昂贵的集群消费者的消费者滞后之后,您才能合理地停止这些线程并在所有消费者达到零滞后时关闭该集群

另一件要记住的事情是,主题创建/更新/删除事件不会自动跨集群同步,因此 Kafka Streams 应用程序,尤其是,将无法使用这种方法维护 state。


您可以使用 MirrorMaker 或 Confluent Replicator / Cluster Linking 等工具来帮助完成所有这些,但我个人从未见过客户端故障转移部分处理得很好,尤其是当记录顺序和幂等处理很重要时


最终,这就是可用性区域的用途。 据我了解,云提供商一次丢失多个可用区的可能性非常小。 因此,您需要跨 3 个或更多可用性区域设置一个 Kafka 集群,并为 Kafka 配置“机架感知”以说明其安装位置。

如果您想在不运行时保持目标/被动集群关闭然后启动集群,如果您不需要任何历史记录并且不关心源集群中的消费者滞后差距.. obv 使用视情况而定。

MM2 或任何类型的异步定向复制要求集群始终处于活动状态。

Stretch cluster 并不是真正可行的 2 dc 事物的 b/c,无论是 raft 还是 zk,你都需要第三个 dc,这可能是你最昂贵的选择。

Redpanda 具有将所有日志段卸载到 s3 的能力,然后对它们进行索引以允许它们用于其他集群,因此如果您不断地将日志段的一个副本写入具有 s3 接口的备用 DC 存储阵列,则可能是可口的。 然后,无论何时需要,您只需在目标 dc 中按需启动一个集群并将其指向 object 商店,您就可以立即开始生产并与您的新客户一起消费。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM