通过Kafka的快速入门 https://www.cnblogs.com/tree1123/p/11150927.html
能了解到Kafka的基本部署,使用,但他和其他的消息中间件有什么不同呢?
Kafka的基本原理,术语,版本等等都是怎么样的?到底什么是Kafka呢?
一、Kafka简介
http://kafka.apache.org/intro
2011年,LinkIn开源, November 1, 2017 1.0版本发布 July 30, 2018 2.0版本发布
参考官网的图:
Kafka®用于构建实时数据管道和流式应用程序。它具有水平可扩展性、容错性、速度极快,并在数千家公司投入生产。
kafka官网最新的定义:Apache Kafka® is a distributed streaming platform
也就是分布式流式平台。
介绍:
三个特点:
- Publish and subscribe to streams of records, similar to a message queue or enterprise messaging system.
- Store streams of records in a fault-tolerant durable way.
- Process streams of records as they occur.
消息 持久化 流处理
两类应用:
-
Building real-time streaming data pipelines that reliably get data between systems or applications
-
Building real-time streaming applications that transform or react to the streams of data
实时流数据管道 实时流应用程序
几个概念
-
Kafka is run as a cluster on one or more servers that can span multiple datacenters.
-
The Kafka cluster stores streams of records in categories called topics.
- Each record consists of a key, a value, and a timestamp
集群 topic record
四个核心api
- The Producer API allows an application to publish a stream of records to one or more Kafka topics.
- The Consumer API allows an application to subscribe to one or more topics and process the stream of records produced to them.
- The Streams API allows an application to act as a stream processor, consuming an input stream from one or more topics and producing an output stream to one or more output topics, effectively transforming the input streams to output streams.
- The Connector API allows building and running reusable producers or consumers that connect Kafka topics to existing applications or data systems. For example, a connector to a relational database might capture every change to a table.
Producer API Consumer API Streams API Connector API
-
客户端服务器通过tcp协议 支持多种语言
主题和日志
一个主题可以有零个,一个或多个消费者订阅写入它的数据
对于每个主题,Kafka群集都维护一个分区日志
每个分区都是一个有序的,不可变的记录序列,不断附加到结构化的提交日志中。
分区中的记录每个都被分配一个称为偏移的顺序ID号,它唯一地标识分区中的每个记录。
Kafka集群持久地保留所有已发布的记录 - 无论它们是否已被消耗 - 使用可配置的保留期。可以配置这个时间。
Kafka的性能在数据大小方面实际上是恒定的,因此长时间存储数据不是问题。
每个消费者保留的唯一元数据是该消费者在日志中的偏移或位置。
这种偏移由消费者控制:通常消费者在读取记录时会线性地提高其偏移量,但事实上,由于消费者控制位置,它可以按照自己喜欢的任何顺序消费记录。例如,消费者可以重置为较旧的偏移量以重新处理过去的数据,或者跳到最近的记录并从“现在”开始消费。
这使得消费者特别容易使用。
生产者:
生产者将数据发布到他们选择的主题。
为了负载均衡,可以选择多个分区。
消费者:
消费者组
传统的消息队列 发布订阅 都有弊端
队列可以扩展但不是多用户,发布订阅每条消费发给每个消费者,无法扩展。
但是kafka这个模式 解决了这些问题
kafka确保使用者是该分区的唯一读者并按顺序使用数据,由于有许多分区,这仍然可以
平衡许多消费者实例的负载。
作为存储系统
作为流处理系统
二、常见使用
http://kafka.apache.org/uses
消息
Kafka可以替代更传统的消息代理。消息代理的使用有多种原因(将处理与数据生成器分离,缓冲未处理的消息等)。与大多数消息传递系统相比,Kafka具有更好的吞吐量,内置分区,复制和容错功能,这使其成为大规模消息处理应用程序的理想解决方案。
根据我们的经验,消息传递的使用通常相对较低,但可能需要较低的端到端延迟,并且通常取决于Kafka提供的强大的耐用性保证。
在这个领域,Kafka可与传统的消息传递系统(如ActiveMQ或 RabbitMQ)相媲美。
网站活动跟踪
站点活动(页面查看,搜索或用户可能采取的其他操作)发布到中心主题,每个活动类型包含一个主题。实时处理,实时监控以及加载到Hadoop或离线数据仓库系统以进行离线处理和报告。
度量
Kafka通常用于运营监控数据。
日志聚合
许多人使用Kafka作为日志聚合解决方案的替代品。日志聚合通常从服务器收集物理日志文件,并将它们放在中央位置(可能是文件服务器或HDFS)进行处理。Kafka抽象出文件的细节,并将日志或事件数据更清晰地抽象为消息流。
流处理
从0.10.0.0开始,这是一个轻量级但功能强大的流处理库,名为Kafka Streams
三、官方文档-核心机制
http://kafka.apache.org/documentation/
简介 使用 快速入门 都已经学习过了
生态:这里有一些kafka的生态,各种Connector 可以直接连接数据库 es等等 还可以连接其他的流处理 还有各种管理工具
confluent公司 专门做kafka的生态
https://cwiki.apache.org/confluence/display/KAFKA/Ecosystem
kafka connect stream management
kafka考虑的几个问题:
吞吐量: 用到了page cache 并不是硬盘读写
消息持久化: 这个还是靠他独特的offset设计
负载均衡:分区副本机制
由于应用 零拷贝技术 客户端应用epoll 所以kafka部署在linux上性能更高。
消息:kafka的消息由 key value timestamp组成 消息头里定义了一些压缩 版本号的信息
crc 版本号 属性 时间戳 长度 key长度 key value长度 value
用的是二进制 不用java类
topic和partition:
这是kafka最核心,也是最重要的机制,这个机制让他区别于其他。
offset是指某一个分区的偏移量。
topic partition offset 这三个唯一确定一条消息。
生产者的offset其实就是最新的offset。
消费者的offset是他自己维护的,他可以选择分区最开始,最新,也可以记住他消费到哪了。
消费者数大于分区,就会有消费者空着。 消费者数小于分区,就会均衡消费。
因为kafka的设计是在一个partition上是不允许并发的,所以consumer数不要大于partition数 ,浪费。
如果consumer从多个partition读到数据,不保证数据间的顺序性,kafka只保证在一个partition上数据是有序的,但多个partition,根据你读的顺序会有不同。
增减consumer,broker,partition会导致rebalance,所以rebalance后consumer对应的partition会发生变化 。
消费者组是为了不同组的消费者可以同时消费一个分区的消息。
replica
这是为了防止服务器挂掉。
分为两类 leader replica 和 follow replica
只有 leader replica会响应客户端。
一旦leader replica所在的broker宕机,会选出新的leader。
kafka保证一个partition的多个replica一定不会分配到同一台broker上。
follow与leader实时同步。
ISR
in-sync replica 与leader replica保持同步的replica集合
正常时,所有的replica都在ISR中,但如果响应太慢,就会踢出ISR。之后追上来再加进来。
ISR中至少有一个replica是活着的。
ISR中所有replica都收到消息,这个消息才是已提交状态。
更多实时计算相关技术博文,欢迎关注实时流式计算