kafka基本概念及操作

这篇具有很好参考价值的文章主要介绍了kafka基本概念及操作。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

kafka介绍

Kafka是最初由Linkedin公司开发,是一个分布式、支持分区的(partition)、多副本的 (replica),基于zookeeper协调的分布式消息系统,它的最大的特性就是可以实时的处理大量数据以满足各种需求场景:比如基于hadoop的批处理系统、低延迟的实时系统、 Storm/Spark流式处理引擎,web/nginx日志、访问日志,消息服务等等,用scala语言编写,Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

1.使用场景

  • 日志收集:可以用Kafka收集各种服务的log,通过kafka以统⼀接口服务的方式开放给各种consumer,例如hadoop、Hbase、Solr等。

  • 消息系统:解耦和生产者和消费者、缓存消息等。

  • 用户活动跟踪:Kafka经常被用来记录web用户或者app用户的各种活动,如浏览网页、 搜索、点击等活动,这些活动信息被各个服务器发布到kafka的topic中,然后订阅者通过订阅这些topic来做实时的监控分析,或者装载到hadoop、数据仓库中做离线分析和挖掘。

  • 运营指标:Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据,生产各种操作的集中反馈,比如报警和报告。

2.kafka基本概念

kafka基本概念及操作,cloud,mq,kafka,分布式

整个流程应该是:producer通过网络发送消息到Kafka集群,然后consumer 来进行消费,如下图:

kafka基本概念及操作,cloud,mq,kafka,分布式

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

kafka基本使用

1.安装&关闭

以下所有操作全部基于kafka_2.13-3.0.1.tgz (3.0.1版本) 这个版本

配置文件server.properties(主要修改以下配置)

#broker.id属性在kafka集群中必须要是唯⼀
broker.id=0
listeners=PLAINTEXT://xx.xx.xx.xx(服务器内网IP地址):9092
advertised.listeners=PLAINTEXT://xx.xx.xx.xx(服务器对外IP地址):9092
#kafka的消息存储⽂件
log.dir=/usr/local/kafka/data/kafka-logs
#kafka连接zookeeper的地址
zookeeper.connect=192.168.65.60:2181

启动

./kafka-server-start.sh -daemon ../config/server.properties

验证

# 查看端口是否占用
netstat -ntlp 

或者

进入到zk内查看是否有kafka的节点:/brokers/ids/0

./zkCli.sh

kafka基本概念及操作,cloud,mq,kafka,分布式

关闭kafka

./kafka-server-stop.sh stop ../config/server.properties

2.创建topic

执行以下命令创建名为“test”的topic,这个topic只有⼀个partition,并且备份因子也设置为 1

./kafka-topics.sh --bootstrap-server kafkahost:9092 --create --topic test --partitions 1 --replication-factor 1

-- 新版本的kafka,已经不需要依赖zookeeper来创建topic,新版的kafka创建topic指令如下:
./kafka-topics.sh --bootstrap-server 124.222.253.33:9092 --create --topic test --partitions 1 --replication-factor 1

3.查看kafka中所有的主题

./kafka-topics.sh --bootstrap-server kafkahost:9092 --list

./kafka-topics.sh --bootstrap-server 124.222.253.33:9092 --list

4.发送消息

kafka自带了⼀个producer命令客户端,可以从本地文件中读取内容或者以命令行中直接输入内容,并将这些内容以消息的形式发送到kafka集群中。在默认情况下,每⼀个行会被当做成⼀个独立的消息。使用kafka的发送消息的客户端,指定发送到的kafka服务器地址和topic

把消息发送给broker中的某个topic,打开⼀个kafka发送消息的客户端,然后开始用客户端向kafka服务器发送消息

./kafka-console-producer.sh --bootstrap-server 124.222.253.33:9092 --topic test

5.消费消息

消费消息两种方式

对于consumer,kafka同样也携带了⼀个命令行客户端,会将获取到内容在命令中进行输出,默认是消费最新的消息。 使用kafka的消费者消息的客户端,从指定kafka服务器的指定 topic中消费消息

  1. 从当前主题中的最后⼀条消息的offset(偏移量位置)+1开始消费

    ./kafka-console-consumer.sh --bootstrap-server 124.222.253.33:9092 --topic test
    
  2. 从当前主题中的第⼀条消息开始消费

    ./kafka-console-consumer.sh --bootstrap-server 124.222.253.33:9092 --from-beginning --topic test
    

6.消息的细节

kafka基本概念及操作,cloud,mq,kafka,分布式

  • 生产者将消息发送给broker,broker会将消息保存在本地的日志文件中
/usr/local/kafka/data/kafka-logs/主题-分区/00000000.log
  • 消息的保存是有序的,通过offset偏移量来描述消息的有序性
  • 消费者消费消息时可以通过offset来描述当前要消费的那条消息的位置

7.单播&多播消息

单播还是多播消息取决于topic有多少消费组

1)单播

如果多个消费者在同⼀个消费组,那么只有⼀个消费者可以收到订阅的topic中的消息。(同⼀个消费组中只能有⼀个消费者收到订阅topic中的消息。)

./kafka-console-consumer.sh --bootstrap-server 124.222.253.33:9092 --consumer-property group.id=testGroup --topic test

2)多播

不同的消费组订阅同⼀个topic,那么不同的消费组中只有⼀个消费者能收到消息。实际上也是多个消费组中的多个消费者收到了同⼀个消息。

./kafka-console-consumer.sh --bootstrap-server 124.222.253.33:9092 --consumer-property group.id=testGroup1 --topic test
./kafka-console-consumer.sh --bootstrap-server 124.222.253.33:9092 --consumer-property group.id=testGroup2 --topic test

3)区别

kafka基本概念及操作,cloud,mq,kafka,分布式

8.查看消费组详细信息

# 查看当前主题下有哪些消费组
./kafka-consumer-groups.sh --bootstrap-server 124.222.253.33:9092 --list

# 查看消费组中的具体信息:⽐如当前偏移量、最后⼀条消息的偏移量、堆积的消息数量
./kafka-consumer-groups.sh --bootstrap-server 124.222.253.33:9092 --describe --group testGroup

kafka基本概念及操作,cloud,mq,kafka,分布式

  • Currennt-offset:当前消费组的已消费偏移量(最后被消费的消息的偏移量)
  • Log-end-offset:主题对应分区消息的结束偏移量(HW) 【消息总量,最后一条消息偏移量】
  • Lag:当前消费组未消费的消息数(积压消息量)

Kafka中主题和分区的概念

1.主题

主题-topic在kafka中是⼀个逻辑的概念,kafka通过topic将消息进⾏分类。不同的topic会被订阅该topic的消费者消费。

但是有⼀个问题,如果说这个topic中的消息非常非常多,多到需要几T来存,因为消息是会被保存到log日志文件中的。为了解决单个文件过大的问题,kafka提出了Partition分区的概念。

2.分区

1)分区的概念

通过partition将⼀个topic中的消息分区来存储。

这样的好处有多个:

  • 分区存储,可以解决统⼀存储文件过大的问题
  • 提高了读写的吞吐量:读和写可以同时在多个分区中进行

kafka基本概念及操作,cloud,mq,kafka,分布式

2)创建多分区的主题

./kafka-topics.sh --bootstrap-server 124.222.253.33:9092 --create --topic test1 --partitions 2 --replication-factor 1

3.kafka中消息日志文件中保存的内容

  • 00000.log: 这个文件中保存的就是消息

  • __consumer_offsets-49:

    kafka内部自己创建了__consumer_offsets主题包含了50个分区。这个主题用来存放消费者消费某个主题的偏移量。因为每个消费者都会自己维护着消费的主题的偏移量,也就是说每个消费者会把消费的主题的偏移量自主上报给kafka中的默认主题:consumer_offsets。因此kafka为了提升这个主题的并发性,默认设置了50个分区(可以通过offsets.topic.num.partitions设置)。

    • 提交到哪个分区:通过hash函数:hash(consumerGroupId) % __consumer_offsets 主题的分区数
    • 提交到该主题中的内容是:key是consumerGroupId+topic+分区号,value就是当前offset的值
  • 文件中保存的消息,默认保存7天。七天到后消息会被删除,最后就保留最新的那条数据。

Kafka集群操作

1.搭建kafka集群(三个broker)

  • 创建三个server.properties文件
# 0 1 2
broker.id=2
# 9092 9093 9094
listeners=PLAINTEXT://xx.xx.xx.xx(服务器内网IP地址):9094
advertised.listeners=PLAINTEXT://xx.xx.xx.xx(服务器对外IP地址):9094
# kafka-logs kafka-logs-1 kafka-logs-2
log.dir=/usr/local/data/kafka-logs-2
  • 通过命令来启动三台broker
./kafka-server-start.sh -daemon ../config/server.properties
./kafka-server-start.sh -daemon ../config/server1.properties
./kafka-server-start.sh -daemon ../config/server2.properties
  • 校验是否启动成功

进入到zk中查看/brokers/ids中过是否有三个znode(0,1,2)

2.副本的概念

在创建主题时,除了指明了主题的分区数以外,还指明了副本数 replication-factor参数

如下主题,创建了两分区、三副本(副本对应集群中broker数量)

./kafka-topics.sh --bootstrap-server 124.222.253.33:9092 --create --topic my-replicated-topic --partitions 2 --replication-factor 3

副本是为了为主题中的分区创建多个备份,多个副本在kafka集群的多个broker中,会有⼀个副本作为leader,其他是follower。

查看topic情况:

# 查看topic情况
./kafka-topics.sh --describe --bootstrap-server 124.222.253.33:9092 --topic my-replicated-topic

kafka基本概念及操作,cloud,mq,kafka,分布式

kafka基本概念及操作,cloud,mq,kafka,分布式

  • leader:

kafka的写和读的操作,都发生在leader上。leader负责把数据同步给follower。当leader挂了,经过主从选举,从多个follower中选举产⽣⼀个新的leader(follower通过poll的方式来同步数据)

  • follower:

接收leader的同步的数据,leader挂了,参与leader选举

  • replicas:

当前副本存在的broker节点

  • isr:

可以同步和已同步的broker节点会被存入到isr集合中。如果isr中的broker节点性能较差,会被踢出isr集合。

3.broker、主题、分区、副本

综上broker、主题、分区、副本概念已全部展示:

集群中有多个broker,创建主题时可以指明主题有多个分区(把消息拆分到不同的分区中存储),可以为分区创建多个副本,不同的副本存放在不同的broker⾥。

4.kafka集群消息的发送

./kafka-console-producer.sh --broker-list 124.222.253.33:9092,124.222.253.33:9093,124.222.253.33:9094 --topic my-replicated-topic

5.kafka集群消息的消费

1)普通消费

./kafka-console-consumer.sh --bootstrap-server 124.222.253.33:9092,124.222.253.33:9093,124.222.253.33:9094 --from-beginning --topic my-replicated-topic

2)指定消费组消费

./kafka-console-consumer.sh --bootstrap-server 124.222.253.33:9092,124.222.253.33:9093,124.222.253.33:9094 --from-beginning --consumer-property group.id=testGroup1 --topic my-replicated-topic

6.分区分消费组的集群消费中的细节

kafka基本概念及操作,cloud,mq,kafka,分布式

  • ⼀个partition只能被⼀个消费组中的⼀个消费者消费,目的是为了保证消费的顺序性,但是多个partion的多个消费者消费的总的顺序性是得不到保证的,那怎么做到消费的总顺序性呢?(Kafka只在partition的范围内保证消息消费的局部顺序性不能在同⼀个topic中的多个partition中保证总的消费顺序性。 ⼀个消费者可以消费多个partition。)

  • partition的数量决定了消费组中消费者的数量,建议同⼀个消费组中消费者的数量不要超过partition的数量,否则多的消费者消费不到消息

  • 如果消费者挂了,那么会触发rebalance机制,会让其他消费者来消费该分区

kafka集群中的controller、 rebalance、HW

1.controller

  • 集群中谁来充当controller 【Kafka集群中始终只有一个Controller Broker

每个broker启动时会向zk创建⼀个临时序号节点,获得的序号最小的那个broker将会作为集群中的controller

负责这么几件事:

  • 当集群中有⼀个副本的leader挂掉,需要在集群中选举出⼀个新的leader,选举的规则是 从isr集合中最左边获得。
  • 当集群中有broker新增或减少,controller会同步信息给其他broker
  • 当集群中有分区新增或减少,controller会同步信息给其他broker

脑裂
如果controller Broker 挂掉了,Kafka集群必须找到可以替代的controller,集群将不能正常运转。这里面存在一个问题,很难确定Broker是挂掉了,还是仅仅只是短暂性的故障。但是,集群为了正常运转,必须选出新的controller。如果之前被取代的controller又正常了,他并不知道自己已经被取代了,那么此时集群中会出现两台controller
其实这种情况是很容易发生。比如,某个controller由于GC而被认为已经挂掉,并选择了一个新的controller。在GC的情况下,在最初的controller眼中,并没有改变任何东西,该Broker甚至不知道它已经暂停了。因此,它将继续充当当前controller,这是分布式系统中的常见情况,称为脑裂。

2.rebalance机制

  • 前提:消费组中的消费者没有指明分区来消费
  • 触发的条件:当消费组中的消费者和分区的关系发生变化的时候
  • 分区分配的策略:在rebalance之前,分区怎么分配会有这么三种策略
    • range:根据公式计算得到每个消费消费哪几个分区:前面的消费者是分区总数/消费者数量+1,之后的消费者是分区总数/消费者数量(7个分区,三个消费者,则是:第一个消费者前三个分区,后面两个消费者各两个分区;8,3->3,3,2;9,3->3,3,3)
    • 轮询:大家轮着来
    • sticky:粘合策略,如果需要rebalance,会在之前已分配的基础上调整,不会改变之前的分配情况。如果这个策略没有开,那么就要进行全部的重新分配(全部重新分配效率较差)。建议开启。

3.HW和LEO

LEO是某个副本最后消息的消息位置(log-end-offset)

HW是已完成同步的位置。消息在写入broker时,且每个broker完成这条消息的同步后,hw才会变化。在这之前消费者是消费不到这条消息的。在同步完成之后,HW更新之后,消费者才能消费到这条消息,这样的目的是防止消息的丢失。(保证了如果leader所在的broker失效,该消息仍然可以从新选举的leader中获取。)
HW <= LEO
kafka基本概念及操作,cloud,mq,kafka,分布式文章来源地址https://www.toymoban.com/news/detail-657245.html

到了这里,关于kafka基本概念及操作的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 应用架构——集群、分布式、微服务的概念及异同

    一、什么是集群?         集群是指将多台服务器集中在一起, 每台服务器都实现相同的业务,做相同的事;但是每台服务器并不是缺 一不可,存在的主要作用是缓解并发能力和单点故障转移问题。 集群主要具有以下特征: (1)、 伸缩性         在一些大系统中,

    2024年02月03日
    浏览(50)
  • 分布式数据库NoSQL(二)——MongoDB 数据库基本操作

    MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。旨在为 WEB 应用提供可扩展的高性能数据存储解决方案。 MongoDB 是一个介于关系数据库和非关系数据库之间的产品,是非关系数据库当中功能最丰富,最像关系数据库的。它支持的数据结构非常松散,是类似 json 的

    2024年02月06日
    浏览(52)
  • 微服务面试问题小结( 微服务、分布式、MQ、网关、zookeeper、nginx)

    单体架构 优点:架构简单,维护成本低 缺点:各个模块耦合度太高,当对一个模块进行更新修改时,会影响到其他模块,要一起进行修改。当存在性能瓶颈的时候,需要对整个服务进行扩容,不能有针对性的扩容,如一个程序的主要功能时其中某个服务,要对其增加机器,

    2024年02月04日
    浏览(41)
  • SpringCloud分布式搜索引擎、数据聚合、ES和MQ的结合使用、ES集群的问题

    目录 数据聚合 聚合的分类 ​编辑 DSL实现Bucket聚合 ​编辑  DSL实现Metrics聚合​编辑 RestAPI实现聚合  对接前端接口​编辑  自定义分词器​编辑 Completion suggester查询 Completion suggester查询 酒店数据自动补全 实现酒店搜索框界面输入框的自动补全  数据同步问题分析​编辑 同

    2024年02月16日
    浏览(50)
  • kafka基本概念及操作

    Kafka是最初由Linkedin公司开发,是一个 分布式、支持分区的(partition)、多副本的 (replica) ,基于zookeeper协调的分布式消息系统,它的 最大的特性就是可以实时的处理大量数据以满足各种需求场景 :比如基于hadoop的批处理系统、低延迟的实时系统、 Storm/Spark流式处理引擎,

    2024年02月12日
    浏览(42)
  • 分布式链路追踪专栏,Spring Cloud Sleuth:分布式链路追踪之通信模型设计

    Spring Cloud Sleuth  赋予分布式跟踪的  Spring Boot  自动配置的一键解决方案。 Spring Cloud Sleuth  是基于  Brave  的封装,也是很多公司采用开源加自研的最佳解决方案。 那么从作为架构师或者技术专家如何去借鉴优秀框架的设计理念和思想,本次  Chat  将开启作者既分布式链路

    2024年01月19日
    浏览(66)
  • 使用Spring Cloud构建分布式应用

    Spring Cloud是一组构建分布式系统的框架,它提供了各种工具和库,帮助开发人员构建高可用、可伸缩、灵活的分布式应用程序。本文将介绍如何使用Spring Cloud构建分布式应用程序。 微服务架构 Spring Cloud是基于微服务架构设计的,该架构将应用程序划分为一组小型、自治的服

    2024年02月06日
    浏览(72)
  • Spring Cloud Sleuth:分布式链路跟踪

    1.1 什么是分布式链路跟踪 在分布式系统中,由于服务间的调用涉及多个节点和网络通信,出现问题时追踪问题的根源变得异常困难。分布式链路跟踪是一种技术,旨在解决这个问题。它允许开发人员追踪分布式系统中请求的流转路径,从而定位和解决性能问题、异常和错误

    2024年02月21日
    浏览(52)
  • 【Spring Cloud】Spring Cloud Alibaba-- 分布式事务Seata原理

    Seata 是一款开源的分布式事务解决方案,致力于提供高性能与简单易用的分布式事务服务,为用户提供了 AT、TCC、SAGA 和 XA 几种不同的事务模式: AT模式:无侵入式的分布式事务解决方案,适合不希望对业务进行改造的场景,但由于需要添加全局事务锁,对影响高并发系统的

    2024年02月08日
    浏览(78)
  • 理解 Spring Cloud 分布式配置中心Eureka

    作者:禅与计算机程序设计艺术 在 Spring Cloud 的世界里,分布式系统经历了开发、测试、运维三个阶段。而在开发阶段,通常采用集中式配置方式,将所有配置文件统一管理在一台服务器上。随着业务系统的不断扩张,各个微服务模块都需要配置自己的属性值。因此,需要一

    2024年02月08日
    浏览(55)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包