这张图片是作者自己创作的。
基于专家的建议，将“# Intro”直接翻译为“# 介绍”更为贴切，更符合中文的口语习惯，因此最终翻译如下： 《介绍》
注：为保持与原文结构一致，保留了“#”符号。
我花了相当多的时间来学习 Apache Kafka 的概念、理论和架构。从 10,000 英尺高空俯瞰 Kafka 的角度来看，它的架构非常简单：代理包含主题，生产者写入数据，消费者读取数据。即使如此，简单，Kafka 也成为了各种规模公司基础设施的核心部分。
在这周的通讯中，我们将了解创建了Kafka的公司，即LinkedIn，如何运行消息系统来帮助其每天处理7万亿条消息的。（此数据引自2019年的一篇文章。因此，现在的数据应该更大了）
简介如果你对这些统计数据还没有感到印象深刻，这里还有一些数字：
作者自制的图片。
- 100 Kafka集群
- 4000 Kafka代理
- 100,000个主题
- 7,000,000个分区
在 LinkedIn 中，Kafka 被广泛应用；以下是一些大类的主要类别：
作者画的图片。
- 解耦发送端和接收端：应用程序的一部分生成消息，而另一部分则消费这些消息。
- 监控：Kafka作为事件总线接收来自代理的监控指标。LinkedIn在服务器上安装代理来收集应用程序的测量数据，例如CPU使用率和内存使用情况等。
- 日志记录：LinkedIn将应用程序、系统以及公共访问日志发送到Kafka。
- 跟踪：跟踪涉及用户和应用程序的每一个操作。这些数据对于保持搜索索引的最新状态、跟踪付费服务使用情况以及实时衡量增长情况至关重要。LinkedIn使用像Samza这样的流处理系统来处理来自Kafka的动作数据。
领英需要以最可靠和最可扩展的方式运行Kafka，以管理其庞大的数据并支持各种用例。在接下来的部分中，我们将看看领英是如何达成这些目标的。
层级与整合
作者绘制的图片。
像 LinkedIn 这样的大型互联网公司在多个不同的数据中心运行其基础设施。
有些应用程序只关心单个数据中心的事情，而另一些应用程序，例如构建搜索索引，则需要跨多个数据中心操作。
在 LinkedIn 的每个数据中心，针对每个消息类别，都部署了一个本地 Kafka 集群。还有一个聚合 Kafka 集群，它会汇总来自所有本地 Kafka 集群的消息。采用这种策略，生产者和消费者可以无需跨数据中心通信，直接与本地的 Kafka 集群进行交互。
最初，他们使用Kafka Mirror Maker将数据从本地复制到聚合集群。后来，他们遇到了该复制工具的扩展问题，因此转而采用了Brooklin，这是一个内部开发的解决方案，允许数据在不同的数据存储之间进行流式传输。
在读取数据时，LinkedIn 让消费者从同一数据中心的经纪人读取数据。这样做简化了相关的配置，并避免了跨数据中心网络问题。
我们现在可以看到LinkedIn上的Kafka部署层级结构。
- 第一层: 生产者
- 第二层: 本地集群（跨越所有数据中心）
- 更多层级: 聚合集群
- 最终层: 消费者
在多个层级上的操作会引发一个担忧：Kafka的消息在经过多个层级传递后是否完整无损。LinkedIn需要一种审计方式。
审计全面性检查
作者的图片。
Kakfa审计是LinkedIn内部的一个工具，确保消息在多级传递过程中不会丢失。
当生产者向Kafka发送消息时，它会跟踪当前时间段内发送的消息数量。定期，生产者将这个计数作为一条消息发送到一个特殊的审计主题（topic）中。
在消费端，由Kafka控制台审计应用审计到的消费者会从所有主题中消费消息，和其他应用程序的消费者一样。
和生产者一样，审计消费者也会定期向审计话题发送消息，记录他们从每个话题中消费的消息数量。
LinkedIn的工程师会比较生产者端点和审计端点的消息数，检查消息是否已成功发送到Kafka。
如果这些数字不一样，就意味着生产商可能有失误。他们可以追踪到具体的服务端和服务器来解决问题。
跟踪之所以可行，是因为在 LinkedIn 中，Kafka 消息的模式包含一个头部，其中包含元数据，例如时间戳、原始物理服务器和具体的服务名称。
LinkedIn Kafka 发布分支版本LinkedIn维护着自己的内部Kafka版本分支，以便部署其生产环境。
作者自制图片。
这有助于他们利用社区的新功能或热修复，并允许LinkedIn向Apache Kafka的开源贡献。让他们的内部分支接近开源的Kafka发布分支，这不仅帮助他们利用社区的新功能或热修复，还可以使LinkedIn向Apache Kafka的开源贡献。
LinkedIn的工程师从相关的Apache Kafka分支分支创建一个内部发布版本分支；他们把这个分支称为上游分支。
他们在LinkedIn开发的Kafka补丁上有两种不同的提交方式：
这张作者创作的图片。
他们首先在上游做出更改，如果必要，他们会提出一个Kafka改进提案（KIP）。然后，他们会将这些更改挑选到他们当前的LinkedIn发布分支中。这种方法适用于低到中等紧急程度的更改。
- 他们首先将代码提交到内部发布分支，然后再提交到上游分支。这种方法适合在高紧急情况下使用。
保持他们的发布分支与上游分支保持接近是一个双向过程；除了将内部补丁同步更新到上游版本外，他们还需要从上游版本中选择补丁合并到内部版本中。LinkedIn的发布分支中有以下几种补丁类型：
- 来自上游 Kafka 分支直至分支点的所有补丁。
- 分支点之后从上游分支挑选的补丁。
- 首先提交到内部分支的紧急修复补丁，准备日后提交到上游分支。
- 仅存在于内部发布分支中的 LinkedIn 专用补丁。它们曾试图提交至上游分支，但被开源社区拒绝。
以下是LinkedIn Kafka开发工作流程。
领英如何使用Kafka进行开发工作，领英如何每天处理7万亿条消息的Apache Kafka优化 (2019)
如果有新问题：
- 如果该补丁存在于开源的 Apache Kafka 分支中，他们可以从上游分支中挑选出该补丁，或者在下次重新合并时再进行同步。
- 如果该补丁不存在于上游分支中，则尝试同时将其提交到上游和内部版本中。
如果有新功能：
他们会将补丁提交到上游和内部分支。在提交到上游时，如果需要，他们还会提交KIP（如果需要）。
LinkedIn的工程师会根据修复补丁的紧急程度选择Upstream First（上游优先）路径或LinkedIn First（LinkedIn优先）路径。通常，解决生产问题的热修复补丁会优先提交。已批准的KIP的功能补丁应优先提交到上游分支。
最后高效运行能够处理大规模数据的数据基础设施并不是一件简单的事情。仅仅增加更多的机器不能解决所有问题。通过这篇文章，我们了解了 LinkedIn 如何操作 Kafka 来每天处理数万亿的消息：从他们如何在数据中心之间组织 Kafka 集群，如何确保消息的完整性，到最后他们的 Kafka 部署工作流程。
参考信息[1] Todd Palino, [大规模运行Kafka一文](https://engineering.linkedin.com/kafka/running-kafka-scale), (2015)_
Jon Lee,LinkedIn如何定制Apache Kafka处理每天7万亿条消息 （2019年）_
共同学习，写下你的评论
评论加载中...
作者其他优质文章
