暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

【译】腾讯PCG如何使用Apache Kafka每天处理10万亿+消息

循技漫聊2 2020-08-18
430

正文共: 3960字 8

预计阅读时间: 10分钟


原文作者:陈健威                 陈卡恩(Kahn Chen)          舒淇(George Shu)

翻译:进藏人

原文链接:https://www.confluent.io/blog/tencent-kafka-process-10-trillion-messages-per-day/


2020年8月3日


作为世界上最大的互联网平台公司之一,腾讯利用技术丰富用户生活,帮助企业进行数字化升级转型。其拥有的一个广受欢迎的应用程序便是微信,它在全球拥有10多亿活跃用户。平台和内容集团(PCG)负责整合腾讯的互联网、社交和内容平台。PCG推动IP跨平台、多模式开发,整体目标是打造更多元化的优质数字内容体验。自成立以来,许多主要产品——从著名的QQQQ空间、视频、应用商店、新闻和浏览器,到生态系统中相对较新的成员,如直播、动漫和电影——一直在稳固的基础设施和一套基础技术组件之上不断发展。

腾讯PCG的ApacheKafka®


我们系统的中心是连接数据和计算的实时消息传递系统。令人自豪的是,我们围绕Apache Kafka建立了许多重要的数据管道和消息队列。我们的Kafka应用与其他组织类似:我们构建跨地域日志采集的管道、机器学习平台与微服务之间的异步通信。独特的挑战来自如何从多个维度扩展我们的架构,即可扩展性、定制化和SLA。以下是一些值得注意的要求:

  • 工作负载需要密切持续的观察,才能全面掌握复杂应用中的数据动态情况对于一个月活跃用户超过10亿、具有高度季节性和事件性的C互联网环境,产品推广和大规模的试验往往会导致交易量较前一日激增20倍。在高峰期,我们的数据管道需要为单个产品每秒传输400万消息(或64 GB/秒)。因此,我们的运维团队面临着管理和优化总共超过1000个物理节点的集群的挑战。

  • 低延迟和高SLA。随着组织迅速转向利用实时分析来推动业务决策,对数据准确性和及时性的要求变得比以前更加严格。想象一下,当视频消费事件被提供给推荐算法时,或者当发现能够引发大量内容产生的热门趋势时,业务方往往希望数据能够在发布后的几秒钟内便可以使用,并且端到端损失率低至0.01%。

  • 灵活性。现在的实时数据处理架构是组件化和可配置的。因此,消息传递系统需要在不影响性能的情况下处理消费者数量、访问模式和主题分布的频繁更改。我们不能像传统的采集管道那样简单地针对静态拓扑优化系统。


在理想情况下,我们需要一个多租户的、巨大的pub/sub系统来满足所有这些需求。在高峰期,它应该能够可靠地支持每秒数百GB的数据传输。该基础设施的供给应该做到几乎立即可以完成,而不中断现有的工作负载;它还需要容忍单节点和集群故障。考虑到接口问题,我们还希望尽量其兼容Kafka SDK。在触碰到单个Kafka集群的局限性之后,我们向前进行了一系列的技术演进。

Kafka联邦设计


我们选择在Kafka生态系统中开发,因为它的成熟度高、具有丰富的客户端和连接器,以及相较于替代产品的卓越性能。然而,使用Apache Kafka来满足上述要求还存在一些空白。例如,我们发现在频繁使用期间,多个磁盘故障会导致副本不足,甚至会导致集群级别的可靠性问题。此外,扩展集群的容量(即添加broker)需要大量的数据重平衡,通常这会造成数小时的操作延迟。如果没有完全自动化的容量管理,这将极大地限制我们支持大型业务的空间。


鉴于我们决定将最初的增强重点放在可伸缩性和容错性上,我们开始构建一个代理层,该层联邦多个Kafka集群,并向提供者和消费者提供兼容的接口。代理层将逻辑主题呈现给Kafka客户端,并在内部将它们映射到每个Kafka集群中的不同物理主题。在下图中,一个有8个分区(P0-P7)的逻辑主题被分配到两个物理集群,每个集群有4个分区(P0-P3)

逻辑主题的额外抽象层允许我们实现以下所需的行为。首先,我们可以用很少的(重新)同步开销来扩展数据管道的容量。如果达到最大大小的两个集群无法处理预测的峰值容量,我们可以轻松地部署另外两个集群,而无需调整任何现有数据。其次,较小的集群更易于管理容错,因为我们可以细粒度地调配额外容量,并以较低成本重定向流量。最后,在常见的物理集群迁移中,透明代理使得应用程序端无需更改任何代码和配置。我们只需要在旧集群完全导出数据之前将其设置为只读模式,同时将代理与新集群相关联。从逻辑主题的角度来看,这种维护是透明的。

关键组件和工作流


在本节中,我们将更详细地介绍我们构建的新组件以及它们在基本场景中是如何交互的,如下图所示。两个代理服务,一个用于生产者(pproxy),另一个用于消费者(cproxy),其实现了Kafka broker的核心协议。它们还负责将逻辑主题映射到它们的物理主题上。应用程序使用相同的Kafka SDK直接连接到代理,后者与一个broker表现相同


为了处理这组代理broker,我们构建了一个轻量级命名服务来维护客户端ID代理服务器集合之间的关系。SDK将在通信开始时使用客户端ID请求一次代理broker列表。在内部,我们实现的最复杂、最庞大的部分涉及管理联邦集群的元数据,包括主题状态和代理节点的生命周期。我们将Kafka控制器节点的逻辑(如主题元数据)提取到一个单独的服务中,该服务也称为控制器,但它不同于Kafka自己的控制器功能。此服务负责收集物理集群的元数据,构建分区信息逻辑主题,然后将其发布给代理broker

通过一些最常见的操作过程示例,我们可以一窥这些组件与其下面的Kafka集群之间是如何交互的:

  • 逻辑主题元数据获取
       
       
       

1.控制器从配置数据库中读取逻辑主题和物理主题之间的映射关系

2.Controller扫描每个Kafka集群中所有物理主题的元数据。

3.控制器从心跳报文中找到可用的代理服务器列表。

4.控制器构建逻辑主题的元数据。

5.控制器将主题映射和主题元数据都推送到代理broker。

6.将元数据发送到Kafka SDK。

 

  • 集群供给工作流程
       
       

1.提供空集群(集群3)并将其添加到集群1和集群2的现有联邦

2.控制器从配置数据库加载逻辑主题到物理主题的映射。

3.控制器从集群3的物理主题加载元数据。

4.控制器通过合并2的结果来重构元数据,递增版本。

5.Controller将新版本发布给Proxy Broker,客户端刷新后SDK便可以看到。

 

  • 集群退役工作流
       
       
       

1.控制器在配置数据库中将集群(集群1)以只读模式标记为退役。

2.当控制器从数据库获取元数据时,它会获取此状态更改。

3.控制器重建生产者的元数据,从物理集群中移除集群1。

4.控制器将新版本的生产者元数据推送到代理。此时,数据停止写入集群1,而消费端不受影响。

5.当集群中的所有主题都过期时,控制器再次重构消费者元数据,并移除不再有效的物理主题。

6.消费者代理加载新的元数据,现在当新的消费者到达时,它将不再使用集群1,这就完成了退役操作。

实践中的Kafka联邦


在过去的一年里,我们将腾讯PCG中的许多产品陆续迁移以使用Kafka联邦解决方案。除了集群,我们还一直在开发更好的监控和自动化管理工具。我们的设计原则很快就得到了许多关键业务场景的验证,例如实时分析、特征工程等。到目前为止,我们已经部署了几百个大小不一的集群,每天处理总计超过10万亿条的消息。下表总结了我们的典型设置和操作基准。

初始化一个联邦集群的平均时间

10分钟

通过添加一个物理集群来横向扩容一个联邦集群的平均时间

2 分钟

源数据刷新延迟

约1秒

一个逻辑集群的最大物理集群个数

60

每个物理集群的broker数量

10

提供的broker总数

约500

最大集群带宽(CPU约40%)

240 Gb/s

代理开销

与Kafka broker相同


带有代理层的集群联邦设计有两个明显的局限性。首先,逻辑分区的分布对于在生成消息时使用哈希键指定分区的客户端是不透明的。因此,当我们添加新集群时,具有相同键的消息可能会被传递到不同的分区,因此顺序会打乱。事实证明,对于我们的场景这个是没有影响的,原因有二:首先,我们调查了产品团队,发现他们只是偶尔使用键控消息。此外,当他们面临应用程序级别的容错和可伸缩性之间的权衡时,他们通常更喜欢后者,有时会采用一种在更新集群成员时暂时停止产生消息的机制。


另一个更根本的限制是,随着更多的功能需要公开,以及原生Kafka的发展,我们必须频繁地迭代代理broker的接口。这会导致不必要的代码重复,并使整个系统更难管理。将来,我们将探索在Kafka中实现类似的语义,如下一节所述。

下一步


如上所述,腾讯是全球最大的Kafka用户之一,每天处理数万亿条消息。这也意味着,为了支持我们的许多场景,我们已经成功地突破了Kafka的一些界限。我们得知了Kafka社区内部正在进行的一些发展和提议,并发现我们的一些想法,比如抽象出控制器和跨多个控制器的流量分片,与社区正在走向的方向不谋而合。如果我们的联邦解决方案与分层存储(KIP-405)和删除Zookeeper(KIP-500)等新功能集成,我们可能会看到更为显著的好处,我们期待着对已得到验证的方案贡献出来,以帮助腾讯重返社区。

结论

在本文中,我们介绍了为需要高可伸缩性和容错能力的业务用例构建Kafka联邦集群的过程。通过强大的工程解决方案和运维投入,我们正在弥合业务需求和技术能力的差距,以支持腾讯PCG的持续增长。我们的经验使我们对Kafka生态系统重拾信心,并阐明了我们能够如何对其能力进行进一步的扩展。我们将继续沿着这个方向持续发展。

使用Apache Kafka开始构建应用

如果您想了解更多关于Kafka和事件流处理的信息,请访问ConfluentDeveloper资源中心,找到全网最大的入门资源集合,包括端到端Kafka教程、视频、演示、Meetup以及播客等。

 

 



 




文章转载自循技漫聊2,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论