优步的Apache Kafka

优步拥有世界上最大的Apache Kafka部署之一，每天处理万亿兆和多个数据的数据。如图1所示，今天我们将Apache Kafka定位为Uber技术堆栈的基石，并在其顶部构建复杂的生态系统来赋予大量不同的工作流程。These include a pub/sub message bus to pass event data from the rider and driver apps, enabling a streaming analytics platform (e.g. Apache Samza, Apache Flink), streaming database changelogs to the downstream subscribers, and ingesting all sorts of data into Uber’s Apache Hadoop data lake.

在Apache Kafka之上，我们克服了许多挑战，我们克服了在Apache Kafka之上提供可扩展，可靠，性能且易于使用的消息平台。在本文中，我们强调了从集群停机等灾难中恢复的一个挑战，并描述了我们如何在优步构建一个多区域Apache Kafka基础架构。

优步的多区Kafka

提供业务弹性和连续性是优先权优先的优先权。灾难恢复计划是仔细构建的，以最大限度地减少自然和人造灾害，如断电，灾难性软件故障和网络中断的业务影响。我们采用了多区域策略，该策略在地理上分布式数据中心的备份中部署了服务。当一个区域中的物理基础架构不可用时，服务仍然可以从其他地区保持并运行。

我们架构了一个多区域Kafka设置，以提供区域 - 故障转移支持的数据冗余。UPER技术堆栈中的许多服务依赖于Kafka来支持地区级故障转移。这些服务位于Kafka Stream的下游，并在Kafka中假设数据可用可靠。

图2描绘了多区域Kafka的体系结构。有两种类型的群集：生产者在本地发布消息区域集群然后，来自区域集群的消息被复制到汇总群集提供全球视野。为简单起见，图2仅显示了两个区域中的簇。

在每个区域中，生产者始终在本地生产以获得更好的性能，并且在KAFKA集群的不可用时，生产者将失败到另一个地区并产生该区域的区域集群。

此架构中的一个关键块是消息复制。消息从区域群集异步复制到整个区域的聚合群集。我们建造了Ureplicator.，优步的开源解决方案以以强大可靠的方式复制Apache Kafka数据。该系统扩展了Kafka的Mirrormaker的原始设计，专注于极高的可靠性，零数据丢失保证和易于操作。

从多区Kafka集群中消耗

从多区域消耗比生产更复杂。多区域Kafka支持两种类型的全激活度。

积极/主动消耗

常用类型的消费类型是活动/活动的，其中消费者独立地消耗每个区域中的聚合集群中的相同主题。如今，Uber的许多应用程序使用主动活动模式从多区域Kafka中使用，并且不会直接与其他地区的对应物通信。如果区域发生故障，则如果在两个区域中可用并且包含相同的数据，则在另一个区域中切换到另一个区域的对应部分。

例如，图3显示了优步的动态定价服务（即浪涌定价）使用主动活动的Kafka来构建灾难恢复计划。价格是根据附近地区最近历史的旅行事件计算的。所有旅行事件都被发送到Kafka区域群集，然后聚合到聚合群集中。然后在每个区域中，具有大存储空间的复杂的传单作业计算不同区域的定价。接下来，All-Active Service协调区域中的更新服务，并将一个主要区域分配更新。来自主区域的Update服务将定价结果存储在活动/活动数据库中，以便快速查找。

当灾难击中主区域时，活动活动服务将另一个区域分配为主要区域，并且浪涌定价计算将失败到另一个区域。重要的是要注意，传递作业的计算状态太大而无法在区域之间同步复制，因此必须从来自聚合群集的输入消息独立地计算其状态。

练习的关键洞察力是，像Kafka这样提供可靠和多区域可用的基础架构服务，可以大大简化应用程序的业务连续性计划的开发。应用程序可以将其状态存储在基础架构层中，从而使其无状态，留下跨区域的状态管理的复杂性，如区域的同步和复制，到基础架构服务。

活跃/被动消费者

另一个多区域消耗模式是主动/被动的：允许一次只允许一个消费者（由唯一名称标识）从聚合群集一次（即主区域）中的一个聚合群集。多区域Kafka跟踪其在偏移量表示的主要区域中的消耗进度，并将偏移复制到其他区域。因此，在主区域失败时，主动/被动模式允许消费者将其故障转移到另一个区域并恢复其消耗。主动/被动模式常用于有利于诸如支付处理和审计等更强大的服务。

主动/被动模式对区域之间消费者偏移同步构成了关键挑战。当消费者失败到另一个区域时，需要采取抵消以恢复进度。因为优步的许多服务不能接受任何数据丢失，所以消费者无法从高处恢复水印（最新消息），并避免太多积压，消费者可以从低水印（最早的消息）恢复。此外，来自聚合集群的消息可能在从区域集群聚合后变为顺序。由于跨区域复制延迟，从区域群集从区域群集复制到本地聚合群集的消息。结果，聚合集群中的消息的序列可能是不同的。例如，在图4A中，在大约同一时间，在图4a消息A1，A2和B1，B2在大约同一时间发布到区域A和区域B的区域集群，但在两个聚合集群中聚集在它们中的顺序不同。

为了在整个区域管理此类抵消映射，我们在优步开发了一个复杂的偏移管理服务。架构如图5所示。当Ureplicator将消息从源群群复制到目标群集时，它会定期检查从源到目的地的偏移映射。例如，图4B的右侧示出了图4a的左侧的消息复制的存储偏移映射。表的第一行记录了在区域A的偏移1的区域A映射到偏移1中的偏移1（0索引）的消息A2，该偏移1中的偏移群体A.同样地，表记录的其余行4个复制路由中的其他检查站。

偏移管理将这些检查点存储在主动活动数据库中，并且可以使用它们来计算给定的主动被动消费者的偏移映射。同时，偏移同步作业周期性地同步主动被动消费者的两个区域之间的偏移。当一个主动/被动消费者从一个区域转移到另一个区域时，消费者可以采用最新的同步偏移并恢复消耗。

偏移映射算法如下工作：在活动消费者的聚合群集中，它找到了来自每个区域的区域群集的所有最新检查点。然后，对于每个检查点中的源偏移，将检查点查找到另一个区域中的聚合群集。最后，它需要最小的被动区域的聚合群中检查点偏移的偏移量。

In the example of Figure 6, assume the active consumer’s current progress is at offset 6 of message A3 in the aggregate cluster of Region B. According to the checkpointing table on the right, the two most recent checkpoints on the aggregate cluster are A2 at offset 3 (blue) and B4 at offset 5 (red), with the source of offset 1 (blue) in Region A’s regional cluster and offset 3 (red) in Region B’s regional cluster respectively. These source offsets map to the other aggregate cluster in Region A at offset 1 (blue) and offset 7 (red). By the algorithm, the passive consumer (black) shall take the smaller offset of the two, which is offset 1.

图6：a。主动/被动消费者的故障转移示例从一个区域到另一个区域。消息复制的检查点

自成立以来，偏移管理服务对于管理偏移映射一直有价值，而不仅针对消费者从一个区域到另一个区域的故障转移，而且对于我们将在未来的文章中讨论的其他几个密钥用例。

结论

在优步，业务连续性取决于整个服务的有效，不间断的数据流，Apache Kafka在公司的灾难恢复计划中发挥着关键作用。在本文中，我们简要介绍了在灾害罢工时UBER和不同地区的UTER和不同故障策略的整体架构。但是，现在，在我们面前有更具挑战性的工作，目前，解决了可以容忍没有区域故障转移的单一群集灾难的更精细的恢复策略。听起来不错？查看我们的实时数据基础架构开口优步职业如果您有兴趣参与本故事的下一章。