Kafka 权威指南 (10):初识 Kafka 1.5& 1.5.1

阅读数:12 2019 年 11 月 24 日 22:17

Kafka权威指南(10):初识 Kafka 1.5& 1.5.1

(起源故事)

内容简介
本书是关于 Kafka 的全面教程,主要内容包括:Kafka 相对于其他消息队列系统的优点,主要是它如何完美匹配大数据平台开发;详解 Kafka 内部设计;用 Kafka 构建应用的 zuijia 实践;理解在生产中部署 Kafka 的 zuijia 方式;如何确保 Kafka 集群的安全。

Kafka 是为了解决 LinkedIn 数据管道问题应运而生的。它的设计目的是提供一个高性能的消息系统,可以处理多种数据类型,并能够实时提供纯净且结构化的用户活动数据和系统度量指标。

数据为我们所做的每一件事提供了动力。
——Jeff Weiner,LinkedIn CEO


(LinkedIn 的问题)

本章开头提到过,LinkedIn 有一个数据收集系统和应用程序指标,它使用自定义的收集器和一些开源工具来保存和展示内部数据。除了跟踪 CPU 使用率和应用性能这些一般性指标外,LinkedIn 还有一个比较复杂的用户请求跟踪功能。它使用了监控系统,可以跟踪单个用户的请求是如何在内部应用间传播的。不过监控系统存在很多不足。它使用的是轮询拉取度量指标的方式,指标之间的时间间隔较长,而且没有自助服务能力。它使用起来不太方便,很多简单的任务需要人工介入才能完成,而且一致性较差,同一个度量指标的名字在不同系统里的叫法不一样。

与此同时,我们还创建了另一个用于收集用户活动信息的系统。这是一个 HTTP 服务,前端的服务器会定期连接进来,在上面发布一些消息(XML 格式)。这些消息文件被转移到线下进行解析和校对。同样,这个系统也存在很多不足。XML 文件的格式无法保持一致,而且解析 XML 文件非常耗费计算资源。要想更改所创建的活动类型,需要在前端应用和离线处理程序之间做大量的协调工作。即使是这样,在更改数据结构时,仍然经常出现系统崩溃现象。而且批处理时间以小时计算,无法用它完成实时的任务。

监控和用户活动跟踪无法使用同一个后端服务。监控服务太过笨重,数据格式不适用于活动跟踪,而且无法在活动跟踪中使用轮询拉取模型。另一方面,把跟踪服务用在度量指标上也过于脆弱,批处理模型不适用于实时的监控和告警。不过,好在数据间存在很多共性,信息(比如特定类型的用户活动对应用程序性能的影响)之间的关联度还是很高的。特定类型用户活动数量的下降说明相关应用程序存在问题,不过批处理的长时间延迟意味着无法对这类问题作出及时的反馈。

最开始,我们调研了一些现成的开源解决方案,希望能够找到一个系统,可以实时访问数据,并通过横向扩展来处理大量的消息。我们使用 ActiveMQ 创建了一个原型系统,但它当时还无法满足横向扩展的需求。LinkedIn 不得不使用这种脆弱的解决方案,虽然 ActiveMQ 有很多缺陷会导致 broker 暂停服务。客户端的连接因此被阻塞,处理用户请求的能力也受到影响。于是我们最后决定构建自己的基础设施。

Kafka权威指南(10):初识 Kafka 1.5& 1.5.1

图灵地址 https://www.ituring.com.cn/book/2067

评论

发布