3.1、消息系统
Kafka 很好地替代了传统的 message broker（消息代理）。Message Brokers 可用于各种场合（如 将数据生成器与数据处理解耦，缓冲未处理的消息等）。与大多数消息系统相比，Kafka 拥有 更好的吞吐量、内置分区、具有复制和容错的功能，这使它成为一个非常理想的大型消息处 理应用。根据我们的经验，通常消息传递使用较低的吞吐量，但可能要求较低的端到端延迟， Kafka 提供强大的持久性来满足这一要求。在这方面，Kafka 可以与传统的消息传递系统 （ActiveMQ 和 RabbitMQ）相媲美。
3.2、跟踪网站活动
Kafka 的初始用例是将用户活动跟踪管道重建为一组实时发布-订阅源。这意味着网站活动 （浏览网页、搜索或其他的用户操作）将被发布到中心 topic，其中每个活动类型有一个 topic。
这些订阅源提供一系列用例，包括实时处理、实时监视、对加载到 Hadoop 或离线数据仓库 系统的数据进行离线处理和报告等。每个用户浏览网页时都生成了许多活动信息，因此活动 跟踪的数据量通常非常大 。
3.3、运营指标
Kafka 也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集 中反馈，比如报警和报告。
3.4、日志聚合
许多人使用Kafka来替代日志聚合解决方案。日志聚合系统通常从服务器收集物理日志文件， 并将其置于一个中心系统（可能是文件服务器或 HDFS）进行处理。Kafka 从这些日志文件中 提取信息，并将其抽象为一个更加清晰的消息流。这样可以实现更低的延迟处理且易于支持 多个数据源及分布式数据的消耗。与 Scribe 或 Flume 等以日志为中心的系统相比，Kafka 具 备同样出色的性能、更强的耐用性（因为复制功能）和更低的端到端延迟。
3.5、流处理
许多 Kafka 用户通过管道来处理数据，有多个阶段：从 Kafka topic 中消费原始输入数据，然后聚合，修饰或通过其他方式转化为新的 topic，以供进一步消费或处理。 例如，一个推荐 新闻文章的处理管道可以从 RSS 订阅源抓取文章内容并将其发布到“文章”topic; 然后对这 个内容进行标准化或者重复的内容，并将处理完的文章内容发布到新的 topic; 最终它会尝试 将这些内容推荐给用户。 这种处理管道基于各个topic创建实时数据流图。从0.10.0.0开始， 在 Apache Kafka 中，Kafka Streams 可以用来执行上述的数据处理，它是一个轻量但功能强大 的流处理库。除 Kafka Streams 外，可供替代的开源流处理工具还包括 Apache Storm 和 Apache Samza。
3.6、采集日志
Event Sourcing 是一种应用程序设计风格，按时间来记录状态的更改。Kafka 可以存储非常多 的日志数据，为基于 Event Sourcing 的应用程序提供强有力的支持。
3.7、提交日志
Kafka 可以从外部为分布式系统提供日志提交功能。日志有助于记录节点和行为间的数据， 采用重新同步机制可以从失败节点恢复数据。Kafka 的日志压缩功能支持这一用法。这一点 与 Apache BookKeeper 项目类似。