如何使用Apache Kafka处理1亿用户的大型应用程序

[复制链接]
作者: 冬致夏陌 | 时间: 2024-4-20 19:49:36 | 其他|
0 52

2002

主题

2002

帖子

6006

积分

研究生

Rank: 9Rank: 9Rank: 9

积分
6006
发表于 2024-4-20 19:49:36| 显示全部楼层 |阅读模式

在大数据和高流量应用程序的世界中,同时处理大量用户是一个巨大的挑战。许多全球最受欢迎的应用程序,服务超过1亿用户,依赖于强大、可扩展的架构来管理数据和请求的洪流。这些架构中的关键参与者是 Apache Kafka,一个分布式事件流平台,以其高吞吐量、可靠性和可扩展性而闻名。在这篇文章中,我们将探讨大型应用程序如何使用 Apache Kafka 处理1亿用户,重点关注其架构和特性,使这成为可能。

Apache Kafka 是管理大量数据的最受欢迎的平台之一,可以处理数百万用户。例如,

Kafka 被许多公司使用,包括 LinkedInUberNetflix

LinkedIn使用 Kafka 进行消息交换、活动跟踪和日志指标处理,每天跨越100多个 Kafka 集群处理7万亿条消息。

Uber使用 Kafka 交换用户和司机之间的数据。

Netflix使用 Kafka 跟踪超过2.3亿订阅者的活动,包括观看历史、电影喜好和不喜欢,以及您观看的内容。

PhonePe使用 Apache Kafka 每天管理大约1000亿事件。Kafka 被用来构建实时流应用程序和数据管道,这些应用程序和管道处理数据并在系统之间移动数据。Kafka 还作为一个分布式系统运行,可以扩展以处理许多应用程序,并且可以根据需要存储数据。

使用 Kafka 的一些其他公司包括 Uber、Shopify、Spotify、Udemy、LaunchDarkly、Slack、Robinhood 和 CRED。

Kafka 还用于消息传递、指标收集和监控、日志记录、事件源、提交日志和实时分析。

Kafka 像 pub-sub 消息队列一样工作,允许用户发布和订阅消息流。它还处理流处理,动态计算派生数据集和流,而不仅仅是传递消息批次。

Kafka 是构建可靠的事件驱动架构(EDAs)的最可靠解决方案之一,这些架构提供可靠的实时银行服务。EDA 使数据能够在松散耦合的事件消费者和事件生产者之间异步流动。

为了为 Kafka Streams 确定容量大小,您可以监控操作系统的性能计数器,以确定 CPU 或网络是否成为瓶颈。如果 CPU 是瓶颈,您可以通过向应用程序添加更多线程来使用更多 CPU。如果网络是瓶颈,您可以添加另一台机器并在那里运行 Kafka Streams 应用程序的克隆。Kafka Streams 将自动在所有机器上运行的所有任务之间平衡负载。


这里有一些 Kafka 真实世界用例的例子:
社交媒体分析

  • 一个社交媒体平台使用 Kafka Streams 实时处理推文,进行情感分析,并提供带有用户情感、趋势和参与度指标的仪表板。
制造业

  • Kafka 被用于实时监控生产线、设备状态和库存水平。这有助于优化生产效率,减少停机时间,并改善供应链管理。
网站活动跟踪

  • 当您访问一个网站并执行诸如登录、搜索或点击产品等操作时,Kafka 捕获这些事件。然后 Kafka 将消息流发送到基于事件类型的特定主题。
Apache Kafka 在高容量应用程序中的作用
Apache Kafka 旨在处理大规模的实时数据流。它在高容量应用程序中的主要作用是作为数据流处理的支柱,使得能够有效处理每秒数百万条消息。Kafka 的架构允许它无缝地将数据分布在多个服务器(或代理)上,确保高可用性和容错能力。

Apache Kafka 的关键特性:

  • 高吞吐量:Kafka 可以每秒处理数百万条消息,支持高容量数据流,而不会显著降低性能。
  • 可扩展性:Kafka 集群可以在不停机的情况下扩展,以容纳更多生产者、消费者和数据,随着用户基础的增长。
  • 持久性和可靠性:Kafka 确保数据不会丢失,将消息存储在磁盘上,并在集群中复制数据以实现容错。
  • 低延迟:Kafka 优化了低延迟消息传递,这对实时应用程序和服务至关重要。
  • 数据流解耦:生产者和消费者是解耦的,允许独立扩展和演进处理应用程序。
处理1亿用户的架构概览
要处理1亿用户,应用程序必须有一个经过深思熟虑的架构,有效利用 Kafka 的特性。以下是这样一个架构的简化概览:

1. 数据摄取层:
数据摄取层是数据从各种来源进入系统的地方。这可以包括用户互动、应用程序日志、系统指标等。Kafka 在这一层的作用是有效收集和缓冲这些传入的数据,确保它们准备好由下游系统处理。

2. 流处理:
一旦数据进入 Kafka,就可以进行流处理。这涉及到数据流的实时分析和处理,可用于多种目的,如实时分析、监控和触发自动化操作。Kafka Streams 是一个客户端库,用于构建应用程序和微服务,其中输入和输出数据存储在 Kafka 主题中,通常在这一层使用。

3. 数据集成:
Kafka 还促进了数据集成,作为不同系统之间数据流动的中心枢纽。这在微服务架构中至关重要,不同的应用程序组件可能需要有效地通信和共享数据。

4. 可扩展存储:
Kafka 提供了数据流的持久存储,允许应用程序根据需要保留和重新处理大量数据。这对于需要保留历史数据以进行分析或符合监管合规的应用程序尤其重要。

5. 事件驱动架构:
Kafka 使事件驱动架构成为可能,生产者发布事件(消息)而不需要了解消费者的细节。这种解耦使系统具有更大的可扩展性、灵活性和弹性。

在Honeycomb,Apache Kafka 每秒可以处理多少消息?
Honeycomb,轻松超过一百万条消息。

在这一集中,了解 Honeycomb 如何在大规模上使用 Kafka。Liz Fong-Jones(Honeycomb 主要开发倡导者)解释了 Honeycomb 如何管理基于 Kafka 的遥测摄取管道,并扩展 Kafka 集群。

那么 Honeycomb 是什么?Honeycomb 是一个可观测性平台,帮助您可视化、分析和改进云应用程序的质量和性能。他们的数据量在大流行期间增长了10倍,而总拥有成本只增加了20%。

为了帮助理解基准测试,让我快速回顾一下 Kafka 是什么以及它是如何工作的。Kafka 是一个最初在 LinkedIn 构建的分布式消息系统,现在是 Apache 软件基金会 的一部分,并被多家公司 使用。

一般设置非常简单。生产者将记录发送到集群,集群保留这些记录并将它们分发给消费者:


Kafka 中的关键抽象是主题。生产者将他们的记录发布到一个主题,消费者订阅一个或多个主题。Kafka 主题只是一个分片的预写日志。生产者将记录追加到这些日志中,消费者订阅变化。每条记录都是一个键/值对。键用于将记录分配给日志分区(除非发布者直接指定分区)。

这里是一个单一生产者和消费者从两个分区主题读写的简单例子。


这张图片展示了一个生产者进程正在为两个分区追加日志,以及一个消费者正在读取相同的日志。日志中的每条记录都有一个关联的条目编号,我们称之为偏移量(offset)。消费者用这个偏移量来描述其在每个日志中的位置。

这些分区分布在一组机器上,允许一个主题存储的数据量超过任何单一机器的容量。

请注意,与大多数消息系统不同,日志始终是持久的。消息在接收时立即写入文件系统。读取消息后不会删除消息,而是根据一些可配置的服务水平协议(比如几天或一周)保留消息。这允许在数据消费者可能需要重新加载数据的情况下使用。它还使得支持空间高效的发布-订阅成为可能,因为无论有多少消费者,都有一个共享的日志;在传统的消息系统中,通常每个消费者都有一个队列,所以添加一个消费者就会使你的数据大小翻倍。这使得Kafka非常适合于传统消息系统之外的用途,比如作为Hadoop等离线数据系统的管道。这些离线系统可能只在周期性的ETL周期的间隔中加载,或者可能因维护而关闭几个小时,在此期间,如果需要,Kafka能够缓冲甚至TB级别的未消费数据。

Kafka还将其日志复制到多个服务器上以实现容错。与其他消息系统相比,我们复制实现的一个重要架构方面是,复制不是需要复杂配置的附加功能,只用于非常特殊的情况。相反,复制被假定为默认设置:我们将未复制的数据视为特殊情况,复制因子恰好为一。

当生产者发布包含记录偏移量的消息时,会收到确认回执。发布到分区的第一条记录被赋予偏移量0,第二条记录为1,以此类推,按照不断递增的序列。消费者从指定的偏移量位置消费数据,并通过定期提交来保存他们在日志中的位置:保存这个偏移量以防消费者实例崩溃,另一个实例需要从它的位置恢复。

测试设置
对于这些测试,我有六台机器,每台机器的规格如下:


  • 英特尔至强2.5 GHz处理器,六核
  • 六个7200 RPM SATA硬盘
  • 32GB RAM
  • 1Gb以太网
Kafka集群设置在其中三台机器上。六个硬盘直接挂载,没有RAID(JBOD风格)。剩下的三台机器我用于Zookeeper和生成负载。

三台机器的集群并不大,但由于我们只会测试到复制因子为三,这就是我们所需要的。显然,我们总是可以添加更多分区并将数据分散到更多机器上,以水平扩展我们的集群。

这些硬件实际上并不是LinkedIn通常的Kafka硬件。我们的Kafka机器更适合运行Kafka,但与我这次测试的“现成”精神不太一样。相反,我从我们的Hadoop集群中借来了这些,这可能是我们所有持久系统中最便宜的设备。Hadoop的使用模式与Kafka非常相似,所以这样做是合理的。

好的,不多说,以下是结果!

挑战与考虑
虽然Kafka提供了处理1亿用户所需的工具和功能,但还有几个挑战和考虑必须解决:

数据分区和分片:正确的数据分区对于在Kafka集群中平衡负载和实现高吞吐量至关重要。•监控和管理:这种规模的Kafka集群需要复杂的监控和管理,以确保最佳性能并迅速解决任何出现的问题。•安全性:处理数百万用户的敏感数据需要强大的安全措施,包括加密、访问控制和审计。•合规性和数据治理:大规模系统通常必须遵守各种监管要求,需要谨慎的数据治理实践。

结论
Apache Kafka的架构和功能使其成为需要处理1亿或更多用户的应用程序的绝佳选择。通过有效管理高容量数据流,确保可靠性和可扩展性,并支持解耦的事件驱动架构,Kafka使应用程序能够扩展以满足庞大用户基础的需求。然而,在这种规模上利用Kafka也需要仔细的规划、监控和管理,以解决相关挑战并确保系统的弹性和性能。


来源:
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回列表 返回顶部