Apache Kafka是什么系统

Apache Kafka是一个分布的、分区的、复制的提交日志服务，它用独一无二的设计，提供了消息系统功可以，假如说数据是高科技的生命线，Apache Kafka 就是 LinkedIn 公司正在用中的循环系统，用 Kafka 在多系统之间搬移各类数据满足服务器快速又可靠的大块数据传输的需求。

1、什么是Apache Kafka？

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

• 对于特定的时间（LinkedIn 在数天内测量）

• 对于分成段的特定大小的消息

• 基于键的消息，仅存储最近的消息

Kafka 提供可靠性、灵活性和盈余保留，同时高吞吐量地解决数据。

2、Apache Kafka的机制

许多不同类型的数据能在一样的集群上被简单的共存，每种数据会被分类成不同的主题。生产者和消费者仅仅需要关心他们感兴趣的内容。LinkedIn让这更进一步，并且定义了四种类别的消息：队列(queuing)，度量(metrics)，日志(logs)和追踪数据(tracking data)，每一类都运行在他们自己的集群上，当把它们合并在一起，在 LinkedIn 的 Kafka 的系统上，每天有超过 8000 亿条消息被发送，相当于超过 175 兆兆字节（terabytes）数据，另外每天还会耗费掉 650 兆兆字节（terabytes）数据的消息，为什么Kafka有这样的可以力去解决这么多产生的数据和耗费掉的数据，对每一种消息分类是一个重要起因。在每天系统最繁忙的时候，我们每秒接收超过 1300 万条消息，相当于每秒 2.75 GB 数据。去解决这所有的信息，LinkedIn 运行超过 60 个集群，并在上面部署超过 1100 个 Kafka 代理商。

2.1、队列

队列 是大多数人所想的那种标准信息类型：应使用的一个部分生成消息，另一部分消费消息。其它应使用对这些消息不感兴趣，由于他们是使用于协调动作或者是单个系统的状态的。这种类型的消息使用于发送邮件，分发由其余在线应使用计算出的数据集，或者者与后台组件配合工作。

2.2、度量

度量 解决所有由应使用操作产生的测量结果。这包括面向应使用的所有操作系统和硬件的统计数据，只需这些数据可以够确保系统正确运作。这是LinkedIn的耳目，使用它可以够看到所有服务器和应使用的状态，从而驱动我们内部的监测预警系统。假如你想要对我们的度量理解更多，能阅读 我们的自动度量系统的原始设计， 也能看Stephen Bisordi最近发表的“自动度量的下一步往哪走”。

2.3、日志

日志包括应使用程序、系统和公共访问日志。最初度量和日志共存于同一集群。现在因为日志量太大我们会不断地将日志数据分离出来。日志数据通过应使用程序产生到Kafka，而后会被其余系统读取使用以日志聚合。

2.4、跟踪

跟踪包括了LinkedIn的基础架构前线中发生的所有行为，不论是使用户的还是应使用程序的。这些行为不仅需要与其余应使用程序交互，也会进入到 Apache Samza的流解决和Apache Hadoop的批解决中。这正是大数据的立足之处：持续升级搜索索引，跟踪付费服务的用以及实时测量大规模增长的趋势。这四种类型的消息机制对LinkedIn的正常运行至关重要，而跟踪数据则较为常见，由于执行层比较重视而且通常能带来效益。

3、Apache Kafka的数据架构

要管理大量的数据中心，例如那些服务于特定使用户请求的应使用，它们只要要关心在一个数据中心发生了什么。还有许多其它应使用，例如那些维持搜索目录的应使用，它们需要检查所有的数据中心发生了什么，对于每个消息目录LinkedIn具备一个创立在数据中心的名为本地消息容器的集群，它同样也是一个聚合集群，它将所有的本地集群的消息整合到一个给定的目录，如用Kafka镜像生成器应使用来将本地消息复制聚合，能避免任何的本地集群之间的消息循环。

Kafka分层架构设计

用Kafka基础架构来移动数据能减少带宽耗费和网络推迟，由于它能让我们的消息复制次数最小化（每个数据中心一次）。使用户能在本地用数据，这样就简化配置并且让他们不需要再关心多种跨数据中心的网络问题。生产者和使用户完成了Kafka基础架构中的分层概念。生产者是第一层，本地集群（结合所有的数据中心）是第二层，每个聚合集群都是一个额外的层级。使用户本身是最后一层。这种分层的基础架构处理了许多问题，但是极大地复杂化了Kafka的监控和确保它的正常运行。由于一个单一的Kafka集群正常运行时，是不会丢失消息的，当引入了额外的层之后，伴随着额外的组件加入，例如镜像生成器，消息消失时会生成无数的故障，另外监视Kafka集群和它们的状况需要一个中间层来确保所有生成的消息都出现每一层，并且使它成为这些数据的关键使用户。

4、Apache Kafka的数据完整性

Kafka Audit 是 LinkedIn 的一个内部工具，这个工具使用来确保所有生产的消息数据无丢失的复制到每一层。消息数据结构包含一个所有消息共有的包含关键数据的头部，关键数据包括时间戳、生产服务和原始主机。当单个生产者发送消息到Kafka的时候，它会记录当前时间间隔发送消息的数量。而后它周期性的发送这个数量到特定的审计主题（topic）。这就提供了每个生产者向某个主题尝试发送消息量的信息。

消费单个 Kafka 集群中所有主题的所有消息。它周期性的发送消息到审计主题，统计上一个时间间隔该集群中每个主题消费的消息量。通过比较这些数量和生产者的数量，我们即可以判断能否所有生产的消息已进入 Kakfa 系统。假如数量对不上，就会可以知道某个生产者有问题，而后即可以追踪故障的服务和主机。每个 Kafka 集群有自己的 console auditor，使用于验证集群中的消息。通过互相比较每一层的数量，我们能保证每一层具备相同数量的消息。这即可以保证既没有丢失也没使用重复消息，假如有问题就可以直接采取行动。

某些关键的消息消比方Hadoop grids，也做为单独一层回写审计信息。这样不仅能监控生产者能否在工作，Kafka能否在传递消息，也能检验消费者能否收到了所有消息。假如应使用将消息从Kafka复制到hadoop出现了问题，那么Kafka审计工具将会显示一个错误，标明Hadoop用的那一层的名字。这最后一块功可以给我们提供了端到端的保证，也就是每条生产的数据最终会被消费。

5、Apache Kafka的数据组合

如何使LinkedIn的所有应使用以相同的方式工作呢， Kafka 库之有的一系列自己设置库，这些库能将额外的功可以连接在一起。如LinkedIn 内部的几乎所有 Kafka 消息生产者都用了一个称为 TrackerProducer 的库，当应使用调使用该库发送消息的时候，这个库将会插入消息头部字段、注册消息结构，同时跟踪、发送审计消息。同样的消费者库将会从注册服务拉取消息结构信息，反序列化 Avro 消息。