入门 - 应用场景

uses

本章节介绍几种主流的Apache Kafka的应用场景。关于几个场景实践的概述可以参考这篇博客.

uses_messaging

Kafka可以作为传统信息中间件的替代产品。消息中间件可能因为各种目的被引入到系统之中（解耦生产者和消费、堆积未处理的消息）。对比其他的信息中间件，Kafka的高吞吐量、内建分区、副本、容错等特性，使得它在大规模伸缩性消息处理应用中成为了一个很好的解决方案。

根据我们的在消息系统场景的经验，系统常常需求的吞吐量并不高，但是要求很低的点到点的延迟并且依赖Kafka提供的强有力的持久化功能。

在这个领域Kafka常常被拿来与传统的消息中间件系统进行对比，例如ActiveMQ或者RabbitMQ。

uses_website

Kafka原本的应用场景要求它能重建一个用户活动追踪管线作为一个实时的发布与订阅消息源。意思就是用户在网站上的动作事件（如浏览页面、搜索、或者其它操作）被发布到每个动作对应的中心化Topic上。使得这些数据源能被不同场景的需求订阅到，这些场景包括实时处理、实时监控、导入Hadoop或用于离线处理、报表的离线数据仓库中。

活动追踪通常情况下是非常高频的，因为很多活动消息是由每个用户的页面浏览产生的。

uses_metrics

Kafka常被用来处理操作监控数据。这涉及到聚合统计分布式应用的数据来产生一个中心化的操作数据数据源。

uses_logs

很多人把Kafka用作日志收集服务的替换方案。日志收集基础就是从服务器收集物理日志文件并他们放在统一的地方（文件服务器或者HDFS）存储以便后续处理。Kafka抽象了文件的细节，为日志或者事件数据提供了一个消息流的抽象。这样就可以很好的支持低延迟处理需求、多数据源需求，分布式数据消费需求。与Scribe或Flume其它的日志收集系统相比，Kafka提供了同样优秀的性能，基于副本的更强的持久化保证和更低的点到点的延迟。

uses_streamprocessing

许多Kafka用户是在一个多级组成的处理管道中处理数据的，他们的从Kafka的Topic上消费原始数据，然后对消息进行聚合、丰富、转发到新的Topic用于消费或者转入下一步处理。例如，一个推荐新闻文章的处理管线可能从RSS数据源爬取文章内容，然后将它发布到”articles“ Topic；然后后续的处理器再对文章内容进行规范化、去重，然后将规整的文章内容发布到一个新的Topic上；最后的处理管线可能尝试将这个内容推荐给用户。这样的处理管线通过一个个独立的topic构建起了一个实时数据流图。从0.10.0.0开始，Kafka提供了一个称为 Kafka Streams的轻量级但强大的流处理包来实现如上所述的处理流程。从Kafka Streams开始，Kafka成为了与Apache Storm和Apache Samza
类似的开源流处理工具的新选择。

uses_eventsourcing

事件溯源 Event sourcing是一种将状态变更记录成一个时序队列的应用设计模式。Kafka对海量存储日志数据的支撑使得它可做这种应用非常好的后端支撑。

uses_commitlog

Kafka可以作为分布式系统的外部提交日志服务。这些日志可以用于节点间数据复制和失败阶段的数据重同步过程。Kafka的日志合并 log compaction功能可以很好的支撑这种应用场景。Kafka这种应用和Apache BookKeeper功能相似。