Apache Kafka-初体验Kafka(01)-入门整体认识kafka

简介: Apache Kafka-初体验Kafka(01)-入门整体认识kafka


kafka官方文档

官网: https://kafka.apache.org/

快速开始: https://kafka.apache.org/documentation/#quickstart


Kafka是最初由Linkedin公司开发,是一个分布式支持分区的(partition)多副本的(replica)基于zookeeper协调的分布式消息系统 .

Kafka的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于hadoop的批处理系统、低延迟的实时系统、storm/Spark流式处理引擎,web/nginx日志、访问日志,消息服务等等.

Kafka用scala语言编写,Linkedin于2010年贡献给了Apache基金会并成为顶级开源 项目。


使用场景

  • 日志收集:一个公司可以用Kafka可以收集各种服务的log,通过kafka以统一接口服务的方式开放给各种 consumer,例如hadoop、Hbase、ES等
  • 消息系统:解耦和生产者和消费者、缓存消息等
  • 用户活动跟踪: 记录web用户或者app用户的各种活动,如浏览网页、搜索、点击等活动,这些活动信息被各个服务器发布到kafka的topic中,然后订阅者通过订阅这些topic来做实时的监控分析,或者装载到 hadoop、数据仓库中做离线分析和挖掘
  • 运营指标: 收集各种分布式应用的数据,生产各种操作的集中反 馈,比如报警和报告

我们来看个常见的系统架构图


Kafka基本概念

kafka是一个分布式的,分区的消息(官方称之为 commit log )服务。

它提供一个消息系统应该具备的功能,但是确有着独特的设计,Kafka借鉴了JMS规范的思想,但是确并没有完全遵循JMS规范。


消息( Message )相关术语

首先,我们来看一下基础的消息( Message )相关术语:

名称 说明
Broker 消息中间件处理节点,一个Kafka节点就是一个broker,一个或者多个Broker可以组成一个Kafka集群
Topic Kafka根据topic对消息进行归类,发布到Kafka集群的每条消息都需要指定一个topic
Producer 消息生产者,向Broker发送消息的客户端
Consumer 消息消费者,从Broker读取消息的客户端
ConsumerGroup 每个Consumer属于一个特定的ConsumerGroup,一条消息可以被多个不同的Consumer Group消费,但是一个Consumer Group中只能有一个Consumer能够消费该消息
Partition 物理上的概念,一个topic可以分为多个partition,每个partition内部消息是有序的

因此,从一个较高的层面上来看,producer通过网络发送消息到Kafka集群,然后consumer来进行消费,如下图:

服务端(brokers)和客户端(producer、consumer)之间通信通过TCP协议来完成。


主题Topic & 消息日志Log

让我们首先深入理解Kafka提出一个高层次的抽象概念-Topic。

Topic是一个类别的名称,同类消息发送到同一个Topic下面。对于每一个Topic,下面可以有多个分区(Partition)日志文件.

Partition是一个有序的message序列,这些message按顺序添加到一个叫做commit log的文件中。

每个partition中的消息都有一个唯一的编号,称之为offset,用来唯一标示某个分区中的message。

注:每个partition,都对应一个commit log文件。一个partition中的message的offset都是唯一的,但是不同的partition中的message的offset可能是相同的

可以这么来理解Topic,Partition和Broker:

一个topic,代表逻辑上的一个业务数据集,比如按数据库里不同表的数据操作消息区分放入不同topic,订单相关操作消息放入订单topic,用户相关操作消息放入用户topic.

对于大型网站来说,后端数据都是海量的,订单消息很可能是非常巨量的,比如有几百个G甚至达到TB级别,如果把这么多数据都放在一台机器上可定会有容量限制问题,那么就可以topic内部划分多个partition来分片存储数据,不同的partition可以位于不同的机器上,每台机器上都运行一个Kafka的进程Broker.

kafka集群,在配置的时间范围内,维护所有的由producer生成的消息,而不管这些消息有没有被消费.

例如日志保留(log retention )时间被设置为2天。kafka会维护最近2天生产的所有消息,而2天前的消息会被丢弃。kafka的性能与保留的数据量的大小没有关系,因此保存大量的数据(日志信息)不会有什么影响。

每个consumer是基于自己在commit log中的消费进度(offset)来进行工作的。在kafka中,消费offset由consumer自己来维护;一般情况下我们按照顺序逐条消费commit log中的消息,当然我可以通过指定offset来重复消费某些消息,或者跳过某些消息。

这意味kafka中的consumer对集群的影响是非常小的,添加一个或者减少一个consumer,对于集群或者其他consumer来说,都是没有影响的,因为每个consumer维护各自的offset。所以说kafka集群是无状态的,性能不会因为consumer数量受太多影响。kafka还将很多关键信息记录在zookeeper里,保证自己的无状态,从而在水平扩容时非常方便。

为什么要对Topic下数据进行分区存储?

  1. commit log文件会受到所在机器的文件系统大小的限制,分区之后,理论上一个topic可以处理任意数量的数据。
  2. 为了提高并行度。

分布式Distribution

log的partitions分布在kafka集群中不同的broker上,每个broker可以请求备份其他broker上partition上的数据。kafka集群支持配置一个partition备份的数量。

针对每个partition,都有一个broker起到“ leader ”的作用,0个或多个其他的broker作为“ follwers ”的作用。

leader处理所有的针对这个partition的读写请求,而followers被动复制leader的结果。如果这个leader失效了,其中的一个follower将会自动的变成新的leader。


Producers

生产者将消息发送到topic中去,同时负责选择将message发送到topic的哪一个partition中。通过 round-­robin 做简单的负载均衡。也可以根据消息中的某一个关键字来进行区分。通常第二种方式使用的更多。


Consumers

传统的消息传递模式有2种:队列( queue) 和(publish-subscribe)

  • queue模式:多个consumer从服务器中读取数据,消息只会到达一个consumer。
  • publish-subscribe模式:消息会被广播给所有的consumer。

Kafka基于这2种模式提供了一种consumer的抽象概念: consumer group

  • queue模式:所有的consumer都位于同一个consumer group 下。
  • publish-subscribe模式:所有的consumer都有着自己唯一的consumer group。

图例说明: 由2个broker组成的kafka集群,总共有4个partition(P0-P3)。这个集群由2个Consumer Group, A有2个consumer instances ,B有四个。

可以看到,每个Consumer属于一个特定的ConsumerGroup,一条消息可以被多个不同的Consumer Group消费,但是一个Consumer Group中只能有一个Consumer能够消费该消息 。

通常一个topic会有几个consumer group,每个consumer group都是一个逻辑上的订阅者( logicalsubscriber )。每个consumer group由多个consumer instance组成,从而达到可扩展和容灾的功能。


消费顺序

Kafka比传统的消息系统有着更强的顺序保证。

一个partition同一个时刻在一个consumer group中只有一个consumer instance在消费,从而保证顺序 。 consumer group中的consumer instance的数量不能比一个Topic中的partition的数量多,否则,多出来的consumer消费不到消息。

Kafka只在partition的范围内保证消息消费的局部顺序性,不能在同一个topic中的多个partition中保证总的消费顺序性。

如果有在总体上保证消费顺序的需求,那么我们可以通过将topic的partition数量设置为1,将consumer group中的consumer instance数量也设置为1。

从较高的层面上来说的话,Kafka提供了以下的保证:

  • 发送到一个Topic中的message会按照发送的顺序添加到commit log中。意思是,如果消息 M1,M2由同一个producer发送,M1比M2发送的早的话,那么在commit log中,M1的offset就会比commit 2的offset小。
  • 一个consumer在commit log中可以按照发送顺序来消费message。
  • 如果一个topic的备份因子设置为N,那么Kafka可以容忍N-1个服务器的失败,而存储在commit log中的消息不会丢失。
相关文章
|
1月前
|
消息中间件 存储 大数据
Apache Kafka: 强大消息队列系统的介绍与使用
Apache Kafka: 强大消息队列系统的介绍与使用
|
3月前
|
消息中间件 Kafka Linux
Apache Kafka-初体验Kafka(03)-Centos7下搭建kafka集群
Apache Kafka-初体验Kafka(03)-Centos7下搭建kafka集群
64 0
|
1月前
|
消息中间件 分布式计算 Kafka
SparkStreaming(SparkStreaming概述、入门、Kafka数据源、DStream转换、输出、关闭)
SparkStreaming(SparkStreaming概述、入门、Kafka数据源、DStream转换、输出、关闭)(一)
47 5
|
1月前
|
消息中间件 Java Kafka
Kafka【环境搭建 01】kafka_2.12-2.6.0 单机版安装+参数配置及说明+添加到service服务+开机启动配置+验证+chkconfig配置说明(一篇入门kafka)
【2月更文挑战第19天】Kafka【环境搭建 01】kafka_2.12-2.6.0 单机版安装+参数配置及说明+添加到service服务+开机启动配置+验证+chkconfig配置说明(一篇入门kafka)
46 1
|
3月前
|
分布式计算 Java 大数据
IO流【Java对象的序列化和反序列化、File类在IO中的作用、装饰器模式构建IO流体系、Apache commons-io工具包的使用】(四)-全面详解(学习总结---从入门到深化)
IO流【Java对象的序列化和反序列化、File类在IO中的作用、装饰器模式构建IO流体系、Apache commons-io工具包的使用】(四)-全面详解(学习总结---从入门到深化)
51 0
|
1月前
|
监控 测试技术 Linux
性能工具之 Apache Bench 入门使用
ab 全称为:apache bench,ab 为小型压力工具,对于在 Linux 中简单压测 HTTP 接口轻巧灵活。
20 1
|
1月前
|
SQL 分布式计算 HIVE
Apache Hudi入门指南(含代码示例)
Apache Hudi入门指南(含代码示例)
53 0
|
3月前
|
SQL 关系型数据库 Apache
Apache Doris 整合 FLINK CDC 、Paimon 构建实时湖仓一体的联邦查询入门
Apache Doris 整合 FLINK CDC 、Paimon 构建实时湖仓一体的联邦查询入门
416 1
|
3月前
|
存储 关系型数据库 Apache
Apache Doris 入门 10 问
本文解答了Apache Doris 在读写流程、副本一致性机制、 存储机制、高可用机制等方面的常见疑问点,欢迎订阅。
Apache Doris 入门 10 问
|
3月前
|
消息中间件 Java Kafka
Apache Kafka-初体验Kafka(04)-Java客户端操作Kafka
Apache Kafka-初体验Kafka(04)-Java客户端操作Kafka
29 0

热门文章

最新文章

推荐镜像

更多