简述Kafka核心原理

一、kafka简介

Kafka是一种 高吞吐量的分布式发布-订阅 消息系统,专为超高吞吐量的实时日志采集、实时数据同步、实时数据计算等场景来设计。kafka是消息中间件的一种,目前主流的消息中间件有Apache的ActiveMQ,Linkedln开发的Kafka(现已捐赠给Apache),阿里的RocketMQ。

优点:

  • 高吞吐量(百万 /秒)
  • 高容错(多分区 &多副本)
  • 高并发(多分区)
  • 易扩展(多 broker节点)

缺点: 对任意消息队列只能分区内有序而不能全局有序

应用场景:

  • 构造实时流数据管道,它可以在系统或应用之间可靠地获取数据。 (相当于message queue)
  • 构建实时流式应用程序,对这些流数据进行转换或者影响。 (就是流处理,通过kafka stream topic和topic之间内部进行变化)

二、kafka架构

2.1架构

Broker: Kafka集群中的服务器
Topic: 维护一个主题中的消息,可视为消息分类
Producer: 向Kafka主题发布(生产)消息
Consumer: 订阅(消费)主题并处理消息

在这里插入图片描述
注:

  • Kafka集群由不同的Broker节点组成,每个Broker都有唯一的id(如从0开始编号)应该在节点安装时指定Broker在本地文件系统存储了所有Topic数据,不依赖外部数据库。
  • Topic类似于一个数据库表,里面存储一条条的key-value消息,Topic又分为多个不同的分区(Partition),每一条消息都由分区策略控制该消息应该存储在哪个分区之中,并由各分区相应的偏移量(Offset)唯一标识。
  • Producer负责向Kafka主题发布(生产)消息,一个Topic可以有多个Producer实例。
  • 在一个Partition中每一个记录的Offset是该记录的唯一标识,即每一个Offset唯一标识当前Partition中的一条记录。

2.2 相关概念

Topic

  • 主题是已发布消息的类别名称
  • 发布和订阅数据必须指定主题
  • 主题副本数量不大于Brokers个数
  • Topic类似于一个数据库表,里面存储一条条的 key value消息。每条消息的Key及 Value都有相应的序列化方式,通常是在 Producer生产消息时指定相应的序列化器,而 Consumer消费时使用相应的反序列化器,在实际应用时生产者与消费者应该约定统一的序列化方式。

在这里插入图片描述

partition

  • Topic是逻辑概念,而Partition则是物理上的概念
  • 一个Topic包含多个Partition,默认按Key Hash分区
  • 每个Partition被视为一个有序的日志文件(LogSegment),并且不断地追加到结构化的commit log文件
  • 当日志大小超过了单台服务器的限制,允许日志进行扩展。每个单独的分区都必须受限于主机的文件限制,不过一个主题可能有多个分区,因此可以处理无限量的数据
  • Replication策略是基于Partition,而不是Topic,可以作为并行的单元集,分布式,每一个分区都会在已配置的服务器上进行备份,确保容错性.
  • 每个Partition都有 一个 Leader,处理一切对 partition (分区)的读写请求
    -每个Partition有 0多个 Followers,被动的同步leader上的数据,当leader宕机了,followers 中的一台服务器会自动成为新的 leader
  • 每个Partition对应一个文件夹<topic_name>-<partition_id>
  • Kafka 只保证分区内的记录是有序的,而不保证主题中不同分区的顺序
  • 可以做负载均衡,根据生产者的 IP地址和端口来为其确定一个相关联的 Broker

注: 数据可靠性保证:
follower故障: follower故障会被临时提出isr,待follower恢复后,follower会读取本地磁盘记录的上次HW,并将log文件高于HW的部分截取掉,从HW开始向leader同步,等follower的LEO大于等于该Partition的HW,重新加入ISR。
leader故障: 从ISR选出一个新的leader,其余follower会先将各自的log文件高于HW的部分截掉,从新的leader同步数据,保证数据一致性。

producers

  • 生产者可以将数据发布到所选择的topic(主题)中
  • 生产者负责将记录分配到topic的哪一个 partition(分区)中
  • 生产者发送到特定topic partition 的消息将按照发送的顺序处理

customer

  • 在每一个消费者中唯一保存的元数据是offset(偏移量)即消费在log中的位置
  • 通常在读取记录后,消费者会以线性的方式增加偏移量,但是消费者可以采用任何顺序消费记录
  • 消费者的增加和减少,对集群或者其他消费者没有多大的影响
  • 一个消费者实例按照日志中的顺序查看记录.
  • 分区分配策略:
    ①:RoundRobin轮询:按组划分
    ②:Range:默认,按主题划分
  • consumer group(消费组)
    ①:每个 topic可以有多个消费组,消费者使用一个 消费组 名称来进行标识,发布到topic中的每条记录被分配给订阅消费组中的一个消费者实例。
    如果所有的消费者实例在同一消费组中,消息记录会负载平衡到每一个消费者实例.。
    如果所有的消费者实例在不同的消费组中,每条消息记录会广播到所有的消费者进程.
    ②:一个partition只能被一个消费组中的一个consumer消费,但可以被不同消费组同时消费
    ③:如果新的实例加入组,他们将从组中其他成员处接管一些 partition 分区;如果一个实例消失,拥有的分区将被分发到剩余的实例
    ④:要实现单播只要所有的consumer在同一个CG(消费组)

broker

  • 消息服务器,提供核心服务
  • 一台kafka服务器就是一个broker。一个集群由多个broker组成
  • 一个broker可以容纳多个topic

offset

  • 分区中的每一个记录都会分配一个有序id号(offset)来表示顺序
  • offset用来唯一的标识分区中每一条记录,offset由消费者所控制

Linux中kafka的常用命令

没有配置环境变量需切换至kafka安装的根目录,在相应命令前加上 /bin

启动kafka

①:前台启动(会独占一窗口)

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

②:后台启动(加上daemon 关键字)

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

创建topic:
可以设置分区数与副本数,副本数不等大于brokers

kafka-topics.sh --create --zookeeper 192.168.206.129:2181 --topic testDemo --partitions 3 --replication-factor 1 

创建生产者,产生数据:

kafka-console-producer.sh --topic testDemo --broker-list 192.168.206.129:9092

创建消费者,重头开始取数据:

kafka-console-consumer.sh --bootstrap-server 192.168.206.129:9092 --topic testDemo --from-beginning

删除topic:
这里的IP地址不用改

kafka-topics.sh --zookeeper 127.0.0.1:2181 --delete --topic testDemo

查看当前kafka中的所有topic列表 :

kafka-topics.sh --zookeeper 192.168.206.129:2181 --list

查看某一个topic详情:

kafka-topics.sh --zookeeper 192.168.206.129:2181 --describe --topic testDemo

查看某一个topic消息队列数量:

kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list 192.168.206.129:9092 --topic testDemo -time -1 --offsets 1
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值