手机网站
手机网站
阿帕奇卡夫卡是领英基础设施的核心组成部分。它最初是作为一个内部流媒体平台诞生的，后来被开放并被外部世界广泛采用。尽管许多公司和项目都在使用卡夫卡，但他们的数据规模很少达到领英卡夫卡在LinkedIn的软件堆栈中被广泛用于活动跟踪、信息交换、指标收集等LinkedIn拥有100多个Kafka集群，包括4000多个代理，共有100000多个主题和700万个分区。到目前为止，领英的卡夫卡集群每天处理超过7万亿条信息。如此大规模的
处理能力不断给领英的卡夫卡生态系统带来可扩展性和运营挑战为了解决这个问题，LinkedIn定制了一个卡夫卡的版本现在，这个分支是官方开源的，托管在GitHub上。这个分支的版本号和阿帕奇卡夫卡的不同之处在于后缀-li被加在它后面。
在本文中，作者将介绍LinkedIn的Kafka定制版本的更多细节、补丁开发过程、如何将变更发送回上游，以及一些补丁的概况和它们如何发布新版本。
1
领英的卡夫卡生态系统
基于阿帕奇卡夫卡的流媒体生态系统是领英技术体系的关键组成部分这个生态系统包括以下组成部分:
卡夫卡集群；
使用卡夫卡客户端应用程序；非Java客户端的
REST代理；
用于维护Avro模式的模式注册表；
brooklin
https://engineering . LinkedIn . com/blog/2019/brooklin-open-source
for maintenance Cruise control
https://engineering . LinkedIn . com/blog/2017/08/open-sourcing-Kafka-Cruise-control
名为“Bean计数器”的管道审计和使用监视器
领英的卡夫卡生态系统
2
领英的卡夫卡版本分支
如前所述，领英的内部版本分支用于创建部署在领英生产环境中的卡夫卡版本每个版本分支都是从相应的阿帕奇卡夫卡上游分支提取的毕竟，LinkedIn并不想使用Apache Kafka，它只是想保持一个尽可能靠近上游的版本。
因此，领英以两种方式提交补丁
上游优先
首先向上游提交补丁并创建一个KIP如有必要；
向当前LinkedIn版本的分支添加修补程序，或在创建新分支时添加修补程序；
通常适用于低优先级或中优先级版本，因为在加入LinkedIn版本分支之前向上游提交会延长发布时间。
LinkedIn优先于
，首先提交给LinkedIn的版本分支；
试图向上游提交，但应注意，出于各种原因，向上游提交可能不被接受；
通常适用于紧急补丁，因为LinkedIn版本可以在提交后立即发布
除了自己创建的补丁，有时LinkedIn还需要从上游选择一些补丁。因此，LinkedIn的版本包括以下补丁:
Apache Kafka补丁:上游提交的补丁；根据优点选择
补丁:提交到上游后添加当前版本。它们可以是提交给上游的内部补丁或外部补丁。
紧急修复补丁:首先在内部创建，然后提交到上游；
特定于LinkedIn的补丁:不被上游接受的紧急修复补丁，它们可能只被LinkedIn内部使用，或者它们可能试图提交给上游但被开源社区拒绝
换句话说，在分支点过去之后，每个LinkedIn版本都将有两个补丁:首选补丁和紧急修复补丁紧急修复补丁还包括仅在LinkedIn中使用的补丁，并尝试向上游提交。从下图中可以看出，虽然每个提交的修补程序都创建一个内部版本，但发布版本是按需创建的，可能包含多个修补程序
3
开发流程
LinkedIn卡夫卡补丁开发流程的卡夫卡版本分支如下图所示
领英的发展过程这里最关键的一点是选择“上游第一”或“领英第一”补丁开发者应该根据紧急情况仔细做出决定。通常，用于解决生产环境问题的补丁首先被视为紧急修复补丁，除非它们能够被快速提交到上游。带有KIP的功能补丁应首先提交到上游下面的
4
补丁示例
将给出一些有代表性的补丁示例，其中一些已经提交到上游，而另一些仅在LinkedIn中使用
可扩展性的改进
LinkedIn内部有一些大型集群，一个集群可能包含140多个代理和100万个副本由于群集太大，控制器速度变慢，或者控制器因内存压力而出现故障这些问题对生产环境有着严重的影响，也可能导致控制器的连锁故障。LinkedIn提供了一些紧急补丁来解决这些问题，比如使用UpdateMetadataRequest对象来减少控制器的内存使用，避免打印太多日志。
因为单个集群包含大量代理，单个代理的缓慢启动和关闭时间也会导致整个集群的部署延迟严重增加因此，为了确保卡夫卡集群的可用性，在部署期间一次只能关闭一个代理。为了解决这个部署问题，LinkedIn提供了一些补丁来减少代理的启动和关闭时间。
操作的改进
这些补丁主要用于解决卡夫卡的部署问题例如，SRE经常需要删除一个失败的代理，并向集群中添加一个新的代理删除代理时，需要保持相同的数据冗余级别，以确保数据不会丢失。SRE需要首先从失败的代理中删除副本，但实际上很难做到这一点，因为集群已经创建了一个新的主题，新的副本可能会分配给失败的代理。为了解决这个问题，领英引入了一种维护模式进入维护模式后，不会为代理分配新的主题分区或副本。有了这个特性，很容易将一个代理的所有副本迁移到另一个代理，然后完全关闭失败的代理。
直接向上游提交的新功能
最近向上游提交的新功能包括KIP-219、KIP-380、KIP-291和KIP-354
还有一些在最初的Apache Kafka中不存在的新特性:
支持用于计费目的的生产和消费计数。
在创建主题时规定了最小复制因子，以避免由于代理失败而导致的数据丢失
新的失调复位策略可以将消费者的消费失调设置为最新的失调。
5
在创建新版本分支之前，
已经介绍了哪些补丁和功能包含在LinkedIn的Kafka版本分支中。接下来，它将介绍如何创建新版本分支。首先，从Apache Kafka版本分支创建一个新分支，然后将尚未提交到上游的紧急维修合并到以前LinkedIn版本分支的新分支中。下图显示了这个过程:
创建LinkedIn Kafka版本分支
。在此过程中，它将在提交意见中指出是否需要将紧急补丁合并到新的分支中。例如，提交的注释可能包括阿帕奇卡夫卡的标签号，通过它您可以知道补丁是否已经合并到阿帕奇卡夫卡的分支中。此外，Apache Kafka分支的补丁将根据业绩定期合并到当前的LinkedIn Kafka分支。
最后，新版本分支将有一个验证过程LinkedIn使用一个特殊的验证框架，根据真实的生产流量对新版本进行各种测试。已验证的项目包括重新平衡、部署、回退、稳定性和降级。经过验证，新版本可以发布。简而言之，LinkedIn Kafka的每个版本都经过了大规模的性能和正确性测试和验证。
https://engineering . LinkedIn . com/blog/2019/Apache-Kafka-万亿-messages
https://git hub . com/LinkedIn/Kafka
updateMetadataRequest对象:
https://git hub . com/LinkedIn/Kafka/COMMIT/5b 99 a6 ba 639d 12e 32 ba F2 a6 c 73508788 5d 12 b 072一个程序员的“快乐生活”和二叉树视频
会议推荐
人工智能在智能交通物流技术进化
工业级实践中的深入学习，阿里广告
个性化对话机器人建设和实践的最新进展语音场景
NLP技术创新和应用实践人工智能时代大规模生产
金融知识地图在蚂蚁商务探索和平台实践256
