【博学谷学习记录】超强总结，用心分享|狂野架构kafka概述

概述

Kafk定义

传统上定义是一个分布式的基于发布/订阅模式的消息队列，主要应用在大数据实时处理场景，现在Kafka已经定义为一个分布式流平台，用于数据通道处理，数据流分析，数据集成和关键任务应用

Kafka历史

Kafka最初是由LinkedIn公司采用Scala语言开发，基于ZooKeeper，现在已经捐献给了Apache基金会，目前Kafka已经定位为一个分布式流式处理平台，它以高吞吐、可持久化、可水平扩展、支持流处理等多种特性而被广泛应用。

Kafka特性

多个生产者和多个消费者

Kafak可以无缝的支持多个生产者，也支持多个消费者从一个单独的消息流中读取数据，且各个消费者之间互不影响

可持久化操作

Kafka还允许消费者非实时读取消息，因为Kafka将消息按一定顺序持久化到磁盘，保证了数据不会丢失，顺序写磁盘的效率比随机写内存还要高，而且以时间复杂度为O(1)的方式提供消息持久化能力，对TB级以上的数据也能保证常数时间的访问性能。

高吞吐量

Kafka基于发布/订阅模式提供了高吞吐量，Kafka每秒可以生产25万消息，处理55万消息

可伸缩性

Kafka设计为具有灵活伸缩性的分布式系统，易于向外扩展，对在线的集群进行扩展丝毫不会影响到整体系统的可用性。

实时性

由于Kafka可横向扩展生产者、消费者、broker，使得集群可以轻松处理巨大的消息流，在处理大量数据的同时，还能保证亚秒级的消息延迟，实时性极高。

容错性

Kafka消息都会在集群中进行备份，每个分区都有一台server作为leader，其他server作为follwers，当leader宕机了，follower中的一台server会自动成为新的leader，继续有条不紊的工作，所以容错性很高且集群的负载是平衡的。

Kafka应用场景

Apache Kafka能够支撑海量数据的数据传递，在离线和实时的消息处理业务系统中，Kafka都有广泛的应用

消息处理

kafka更好的替换传统的消息系统，消息系统被用于各种场景，与大多数消息系统比较kafka有更好的吞吐量内置分区，副本和故障转移，这有利于处理大规模的消息。

根据我们的经验消息往往用于较低的吞吐量，但需要低的端到端延迟并需要提供强大的耐用性的保证，在这一领域的kafka比得上传统的消息系统，如ActiveMQ或RabbitMQ等。

网站活动追踪

kafka原本的使用场景是用户的活动追踪，网站的活动（网页游览，搜索或其他用户的操作信息）发布到不同的话题中心，这些消息可实时处理实时监测也可加载到Hadoop或离线处理数据仓库。

指标分析

kafka也常常用于监测数据，分布式应用程序生成的统计数据集中聚合。

日志聚合

许多人使用Kafka作为日志聚合解决方案的替代品，日志聚合通常从服务器中收集物理日志文件，并将它们放在中央位置（可能是文件服务器或HDFS）进行处理。Kafka抽象出文件的细节，并将日志或事件数据更清晰地抽象为消息流。这允许更低延迟的处理并更容易支持多个数据源和分布式数据消费。

流处理

kafka中消息处理一般包含多个阶段，其中原始输入数据是从kafka主题消费的，然后汇总，丰富，或者以其他的方式处理转化为新主题，例如，一个推荐新闻文章，文章内容可能从“articles”主题获取；然后进一步处理内容，得到一个处理后的新内容，最后推荐给用户。这种处理是基于单个主题的实时数据流。从0.10.0.0开始，轻量，但功能强大的流处理，就可以这样进行数据处理了，除了Kafka Streams还有ApacheStorm和Apache Samza可选择。

事件采集

事件采集是一种应用程序的设计风格，其中状态的变化根据时间的顺序记录下来，kafka支持这种非常大的存储日志数据的场景。

Kafka架构

先来看一张图，下面这张图就是 kafka 生产与消费的核心架构模型！

如下图，一个kafka架构包括若干个Producer（服务器日志、业务数据、web前端产生的page view等），若干个Broker（kafka支持水平扩展，一般broker数量越多集群的吞吐量越大），若干个consumer group，一个Zookeeper集群（kafka通过Zookeeper管理集群配置、选举leader、consumer group发生变化时进行rebalance）