LinkedIn —— Apache Kafka 的伸缩扩展能力

什么是Kafka? Apache Kafka是一个演进的发布/订阅消息系统。系统结合队列和消息机制,可把它当成在一群服务器间进行的日志提交过程。消息被分成多个主题和分段,每个主题支持多个发布者(生产者)和多个订阅者(消费者)。Kafka群以良好的形式为每一个主题保存着这些消息。

  • 对于特定的时间(LinkedIn在数天内测量)
  • 对于分成段的特定大小的消息
  • 基于键的消息,仅存储最近的消息

Kafka提供可靠性、灵活性和盈余保留,同时高吞吐量地处理数据。 已有多篇关于Kafka的文章和讨论,包括talk given at Apache Con2014 byClar kHaskins和我自己的。如果你还不熟悉Kafka,你可能需要去查看这些链接来学习一些Kafka的基本操作原理。 多大算大? Kafka是不关心消息中的内容的。许多不同类型的数据可以在一样的集群上被简单的共存,每一种的数据会被分类成不同的主题。生产者和消费者仅仅需要关心他们感兴趣的内容。LinkedIn让这更进一步,并且定义了四种类别的消息:队列,度量,日志和追踪数据,每一类都运行在他们自己的集群上。 当联合时,在LinkedIn的Kafka的系统上,每天有超过8000亿条消息被发送,相当于超过175兆兆字节(terabytes)数据,另外,每天还会消耗掉650兆兆字节(terabytes)数据的消息,为什么Kafka有这样的能力去处理这么多产生的数据和消耗掉的数据,对每一种消息分类是一个重要原因。在每天系统最繁忙的时候,我们每秒接收超过1300万条消息,相当于每秒2.75GB数据。去处理这所有的信息,LinkedIn运行超过60个集群,并在上面部署超过1100个Kafka代理。 队列 队列是大多数人所想的那种标准信息类型:一个应用的部分生成消息,另一部分消费消息。其它应用对这些消息不感兴趣,因为他们是用于协调动作或是单个系统的状态的。这种类型的消息用于发送邮件,分发由其他在线应用计算出的数据集,或者与后端组件配合工作。 度量 度量处理所有由应用操作产生的测量结果。这包括面向应用的所有操作系统和硬件的统计数据,只要这些数据能够确保系统正确运作。这是LinkedIn的耳目,用它能够看到所有服务器和应用的状态,从而驱动我们内部的监测预警系统。如果你想要对我们的度量了解更多,可以阅读我们的自动度量系统的原始设计,也可以看Stephen Bisordi最近发表的自动度量的下一步往哪走。 日志包括应用程序、系统和公共访问日志。最初,为了方便,度量和日志共存于同一集群。现在由于日志量太大我们会不断地将日志数据分离出来。日志数据通过应用程序产生到Kafka,然后会被其他系统读取用以日志聚合。 跟踪 跟踪包括了LinkedIn的基础架构前线中发生的所有行为,不管是的用户的还是应用程序的。这些行为不仅需要与其他应用程序交互也会进入到Apache Samza的流处理和Apache Hadoop的批处理中。这正是大数据的立足之处:持续更新搜索索引,跟踪付费服务的使用以及实时测量大规模增长的趋势。这四种类型的消息机制对LinkedIn的正常运行至关重要,而跟踪数据则较为常见,因为执行层比较重视而且通常可以带来效益。 分层和聚合 与所有大型网站一样,LinkedIn需要管理大量的数据中心。一些应用,例如那些服务于特定的用户请求的应用,它们只需要关心在一个数据中心发生了什么。还有许多其它应用,例如那些维持搜索目录的应用,它们需要检查所有的数据中心发生了什么。 对于每个消息目录,LinkedIn具有一个创建在数据中心的名为本地消息容器的集群。它同样也是一个聚合集群,它将所有的本地集群的消息整合到一个给定的目录。我们使用Kafka镜像生成器应用来将本地消息复制聚合,这样可以避免任何的本地集群之间的消息循环。

图1:Kafka分层架构设计 使用Kafka基础架构来移动数据可以减少带宽消耗和网络延迟,因为它可以让我们的消息复制次数最小化(每个数据中心一次)。用户可以在当地使用数据,这样就简化他们的配置并且让他们不需要再关心多种跨数据中心的网络问题。生产者和用户完成了Kafka基础架构中的分层概念。生产者是第一层,本地集群(结合所有的数据中心)是第二层,每个聚合集群都是一个额外的层级。用户本身是最后一层。 这种分层的基础架构解决了许多问题,但是极大地复杂化了Kafka的监控和确保它的正常运行。因为一个单一的Kafka集群正常运行时,是不会丢失消息的,当引入了额外的层之后,伴随着额外的组件加入,例如镜像生成器,当消息消失的时候会生成无数的故障,另外监视Kafka集群和它们的状况,我们需要一个中间层来确保所有生成的消息都出现每一层,并且使它成为这些数据的关键用户。 审计完整性 Kafka Audit是LinkedIn的一个内部工具,这个工具用来确保所有生产的消息无丢失的复制到每一层。消息结构包含一个所有消息共有的包含关键数据的头部,关键数据包括时间戳、生产服务和原始主机。当单个生产者发送消息到Kafka的时候,它会记录当前时间间隔发送消息的数量。然后它周期性的发送这个数量到特定的审计主题(topic)。这就提供了每个生产者向某个主题尝试发送消息量的信息。 我们的Kafka基础设施应用之一,被称做Kafka Console Auditor,消费单个Kafka集群中所有主题的所有消息。它周期性的发送消息到审计主题,统计上一个时间间隔该集群中每个主题消费的消息量。通过比较这些数量和生产者的数量,我们就可以判断是否所有的生产的消息已经进入Kakfa系统。如果数量对不上,我们就能知道某个生产者有问题,然后就可以追踪故障的服务和主机。每个Kafka集群有自己的console auditor,用于验证集群中的消息。通过互相比较每一层的数量,我们可以保证每一层具有相同数量的消息。这就可以保证既没有丢失也没用重复消息,如果有问题就能直接采取行动。

图2:Kafka消息审计概况 某些关键的消息消费者,比如Hadoop grids,也做为单独一层回写审计信息。这使得我们不仅可以监控生产者是否在工作,Kafka是否在传递消息,也可以检验消费者是否收到了所有消息。如果应用将消息从Kafka复制到hadoop出现了问题,那么Kafka审计工具将会显示一个错误,标明Hadoop使用的那一层的名字。这最后一块功能给我们提供了端到端的保证,也就是每条生产的数据最终会被消费。 将所有内容组合在一起 简单的Kafka集群上面的这些层看起来很复杂——这给我们提出一个艰巨的任务,如何使LinkedIn的所有应用以相同的方式工作——但是我们有秘密王牌。LinkedIn有一个Kafka工程师团队,其中包括一些顶级的开源Kafka开发者。他们为LinkedIn开发社区提供内部支持,帮助内部团队以一致的、可维护的方式使用Kafka。对于任何想要知道如何实现生产者、消费者,或者深入了解Kafka的特定设计问题的人,他们是共同的交流沟通的团队。 Kafka开发团队也为LinkedIn提供了其他好处,也就是在开源Kafka库之上的一系列自定义库,这些库可以将额外的功能连接在一起。例如,LinkedIn内部的几乎所有Kafka消息生产者都使用了一个称为Tracker Producer的库。当应用调用该库发送消息的时候,这个库将会插入消息头部字段、注册消息结构,同时跟踪、发送审计消息。同样的,消费者库将会从注册服务拉取消息结构信息,反序列化Avro消息。大部分Kafka基础设施应用,比如console auditor,也由该开发团队维护。

图3:LinkedIn内部的Kafka即服务 展望 就像MammadZadeh,我们的技术总监,最近说的,LinkedIn对于Kafka的承诺如故。工程师团队在Kafka开源社区非常活跃。其中的工作包括强安全控制、配额控制,确保LinkedIn能够扩展到每天1万亿条消息,乃至更多。我们基于Kafka之上构建的流处理框架,Samza,最近已完成孵化,成为顶级项目。 SRE团队正与工程师们一起工作,确保我们资深的运营经验可以与开发者的代码经验保持同步。SRE团队也在持续自动化运行Kafka的流程,为诸如移动分片(partition)等任务构建工具,这将会集成到Kafka的组件中。我们也在持续的评估大规模运行Kafka的最佳调优策略,将我们的发现尽可能的告诉社区。 我们在ApacheKafka的邮件列表也很活跃,LinkedIn很荣幸的主持着ApacheKafka Meetup和Bay Area Samza Meetup,交替着每月一次。亲自参与会议,或者远程参加会议,来发现更多关于LinkedIn和其他公司使用Kafka和Samza的信息吧!

原文发布于微信公众号 - 马哥Linux运维(magedu-Linux)

原文发表时间:2015-04-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏社区的朋友们

浅聊 API 网关

在微服务概念流行之前,API 网关的就已经诞生了,如银行、证劵等领域常见的前置机系统,解决访问认证、报文转换、访问统计等;而我今天的切入点是从 API-cent...

1.6K2
来自专栏运维一切

大批量散装文件的迁移 原

有幸我遇到这样一个数据迁移场景: 有很多小文件散落到在不同的文件夹,我需要将这些小文件按照一定的规则找出来,然后将他转移到另外的一个文件系统。如果看到这个可能...

1104
来自专栏搜云库

分布式和集群区别?什么是云计算平台?分布式的应用场景?

分布式是指将一个业务拆分不同的子业务,分布在不同的机器上执行,集群是指多台服务器集中在一起,实现同一业务,可以视为一台计算机,一个云计算平台,就是通过一套软件系...

1.1K10
来自专栏编程软文

小程序二维码和小程序带参数二维码生成

1.3K4
来自专栏搜云库

分布式和集群区别?什么是云计算平台?分布式的应用场景?

分布式是指将一个业务拆分不同的子业务,分布在不同的机器上执行,集群是指多台服务器集中在一起,实现同一业务,可以视为一台计算机,一个云计算平台,就是通过一套软件系...

2845
来自专栏lestat's blog

SoapClient的一点总结

近期在开发一个小型的酒店订房系统 ---- 应用场景:由于是在公司之前一个订房系统基础上进行修改,因此工作量不算大,但需要在系统中多个位置和酒店方提供的另一个...

3004
来自专栏java一日一条

浅析数据一致性

在数据有多分副本的情况下,如果网络、服务器或者软件出现故障,会导致部分副本写入成功,部分副本写入失败。这就造成各个副本之间的数据不一致,数据内容冲突。 实践中,...

5861
来自专栏带你撸出一手好代码

让程序的性能提升10倍

公司有一个Web Service,访问量不大, 但也不算小, 每天几百万的量级。正常情况下, 平均每个请求响应的时间在200毫秒左右。 每天几百万的访问量, 那...

3778
来自专栏北京马哥教育

榨干python性能之服务优化

初看这个标题,相信很多同学都笑了,python有性能可言么,呵呵哒...确实哦,python其实就是为了快速开发应用而出生的,虽然python的服务都以性能低...

3515
来自专栏杨建荣的学习笔记

最近的几个技术问题总结和答疑(八)(r9笔记第82天)

今天的技术问答是刘晨兄的一个问题,提问来自于我新书中的一个实验,刘晨兄非常认真,对我书中的很多细节都进行了测试。 ? 看到这个错误,如果出现end-of-f...

3597

扫码关注云+社区

领取腾讯云代金券