Apache Kafka是一个分布式、分区和复制的提交日志服务。它提供了具有独特设计的消息系统功能。如果说数据是高科技的生命线，那么Apache Kafka就是LinkedIn正在使用的循环系统。它使用Kafka在多个系统间移动各种数据，满足服务器快速可靠的海量数据传输需求。 1.什么是阿帕奇卡夫卡？Apache Kafka是一个改进的发布/订阅消息系统。 结合系统队列和消息机制，可以看作是一组服务器之间的日志提交过程。消息被分成多个主题和片段，每个主题支持多个发布者(生产者)和多个订阅者(消费者)。 Kafka group以良好的形式为每个主题保存这些消息。 对于特定时间(由LinkedIn在几天内测量)对于划分为段的特定大小的基于键的消息，仅存储最近的消息Kafka提供了可靠性、灵活性和剩余保留，同时以高吞吐量解决数据。 2.Apache Kafka的机制许多不同类型的数据可以简单地共存于同一个集群中，并且每种数据将被分类到不同的主题中。 生产者和消费者只需要关心自己感兴趣的东西。 LinkedIn更进一步，定义了四类消息:排队、度量、日志和跟踪数据。每个类别都在它们自己的集群上运行。当它们结合在一起时，LinkedIn的Kafka系统上每天发送超过8000亿条消息。相当于超过175太字节的数据，另外每天还会消耗650太字节的数据。为什么卡夫卡有这么大的力量去解决那么多生成和消耗的数据？对每条消息进行分类是一个重要的原因。 在每天系统最忙的时候，我们每秒接收超过1300万条消息，相当于每秒2.75 GB的数据。 为了解决所有这些信息，LinkedIn运行了超过60个集群，并在其上部署了超过1，100个Kafka代理。 2.1.队列队列是大多数人认为的标准信息类型:应该使用的一部分生成消息，另一部分消耗消息。 应该使用对这些消息不感兴趣的其他消息，因为它们用于协调单个系统的动作或状态。 这种类型的消息用于发送邮件，分发由其他在线应用程序计算的数据集，或者与后台组件合作。 2.2.测量度量解决了应该使用的由操作生成的所有测量结果。 这包括应该使用的所有操作系统和硬件的统计数据，只有这些数据才能确保系统的正确运行。 这是LinkedIn的眼睛和耳朵，可以用来看到所有的服务器和应该使用的状态，从而驱动我们内部的监控和预警系统。 如果你想更多地了解我们的测量，你可以阅读我们的自动测量系统的原始设计，也可以阅读斯蒂芬·比索迪最近出版的《自动测量的下一步在哪里？ 2.3.日志包括应该使用的程序、系统和公共访问日志。 最初，指标和日志共存于同一集群中。 因为现在日志量太大，所以我们会一直把日志数据分开。 日志数据通过应用程序生成给Kafka，然后会被其他系统读取使用，进行日志聚合。 2.4.跟踪包括所有发生在LinkedIn基础设施一线的行为，无论是对用户还是对程序。 这些行为不仅需要和其他应该使用的程序进行交互，还要进入Apache Samza的流解和Apache Hadoop的批处理解。 这就是大数据的立足点:不断升级搜索索引，跟踪付费服务的使用情况，实时衡量大规模增长的趋势。 这四类消息机制对LinkedIn的正常运行至关重要，而跟踪数据则很常见，因为执行层非常重视它们，通常会带来好处。 3.Apache Kafka的数据架构应该管理大量的数据中心，比如那些服务于特定用户请求的数据中心。他们只需要关心一个数据中心发生了什么。 还有许多其他应该使用的工具，比如那些维护搜索目录的工具。他们需要检查所有数据中心的情况。对于每个消息目录，LinkedIn都有一个名为local message container的集群，这也是一个聚合集群。它将所有本地集群消息集成到给定的目录中。例如，应该使用Kafka镜像生成器来复制和聚合本地消息，这可以避免本地集群之间的任何消息循环。 Kafka分层架构设计使用Kafka基础设施移动数据可以减少带宽消耗和网络延迟，因为它可以最大限度地减少消息复制的次数(每个数据中心一次)。 使用户能够在本地使用数据，从而简化配置并消除他们关心各种跨数据中心网络问题的需要。 生产者和使用者在Kafka基础设施中完成了分层概念。 生产者是第一层，本地集群(合并所有数据中心)是第二层，每个聚合集群是附加层。 让用户自己成为最后一层。 这种分层的基础设施处理了许多问题，但它使Kafka的监控和确保其正常运行变得非常复杂。 由于单个Kafka集群正常运行，因此不会丢失消息。当引入附加层时，随着附加组件(如镜像生成器)的添加，当消息消失时，将会产生大量故障。此外，监视Kafka集群及其状态需要一个中间层，以确保所有生成的消息都出现在每一层中，并使其成为这些数据的关键。用户 4.Apache Kafka Kafka审计的数据完整性是LinkedIn的内部工具。该工具用于确保所有生成的消息数据被无损地复制到每一层。 消息结构包含一个标题，其中包含所有消息共有的关键数据，包括时间戳、生产服务和原始主机。 当单个生产者向Kafka发送消息时，它记录当前时间间隔内发送的消息数量。 然后，它定期将这个数量发送给特定的审计主题。 这提供了关于每个生成器试图发送给一个主题的消息数量的信息。 在一个Kafka集群中消费所有主题的所有消息。 它定期向审核主题发送消息，并统计集群中每个主题在最近一段时间间隔内消耗的消息数量。 通过比较这些数字和生产者的数量，我们可以判断是否所有的生产信息都进入了Kakfa系统。 如果数量不匹配，就可以知道某个生产者有问题，然后就可以追溯出故障的服务和主机。 每个Kafka集群都有自己的控制台审计器，用于验证集群中的消息。 通过比较每一层的数量，我们可以确保每一层都有相同数量的消息。 也就是说，它可以确保没有重复的消息丢失或被使用，如果有问题，您可以采取直接的措施。 一些关键消息，如Hadoop网格，也被用作一个单独的层来写回审计信息。 这样不仅可以监控制作者是否在工作，卡夫卡是否在传递信息，还可以检查消费者是否收到了所有的信息。 如果将消息从Kafka复制到hadoop有问题，Kafka审计工具将显示一个错误，指示Hadoop使用的层的名称。 这最后一项工作可以为我们提供一个端到端的保证，即产生的每一项数据最终都会被消费掉。 5.Apache Kafka的数据组合是如何让所有LinkedIn应用都以相同的方式工作的？所有的卡夫卡图书馆都有一系列的自设库，可以把多余的作品连接在一起。 例如，LinkedIn中几乎所有的Kafka消息生产者都使用一个名为TrackerProducer的库。当使用该库发送消息时，该库将插入消息头字段，注册消息结构，并跟踪和发送审计消息。 同一个消费者库将从注册服务中提取消息结构信息，并反序列化Avro消息。