【学习笔记】Kafka学习

Kafka

传统定义：分布式的基于发布/订阅模式的消息队列，主要应用于大数据实时处理领域。是开源的分布式时间流平台，被数千家公司用于高性能数据管道、流分析、数据集成和关键任务应用

发布/订阅：消息的发布者不会将消息直接发送给特定的订阅者，而是将发布的消息分为不同的类别，订阅者只接受感兴趣的消息

常见的消息队列:Kakfa、ActiveMQ、RabbitMQ

在大数据场景主要常用Kafka。JavaEE开发主要采用ActiveMQ、RabbitMQ、RocketMQ

消息队列主要应用场景：缓冲/消峰、解耦、异步通信

缓冲/消峰：有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息处理速度不一致的情况

 解耦：允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束

 异步通信：允许用户吧一个消息放入队列，但并不立即处理它，然后在需要的时候再去处理它们

 

消息队列的两种模式：点对点模式、发布/订阅模式

点对点模式（不利于处理复杂业务场景）

消费者主动拉取数据，消息收到后清除消息（一个生产者对一个消费者）

 

发布/订阅模式

1. 可以有多个topic主题（浏览、点赞、收藏、评论等）

1. 消费者消费数据后，不删除数据
2. 每个消费者相互独立，都可以消费到数据

 Kafka的基础架构

1. 为了方便扩展，并提高吞吐量，一个topic分为多个partition
2. 配合分区的设计，提出消费者组的概念，组内每个消费者并行消费
3. 一个分区智只能给一个消费者消费，不然不利于管理
4. 为提高可用性，为每个分区增加若干副本，类似NameNode HA；副本分为leader和follower，生产消费只针对leader，leader挂follower可以成为leader
5. Zookeeper：记录整个集群服务器结点运行状态、记录每个分区的leader相关信息。Kafka2.8.0以后配置可以不采用Zookeeper

 

Broker：kafka集群包含一个或多个服务器，服务器节点成为broker

Topic：

1. 每条发布到kafka集群的消息都有一个类别，这个类别成为topic。
2. 物理上不同的Topic的消息是分开存储的。
3. 逻辑上一个Topic的消息虽然保存于一个或多个broker上但是用户只需要指定消息的Topic即可生产消费数据并不需要关注数据存于何处

Partition：

1. Topic中数据分割一个或者多个partition
2. 每个topic至少有一个partition，当生产者生产数据的时候，根据分配策略，选择分区，然后将消息追加到指定的分区末尾
3. 每条消息都有一个自增序号标识顺序和消息的偏移量
4. Partition中的数据是有序的，不同的分区间的数据丢失了数据的顺序
5. 如果topic有多个分区，消费数据时无法保证数据的顺序，严格保证消费顺序的场景下，需要将分区设为1

Leader

每个partition有多个副本，其中有且只有一个作为leader，负责数据读写

Follower（只负责备份）

1. Follower跟随Leader，所有写请求都通过Leader，数据变更会广播给所有从节点，从节点和主节点保持数据同步
2. 如果主节点失效，重新在从节点选举主节点
3. 当从节点挂掉或者同步太慢，主节点会吧从节点从”in sync replicas”(ISR)列表中删除，重新创建从节点

Producer

生产者将消息发布到kafka的Topic中，broker接收到生产者的消息后，将消息追加数据到segment文件中，生产者发送的消息存储到一个partition中，生产者也可以指定数据存储的partition

Consumer

消费者可以从broker中读取数据，消费者可以消费多个Topic中的数据

Consumer group

1. 每个消费者属于一个特定的消费者组，可以指定组名，不加则属于默认组
2. 将多个消费者集中到一起去处理某一个Topic数据，可以更快的提高数据消费
3. 整个消费者组共享一组偏移量（防止数据被重复读取），因为一个Topic多个分区
4. 一个消费者组只从broker读取一次数据

Offset偏移量

1. 唯一标识一条消息
2. 偏移量决定读取消息的位置，不会出现线程安全的问题，消费者通过偏移量来决定下次读取的消息
3. 消息被消费之后不会马上删除，这样多个业务可以重复使用kafka的消息
4. 可以通过修改偏移量达到重新读取消息的目的，偏移量由用户控制
5. 消息最终还是会被删除，生命周期为一周7*24

单播消息

一个消费组里只能有一个消费者消费消息

Kafka快速入门

Apache Kafka

进入官网下载kafka，连接Linux虚拟机并传入，解压：

tar -zxvf kafka_2.12-3.0.0.tgz -C ~/kafka（解压目标位置）

修改名称：mv kafka_2.12-3.0.0 kafka

 唯一标识，不能重复

 消息数据存储位置，默认Linux临时文件，会定期清除，所以需要修改

 Zookeeper连接，默认本地

运行kafka:

cd ./kafka

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

消息生产和发布

创建一个主题

bin/kafka-topics.sh --zookeeper localhost:2181 --create --topic heima --partitons 2 --replication-factor 1

--zookeeper：指定kakfa连接zookeeper的地址

--topic：指定创建的主题名

--partitions：指定分区的个数，发布消息是发送到主题的分区中

--replication-factor：指定副本因子

--create：创建主题的动作指令

查看所有topic

./bin/kafka-topics.sh --list --bootstrap-server 192.168.235.137:9092

在Topic中生产消息

./bin/kafka-console-producer.sh --topic wangting --broker-list 192.168.235

消费者消费某topic上的消息

./bin/kafka-console-consumer.sh --from-beginning -topic wangting --bootstrap-server 192.168.235.137:9092

Kafka集群

可扩展性：集群的性能不限制于单一服务实体，新的服务实体可以动态的恶添加到集群，从而增强集群的性能

高可用性：集群当其中一个结点发生故障时，这台结点上所运行的应用程序将在另一台结点上自动换管

集群的能力

负载均衡：负载均衡吧人物比较均匀的分布到集群环境下的计算和网络资源，以提高数据吞吐量

错误恢复：如果集群中某一台服务器发生故障无法使用，资源和应用程序可转移到可用的集群结点上。

Broker：每个Broker即kafka服务实例，多个Broker构成kafka集群，生产者发布的消息将保存在Broker中，消费者从Broker中拉取消息进行消费

Zookeeper：通过Zookeeper管理自身集群，如：Broker列表管理、Partition与Broker的关系、Partition与Consumer的关系、Producer与Consumer负载均衡、消费进行Offset记录、消费者注册等。为了达到高可用，zookeeper也必须是集群

1.搭建Zookeeper集群并启动

2.将原来的kafka目录复制多份，日志目录同时也要复制多份，重新开启集群需要将日志目录中的内容全部清空。

3.编辑配置文件：broker.id用于标识区分broker；其他broker的日志目录修改；zookeeper.connect连接ip：要将zookeeper集群的几个服务器都填上去

副本就是为了主题中的分区进行多个备份，副本之间会选举一个leader多个follower。

Isr即可用的结点（可以同步和已同步节点存入isr集合），当Isr有个节点性能较差，则会被踢出集合中，Leader会从Isr中选举出

集群有多个broker，创建主题时可以指明该主题有多少个分区（把消息拆分在不同的分区中存储），可以为分区创建多个副本，不同的副本存入不同的Broker