Kafka介绍
ChatGPT对于Apache Kafka的介绍:
Apache Kafka是一个分布式流处理平台,最初由LinkedIn开发并于2011年开源。它主要用于解决大规模数据的实时流式处理和数据管道问题。
Kafka是一个分布式的发布-订阅消息系统,可以快速地处理高吞吐量的数据流,并将数据实时地分发到多个消费者中。Kafka消息系统由多个broker(服务器)组成,这些broker可以在多个数据中心之间分布式部署,以提供高可用性和容错性。
Kafka的基本架构由生产者、消费者和主题(topic)组成。生产者可以将数据发布到指定的主题,而消费者可以订阅这些主题并消费其中的数据。同时,Kafka还支持数据流的处理和转换,可以在管道中通过Kafka Streams API进行流式计算,例如过滤、转换、聚合等。
Kafka使用高效的数据存储和管理技术,能够轻松地处理TB级别的数据量。其优点包括高吞吐量、低延迟、可扩展性、持久性和容错性等。
Kafka在企业级应用中被广泛应用,包括实时流处理、日志聚合、监控和数据分析等方面。同时,Kafka还可以与其他大数据工具集成,如Hadoop、Spark和Storm等,构建一个完整的数据处理生态系统。
MQ的作用
MQ:MessageQueue,消息队列。 队列,是一种FIFO 先进先出的数据结构。消息则是跨进程传递的数据。一个典型的MQ系统,会将消息消息由生产者发送到MQ进行排队,然后根据一定的顺序交由消息的消费者进行处理。
主要作用:
-
异步
异步能提高系统的响应速度、吞吐量。
-
解耦
1、服务之间进行解耦,才可以减少服务之间的影响。提高系统整体的稳定性以及可扩展性。
2、另外,解耦后可以实现数据分发。生产者发送一个消息后,可以由一个或者多个消费者进行消费,并且消费者的增加或者减少对生产者没有影响。
-
削峰
作用:以稳定的系统资源应对突发的流量冲击。
为什么要用Kafka
典型日志聚合的应用场景:
业务场景决定了产品的特点。
1、数据吞吐量很大: 需要能够快速收集各个渠道的海量日志
2、集群容错性高:允许集群中少量节点崩溃
3、功能不需要太复杂:Kafka的设计目标是高吞吐、低延迟和可扩展,主要关注消息传递而不是消息处理。所以,Kafka并没有支持死信队列、顺序消息等高级功能。
4、允许少量数据丢失:Kafka本身也在不断优化数据安全问题,目前基本上可以认为Kafka可以做到不会丢数据。
Kafka快速上手
实验环境
准备三台CentOS7的虚拟机,预备搭建三台机器的集群。分别配置机器名 worker1,worker2,worker3。
vi /etc/hosts
192.168.146.128 worker1
192.168.146.129 worker2
192.168.146.130 worker3
关闭防火墙(实验环境建议关闭)
firewall-cmd --state 查看防火墙状态
systemctl stop firewalld.service 关闭防火墙
补充:虚拟机centos7遇到问题,bash: jps: 未找到命令... 的解决方案
yum list *openjdk-devel*
#安装适合自己的版本
yum install java-1.8.0-openjdk-devel.x86_64
#安装过程有几个同意步骤,输入y,安装完成测试jps ok!
下载kafka地址:Apache Kafka ,选择kafka_2.13-3.4.0.tgz进行下载。
下载Zookeeper地址 Apache ZooKeeper ,这里选择比较新的3.6.1版本。
下载完成后,将这两个工具包上传到服务器上,解压后,分别放到/app/kafka和/app/zk目录下。并将部署目录下的bin目录路径配置到path环境变量中。
环境变量/etc/profile
最终配置:
export ZK_HOME=/app/zk/apache-zookeeper-3.6.4-bin
export KAFKA_HOME=/app/kafka/kafka_2.13-3.4.0
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk
export PATH=$KAFKA_HOME/bin:$ZK_HOME/bin:$JAVA_HOME/bin:$PATH
export CLASSPATH=:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
单机服务体验
1、启动Kafka之前需要先启动Zookeeper。
#解压命令
tar zxvf apache-zookeeper-3.6.4-bin.tar.gz
tar zxvf kafka_2.13-3.4.0.tgz
#这里用Kafka自带的Zookeeper启动脚本
cd kafka_2.13-3.4.0/
nohup bin/zookeeper-server-start.sh config/zookeeper.properties &
通过jps指令看到一个QuorumPeerMain进程,确定服务启动成功。zk默认启动在2181端口
启动遇到问题可以查看nohup.out日志文件,注意脚本的执行权限
2、启动Kafka
nohup bin/kafka-server-start.sh config/server.properties &
启动完成后,使用jps指令,看到一个kafka进程,确定服务启动成功。服务默认9092端口
3、简单收发消息
Kafka的基础工作机制:消息发送者将消息发送到kafka上指定的topic,消息消费者从指定的topic上消费消息。
简单收到命令:
#创建Topic
bin/kafka-topics.sh --create --topic test --bootstrap-server localhost:9092
#查看Topic
bin/kafka-topics.sh --describe --topic test --bootstrap-server localhost:9092
#启动一个消息发送者端,往一个名为test的Topic发送消息
bin/kafka-console-producer.sh --broker-list localhost:9092 --topic test
#启动一个消息接收者端,接收名为test的Topic消息
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic test
生产者端示例:
消费者端示例:
注意:消费者启动命令执行后有几秒钟延迟(启动中接收不到消息),默认处理启动成功后接收到的消息
4、其他消费模式
指定消费进度
#通过--from-beginning消费之前发的消息
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --from-beginning --topic test
#指定从哪一条消息开始消费,offset表示索引/偏移量,索引4也就是第五条消息开始,0号partition
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --partition 0 --offset 4 --topic test
分组消费
kafka中的同一条消息,只能被同一个消费者组下的某一个消费者消费。而不属于同一个消费者组的其他消费者,也可以消费到这一条消息。通过--consumer-property group.id=testGroup
指定消费者组
#两个消费者实例属于同一个消费者组
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --consumer-property group.id=testGroup --topic test
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --consumer-property group.id=testGroup --topic test
#这个消费者实例属于不同的消费者组
bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 --consumer-property group.id=testGroup2 --topic test
查看消费者组的偏移量
#查看消费者组的情况,包括消费进度。
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group testGroup
···命令输出结果示例
Consumer group 'testGroup' has no active members. #没有活跃消费者
GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID
testGroup test 0 20 20 0 ... ... ...
···
描述:
PARTITION 分区
CURRENT-OFFSET 当前消费进度
LOG-END-OFFSET 日志种最大消息进度
LAG 未消费消息数
虽然业务上是通过Topic来分发消息的,但是实际上,消息是保存在Partition这样一个数据结构上
理解Kakfa的消息传递机制
Kafka的消息发送者和消息消费者通过Topic这样一个逻辑概念来进行业务沟通。但是实际上,所有的消息是存在服务端的Partition这样一个数据结构当中的。
-
客户端Client: 包括消息生产者和消息消费者。
-
消费者组:每个消费者可以指定一个所属的消费者组,相同消费者组的消费者共同构成一个逻辑消费者组。每一个消息会被多个感兴趣的消费者组消费,但是在每一个消费者组内部,一个消息只会被消费一次。
-
服务端Broker:一个Kafka服务器就是一个Broker。
-
话题Topic:这是一个逻辑概念,一个Topic被认为是业务含义相同的一组消息。客户端都通过绑定Topic来生产或者消费自己感兴趣的话题。
-
分区Partition:Topic只是一个逻辑概念,而Partition就是实际存储消息的组件。每个Partiton就是一个queue队列结构。所有消息以FIFO先进先出的顺序保存在这些Partition分区中。
Kafka集群服务
为什么要用集群?
单机服务下,Kafka已经具备了非常高的性能。TPS能够达到百万级别。但是,在实际工作中使用时,单机搭建的Kafka会有很大的局限性。
一方面:消息太多,需要分开保存。Kafka是面向海量消息设计的,一个Topic下的消息会非常多,单机服务很难存得下来。这些消息就需要分成不同的Partition,分布到多个不同的Broker上。这样每个Broker就只需要保存一部分数据。这些分区的个数就称为分区数。
另一方面:服务不稳定,数据容易丢失。单机服务下,如果服务崩溃,数据就丢失了。为了保证数据安全,就需要给每个Partition配置一个或多个备份,保证数据不丢失。Kafka的集群模式下,每个Partition都有一个或多个备份。Kafka会通过一个统一的Zookeeper集群作为选举中心,给每个Partition选举出一个主节点Leader,其他节点就是从节点Follower。主节点负责响应客户端的具体业务请求,并保存消息。而从节点则负责同步主节点的数据。当主节点发生故障时,Kafka会选举出一个从节点成为新的主节点。
最后:Kafka集群中的这些Broker信息,包括Partition的选举信息,都会保存在额外部署的Zookeeper集群当中,这样,kafka集群就不会因为某一些Broker服务崩溃而中断。
Kafka集群架构: