kafka快速入门到精通

目录

• 中文文档
• 1. 消息队列两种模式
  • 1.1 消息队列作用
  • 1.2 点对点模式(一对一，消费者主动拉取数据，消息收到后消息删除)
  • 1.3 发布/订阅模式(一对多，消费数据之后不会删除消息)
  • 1.4 kafka框架
  • 1.5 kafka工作流程
• 2. 安装部署
  • 2.1 下载安装
  • 2.2 配置hosts文件
  • 2.3 kafka配置文件（日志数据分离）
  • 2.4 配置环境变量
  • 2.5 启动集群/bin下脚本说明
  • 2.6 启动kafka集群shell脚本
  • 2.7 kafka启动日志文件
• 3. topic(队列)增删改查
  • 3.1 增-create
  • 3.2 删-delete
  • 3.3 修改topic分区数
  • 3.4 查topic列表-list
  • 3.5 查topic详情-describe
• 4. 终端开启测试生产者消费者
  • 4.1 开启生产者
  • 4.2 开启消费者
  • 4.3 新版和老版对比zookeeper/bootstrap-server
  • 4.4 数据目录kafka/data
• 5. kafka架构深入
  • 5.1 kafka工作流程
  • 5.2 kafka存储机制
  • 5.3 kafka生产者
    • 5.3.1 分区策略/分区原因/分区原则
    • 5.3.2 数据可靠性
    • 5.3.3 kafka数据同步策略/leader回复ack时机
    • 5.3.4 ISR保持同步的follower集合
    • 5.3.5 leader故障选举新leader（通过ISR选举）
    • 5.3.6 ack应答机制/ack配置
    • 5.3.7 故障处理细节（follower故障，leader故障,HW,LEO）
    • 5.3.8 Exactly Once(既不重复也不丢失)语义/启动幂等性
  • 5.4消费者
    • 5.4.1 消费方式（pull拉，timeout）
    • 5.4.2 offset的维护
    • 5.4.3 消费者组
  • 5.5 kafka为什么高效读写数据
  • 5.6 kafka事务
    • 5.6.1 Producer 事务
    • 5.6.2 Consumer 事务
• 6. kafka API
  • 6.1 消息发送流程（拦截器->序列化器->分区器）
  • 6.2 生产者API
  • 6.2 消费者API
    • 6.2.1 创建所有分区消费
    • 6.2.2 创建指定分区消费
    • 6.2.3 创建消费者组
• 7 . kafka-eagle监控
  • 7.1 下载安装
  • 7.2 修改配置
  • 7.3 启动kafka-eagle
  • 7.4 kafka-eagle删除需要的token

中文文档

https://kafka.apachecn.org/

1. 消息队列两种模式

1.1 消息队列作用

消息队列主要作用：
 1.解偶
 2.削峰，缓冲
 3.异步
 4.占存数据

kafka机器可用动态添加减少机器

1.2 点对点模式(一对一，消费者主动拉取数据，消息收到后消息删除)

消息生产者生产消息发送到Queue 中，然后消息消费者从Queue 中取出并且消费消息。消息被消费以后，queue 中不再有存储，所以消息消费者不可能消费到已经被消费的消息。Queue 支持存在多个消费者， 但是对一个消息而言， 只会有一个消费者可以消费。

eg:rabbitMQ简单模式

1.3 发布/订阅模式(一对多，消费数据之后不会删除消息)

消息生产者（发布）将消息发布到 topic 中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到 topic 的消息会被所有订阅者消费。

eg:kafka

1.4 kafka框架

1）	Producer ：消息生产者，就是向 kafka broker 发消息的客户端；
2）	Consumer ：消息消费者，向 kafka broker 取消息的客户端；
3）	Consumer Group （CG）：消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
4）	Broker ：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker
可以容纳多个topic。
5）	Topic ：可以理解为一个队列，生产者和消费者面向的都是一个 topic；
6）	Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个broker（即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列；
7）	Replica：副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失，且kafka 仍然能够继续工作，kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。
8）	leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。
9）	follower：每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 leader。

1.5 kafka工作流程

2. 安装部署

2.1 下载安装

下载官网：https://kafka.apache.org/downloads.html
使用：0.11.0.0版本
下载：wget https://archive.apache.org/dist/kafka/0.11.0.0/kafka_2.11-0.11.0.0.tgz
解压：tar -xf kafka_2.11-0.11.0.0.tgz -C /opt/module/
改名：mv kafka_2.11-0.11.0.0 kafka

2.2 配置hosts文件

cat >> /etc/hosts << EOF
192.168.0.215 sg-15
192.168.0.216 sg-16
192.168.0.217 sg-17
EOF

2.3 kafka配置文件（日志数据分离）

日志数据分离：
需要手动创建目录：/opt/module/kafka/data  //数据目录
会自动创建目录：/opt/module/kafka/logs  //日志目录

[root@sg-15 config]# cd /opt/module/kafka/config/
[root@sg-15 config]# vi server.properties //修改配置文件

输入以下内容：
#broker 的全局唯一编号，不能重复。其他机器kafka需要修改
broker.id=0
#删除 topic 功能使能
delete.topic.enable=true 
#处理网络请求的线程数量
num.network.threads=3
#用来处理磁盘 IO 的现成数量
num.io.threads=8
#发送套接字的缓冲区大小
socket.send.buffer.bytes=102400 
#接收套接字的缓冲区大小
socket.receive.buffer.bytes=102400 
#请求套接字的缓冲区大小
socket.request.max.bytes=104857600 
#kafka 暂存数据路径
log.dirs=/opt/module/kafka/data 
#topic 在当前 broker 上的分区个数
num.partitions=1
#用来恢复和清理 data 下数据的线程数量
num.recovery.threads.per.data.dir=1 
#一个数据文件最大大小。默认1G，/opt/module/kafka/data/00000000000000000000.log
log.segment.bytes=1073741824
#segment 文件保留的最长时间，超时将被删除。单位小时
log.retention.hours=168 
#配置连接Zookeeper 集群地址
zookeeper.connect=192.168.0.215:2181,192.168.0.216:2181,192.168.0.217:2181


配置完之后分发到其他kafka服务器，然后把配置文件broker.id改了broker.id=1、broker.id=2

2.4 配置环境变量

配置kafka命令，想配就配。不然就到kafaka/bin里执行命令

[root@sg-15 kafka]# sudo vi /etc/profile

#KAFKA_HOME
export KAFKA_HOME=/opt/module/kafka export PATH=$PATH:$KAFKA_HOME/bin

[atguigu@hadoop102 module]$ source /etc/profile

2.5 启动集群/bin下脚本说明

bin目录下常用文件介绍：
kafka-server-start.sh      //启动kafka服务
kafka-server-stop.sh       //停止kafka服务
kafka-console-consumer.sh  //控制台的消费者-测试环境使用
kafka-console-producer.sh  //控制台的生产者-测试环境使用
kafka-topics.sh            //关于topic的操作-增删改查
kafka-producer-perf-test.sh //生产者压力测试-测试集群负载能力
kafka-consumer-perf-test.sh //消费者压力测试-测试集群负载能力

//启动kafka，需要指定配置文件
[root@sg-15 kafka]# bin/kafka-server-start.sh -daemon config/server.properties  
[root@sg-15 kafka]# jps // 查看
29735 Jps
29658 Kafka
24235 QuorumPeerMain

2.6 启动kafka集群shell脚本

**:先做免密登陆
[root@sg-15 bin]# vi kafka.sh
[root@sg-15 script]# chmod 777 kafka.sh //加权限

case $1 in 
"start"){
	for i in 192.168.0.215 192.168.0.216 192.168.0.217
	do
		echo "*******kafka--$i**********"
		ssh $i "/opt/module/kafka/bin/kafka-server-start.sh -daemon /opt/module/kafka/config/server.properties"
		done
};;
"stop"){
	for i in 192.168.0.215 192.168.0.216 192.168.0.217
	do
		echo "*******kafka--$i**********"
		ssh $i "/opt/module/kafka/bin/kafka-server-stop.sh"
		done
};;
esac

2.7 kafka启动日志文件

如果jps查看没有kafka进程，到这个日志查原因

// 日志文件
[root@sg-15 logs]# cat /opt/module/kafka/logs/server.log

3. topic(队列)增删改查

3.1 增-create

--create
//增加一个主题(队列)
[root@sg-15 bin]# ./kafka-topics.sh --create --zookeeper 192.168.0.215:2181 --topic topicName --partitions 2 --replication-factor 2

Created topic "topicName".

参数：
--topic：定义主题名称
--partitions：定义分区数
--replication-factor：定义副本数,副本数小于等于kafka节点数(机器数)

3.2 删-delete

--delete
//删除topic
[root@sg-15 bin]# ./kafka-topics.sh --delete --zookeeper 192.168.0.215:2181 --topic topic_name

Topic topic_name is marked for deletion.
Note: This will have no impact if delete.topic.enable is not set to true.

注意：配置文件必须把delete.topic.enable=true,删除功能打开才能成功。

3.3 修改topic分区数

--alter
//修改分区数
[root@sg-15 bin]# ./kafka-topics.sh --zookeeper 192.168.0.215:2181 --topic topic_name --alter --partitions 4

3.4 查topic列表-list

--list
//查询主题列表(队列)，需要连接zookeeper
[root@sg-15 bin]# ./kafka-topics.sh --list --zookeeper 192.168.0.215:2181

3.5 查topic详情-describe

--describe
// 查询详情，副本数，分区数等
[root@sg-15 bin]# ./kafka-topics.sh --describe --topic frist --zookeeper 192.168.0.215:2181
Topic:frist	PartitionCount:1	ReplicationFactor:1	Configs:
	Topic: frist	Partition: 0	Leader: 1	Replicas: 1	Isr: 1

[root@sg-15 bin]# ./kafka-topics.sh --describe --topic frist2 --zookeeper 192.168.0.215:2181
Topic:frist2	PartitionCount:2	ReplicationFactor:2	Configs:
	Topic: frist2	Partition: 0	Leader: 1	Replicas: 1,0	Isr: 1,0
	Topic: frist2	Partition: 1	Leader: 2	Replicas: 2,1	Isr: 2

4. 终端开启测试生产者消费者

4.1 开启生产者

[root@sg-15 bin]# ./kafka-console-producer.sh --topic topicName -broker-list 192.168.0.215:9092
>aaa  // 生产消息
>123456  // 生产消息

4.2 开启消费者

// 开启消费者方式1:通过老方式依赖--zookeeper方式(有一堆提示)
[root@sg-17 bin]# ./kafka-console-consumer.sh --topic topicName --zookeeper 192.168.0.215:2181
Using the ConsoleConsumer with old consumer is deprecated and will be removed in a future major release. Consider using the new consumer by passing [bootstrap-server] instead of [zookeeper].
123456  //收到消息

// 开启消费者方式2:通过新版本方式--bootstrap-server（无提示）
--from-beginning 从头消费
[root@sg-17 bin]# ./kafka-console-consumer.sh --topic topicName --bootstrap-server 192.168.0.215:9092 --from-beginning
123456  //收到消息

// --from-beginning 从头开始消费7天内数据，最大保留7天
[root@sg-17 bin]# ./kafka-console-consumer.sh --topic topicName --bootstrap-server 192.168.0.215:9092 --from-beginning
aaa  //收到消息
123456  //收到消息

4.3 新版和老版对比zookeeper/bootstrap-server

老版：通过--zookeeper 方式开启消费者。zookeeper中主要存offset偏移量，依赖于zookeeper，需要频繁和zookeeper通信。
新版：通过--bootstrap-server offset偏移量存在了kafka自己本身中，kafka自默认有50个分区1个副本,50个分区以轮训的方式分布在kafka所有机器中，50个分区存系统主题

4.4 数据目录kafka/data

数据目录：/opt/module/kafka/data
创建topic时指定了两个副本，生产者生产数据时默认轮训往副本总写入写消息
00000000000000000000.log：存放数据文件，超过最大文件大小，将产生一个新的文件
log.segment.bytes=1073741824 参数配置00000000000000000000.log文件大小

“.index”文件存储大量的索引信息
“.log”文件存储大量的数据，索引文件中的元数据指向对应数据文件中message的物理偏移地址。

两个问题：
 1.怎么快速定位到消费的位置，.index索引文件
 2.超过文件大小时，新文件名称怎么命名

通过index文件快速定位到消费的位置：
第一步：通过二分查找发定位到.index文件
第二步：扫描index文件，找到数据在.log文件中具体的物理偏移量

5. kafka架构深入

5.1 kafka工作流程

topic可以理解为：队列
1.Kafka中消息是以topic进行分类的，生产者生产消息，消费者消费消息，都是面向topic的。

2.topic是逻辑上的概念，而partition是物理上的概念，每个partition对应于一个00000000000000000000.log数据文件，该log文件中存储的就是producer生产的数据。Producer生产的数据会被不断追加到该log文件末端，且每条数据都有自己的offset。消费者组中的每个消费者，都会实时记录自己消费到了哪个offset，以便出错恢复时，从上次的位置继续消费。

5.2 kafka存储机制

  由于生产者生产的消息会不断追加到 log 文件末尾，为防止 log 文件过大导致数据定位效率低下，Kafka 采取了分片和索引机制，将每个 partition 分为多个 segment。每个 segment 对应两个文件“.index”索引文件和“.log”数据文件。这些文件位于一个文件夹下，该文件夹的命名规则为：topic 名称+分区序号。

“.index”文件存储大量的索引信息
“.log”文件存储大量的数据，索引文件中的元数据指向对应数据文件中message的物理偏移地址。

5.3 kafka生产者

5.3.1 分区策略/分区原因/分区原则

分区策略

一个消费者组中有多个消费者，一个topic有多个分区，所以必然会涉及到partition的分配问题，即确定那个partition 由哪个consumer来消费。
两种方式：1）RoundRobin 2）Range
Range:面向topic处理，分配给订阅了该主题的人
RoundRobin：面向消费者组处理，分配给某个消费者组

分区原因

（1）方便在集群中扩展，每个Partition 可以通过调整以适应它所在的机器，而一个topic又可以有多个 Partition 组成，因此整个集群就可以适应任意大小的数据了；

（2）	可以提高并发，因为可以以Partition 为单位读写了。

分区原则

（1）	指明partition的情况下，直接将指明的值直接作为partiton值；
（2）	没有指明partition值但有key的情况下，将key的hash值与topic的partition数进行取余得到partition值；
（3）	既没有partition值又没有key值的情况下，第一次调用时随机选择一个partition，后面就轮寻。

5.3.2 数据可靠性

  为保证 producer 发送的数据，能可靠的发送到指定的 topic，topic的每个 partition 收到producer 发送的数据后，都需要向 producer 发送 ack（acknowledgement 确认收到），如果producer 收到 ack，就会进行下一轮的发送，否则重新发送数据。

什么时候回复ack？
 确保有follower与leader同步完成，leader再发送ack，这样才能保证leader 挂掉之后，能在follower中选举出新的leader

5.3.3 kafka数据同步策略/leader回复ack时机

kafka同步策略：全部完成同步，才发送ack回复
Kafka 选择了第二种方案，原因如下：
  1.同样为了容忍 n 台节点的故障，第一种方案需要 2n+1 个副本，而第二种方案只需要 n+1
个副本，而Kafka 的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。
  2.虽然第二种方案的网络延迟会比较高，但网络延迟对 Kafka 的影响较小。

方案	优点	缺点
半数以上完成同步，就发送 ack	延迟低	选举新的 leader 时，容忍 n 台节点的故障，需要 2n+1 个副 本
全部完成同步，才发送 ack	选举新的 leader 时，容忍 n 台节点的故障，需要 n+1 个副 本	延迟高

5.3.4 ISR保持同步的follower集合

  采用第二种方案之后(ack=-1)，设想以下情景：leader收到数据，所有follower都开始同步数据，但有一个follower，因为某种故障，迟迟不能与leader进行同步，那leader就要一直等下去，直到它完成同步，才能发送ack。这个问题怎么解决呢？

  Leader维护了一个动态的in-sync replica set (ISR)，意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后，leader就会给follower发送ack。如果follower长时间未向leader同步数据，则该follower将被踢出ISR，该时间阈值由:
replica.lag.time.max.ms参数设定。Leader发生故障之后，就会从ISR中选举新的leader。

5.3.5 leader故障选举新leader（通过ISR选举）

leader:通过isr选举：
 0.9版本之前(老版本):2个条件，与之前leader同步时间最短，同步消息数最多的就是新leader。
 0.9版本之后(新版本):1个条件，与之前leader同步时间最短的就是新leader。

5.3.6 ack应答机制/ack配置

ack:生产者发送数据确认收到，控制数据丢失
HW：控制数据所有副本一致性

  对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等ISR中的follower全部接收成功。
  所以Kafka为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置。

acks参数配置：0/1/-1(all)
 0：producer不等待broker的ack，这一操作提供了一个最低的延迟，broker一接收到还没有写入磁盘就已经返回，当broker故障时有可能丢失数据；
 1：producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据；
 -1（all）：producer等待broker的ack，partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。
 
acks:大白话
0:生产者不接收返回值(leader挂或不挂都可能丢失数据)
1:leader收到消息后，返回ack（leader挂了会丢失数据）
-1:等待ISR集合中全部收到数据，返回ack。（leader挂了，可能重复数据）

5.3.7 故障处理细节（follower故障，leader故障,HW,LEO）

log文件中的HW,LEO
LEO：指的是每个副本最大的 offset；
HW：指的是消费者能见到的最大的 offset，ISR 队列中最小的 LEO。
HW控制所有副本数据一致性

（1）follower 故障
  follower 发生故障后会被临时踢出 ISR，待该 follower 恢复后，follower 会读取本地磁盘记录的上次的HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 leader 进行同步。等该 follower 的 LEO 大于等于该Partition 的 HW，即 follower 追上 leader 之后，就可以重新加入 ISR 了。

（2）leader 故障
  leader 发生故障之后，会从 ISR 中选出一个新的 leader，之后，为保证多个副本之间的数据一致性，其余的follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 leader同步数据。

注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。

5.3.8 Exactly Once(既不重复也不丢失)语义/启动幂等性

acks:0  At Most Once(最多一次)，生产者发送数据最多发送一次，不接受ack。可以保证数据不重复，但是不能保证数据不丢失。

acks:-1 At least Once(最少一次)，生产者发送数据最少一次，接受到ack为止，可能多次发送，造成数据重复。可以保证不丢数据，但是不能保证数据不重复。

Exactly Once(既不重复也不丢失)语义：0.11版本以前kafka对此无能为力，只能保证数据不丢失，然后在下游(消费者)对数据做全局去重，对性能造成很大的影响。

  0.11 版本的 Kafka，引入了一项重大特性：幂等性。所谓的幂等性就是指Producer 不论向 Server 发送多少次重复数据，Server 端都只会持久化一条。幂等性结合 At Least Once 语义，就构成了Kafka 的Exactly Once 语义。
即：At Least Once + 幂等性 = Exactly Once

启动幂等性：将 Producer 的参数中 enable.idompotence 设置为 true 即可

kafka幂等性实现方式：将原来下游需要做的去重放在了数据上游。开启幂等性的 Producer 在初始化的时候会被分配一个 PID，发往同一 Partition 的消息会附带 Sequence Number。而Broker 端会对<PID, Partition, SeqNumber>做缓存，当具有相同主键的消息提交时，Broker只会持久化一条。
但是PID 重启就会变化，同时不同的 Partition 也具有不同主键，所以幂等性无法保证跨分区跨会话的Exactly Once。

5.4消费者

5.4.1 消费方式（pull拉，timeout）

consumer 采用 pull（拉）模式从 broker 中读取数据。
因为push（推）模式很难适应消费速率不同的消费者，因为消息发送速率是由 broker 决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成 consumer 来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而 pull 模式则可以根据 consumer 的消费能力以适当的速率消费消息。

pull 模式不足之处是， 如果 kafka 没有数据，消费者可能会陷入循环中，一直返回空数据。针对这一点，Kafka 的消费者在消费数据时会传入一个时长参数 timeout，如果当前没有数据可供消费，consumer 会等待一段时间之后再返回，这段时长即为timeout。

5.4.2 offset的维护

  由于consumer 在消费过程中可能会出现断电宕机等故障，consumer 恢复后，需要从故障前的位置的继续消费，所以 consumer 需要实时记录自己消费到了哪个 offset，以便故障恢复后继续消费。

//offset存在zookeeper的位置
[zk: localhost:2181(CONNECTED) 10] get /consumers/atguigu/offsets/topicName/0
18

Kafka 0.9 版本之前，consumer 默认将 offset 保存在 Zookeeper 中，从 0.9 版本开始， consumer 默认将 offset 保存在 Kafka 一个内置的 topic 中，该 topic 为 consumer_offsets。

1）修改配置文件consumer.properties
exclude.internal.topics=false

5.4.3 消费者组

  一个消费者组中有多个消费者，一个topic(队列)有多个partition(分区)，所以必然会涉及到partition的分配问题，即确定那个partition由哪个consumer来消费。
  注意：一个消费者组，同时只有一个消费者消费

配置文件：vi /opt/module/kafka/config/consumer.properties
默认：group.id=test-consumer-group 每创建一个消费者随机创建一个组
修改：group.id=bsBike  修改任意组名，创建的消费者都在这个组里面

// 必须指定--consumer.config刚刚修改的配置文件
创建2个同组消费者：[root@sg-16 bin]# ./kafka-console-consumer.sh --topic topicName --zookeeper 192.168.0.215:2181 --consumer.config ../config/consumer.properties

启动生产者：[root@sg-15 config]# ./kafka-console-producer.sh --topic topicName -broker-list 192.168.0.215:9092

验证:同一时刻只有一个消费者消费数据。

5.5 kafka为什么高效读写数据

kafka高效的原因有：
1.分布式的（有分区概率，可以并发读写，但是单机器效率也很高）
2.顺序读写磁盘
3.零复制技术（零拷贝技术）

顺序读写磁盘

  Kafka 的 producer 生产数据，要写入到log数据文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到 600M/s，而随机写只有 100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。

 顺序写：相当于开辟一块空间，每次都写在磁盘的同一个扇区
 随机写：每次写在磁盘的不同扇区，需要花费大量寻址时间

零拷贝技术

a.txt修改为b.txt：
普通情况(图1)：用户通过代码调用c语言，读取a.txt文件，再通过网络写入b.txt文件
零拷贝技术(图2)：用户发送给操作系统指令，由操作系统直接把a.txt修改为b.txt

图1

图2

5.6 kafka事务

  Kafka 从 0.11 版本开始引入了事务支持。事务可以保证 Kafka 在Exactly Once 语义的基础上，生产和消费可以跨分区和会话，要么全部成功，要么全部失败。

5.6.1 Producer 事务

  为了实现跨分区跨会话的事务，需要引入一个全局唯一的 Transaction ID，并将 Producer 获得的PID 和Transaction ID 绑定。这样当Producer 重启后就可以通过正在进行的Transaction ID 获得原来的PID。
  为了管理Transaction，Kafka 引入了一个新的组件Transaction Coordinator。Producer 就是通过和 Transaction Coordinator 交互获得 Transaction ID 对应的任务状态。Transaction Coordinator 还负责将事务所有写入 Kafka 的一个内部 Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

5.6.2 Consumer 事务

   上述事务机制主要是从Producer 方面考虑，对于 Consumer 而言，事务的保证就会相对较弱，尤其时无法保证 Commit 的信息被精确消费。这是由于 Consumer 可以通过 offset 访问任意信息，而且不同的 Segment File 生命周期不同，同一事务的消息可能会出现重启后被删除的情况。

6. kafka API

6.1 消息发送流程（拦截器->序列化器->分区器）

  Kafka 的 Producer 发送消息采用的是异步发送的方式。在消息发送的过程中，涉及到了两个线程——main线程和Sender线程，以及一个线程共享变量——RecordAccumulator。main 线程将消息发送给 RecordAccumulator，Sender 线程不断从 RecordAccumulator 中拉取消息发送到Kafka broker。

相关参数：
batch.size：只有数据积累到 batch.size 之后，sender 才会发送数据。
linger.ms：如果数据迟迟未达到 batch.size，sender 等待 linger.time 之后就会发送数据。

分区器:hash计算分区分区号，决定写入的分区
序列化器:生产者把对象转换成字节数组才能通过网络发送给Kafka，消费者需要反序列化
拦截器:在消息发送前做一些准备工作，比如按照某个规则过滤不符合要求的消息、修改消息的内容等
RecordAccumulator：数据共享区

处理顺序：拦截器-->序列化器-->分区器

6.2 生产者API

电脑本地添加hosts内容：sudo vi /etc/hosts
192.168.0.215 sg-15
192.168.0.216 sg-16
192.168.0.217 sg-17

生产者API

官网：https://www.topgoer.cn/docs/golang/chapter10-5-4

Go语言中连接kafka使用第三方库: github.com/Shopify/sarama。使用v1.19.0版本
下载安装：go get github.com/Shopify/sarama@v1.19.0

连接kafka发送消息

package main

import (
	"fmt"

	"github.com/Shopify/sarama"
)

func main() {
	config := sarama.NewConfig()
  // 回复ack模式
	config.Producer.RequiredAcks = sarama.WaitForAll          // 发送完数据需要leader和follow都确认
	config.Producer.Partitioner = sarama.NewRandomPartitioner // 新选出一个partition
	config.Producer.Return.Successes = true                   // 成功交付的消息将在success channel返回

	// 构造一个消息
	msg := sarama.ProducerMessage{}
	msg.Topic = "topicName"
	msg.Value = sarama.StringEncoder("this is a test log2")
	// 连接kafka
	client, err := sarama.NewSyncProducer([]string{"192.168.0.216:9092"}, config)
	if err != nil {
		fmt.Println("producer closed",err)
		return
	}
	defer client.Close()
	// 发送消息
	pid, offset, err := client.SendMessage(&msg)
	if err != nil {
		fmt.Println("send msg failed：",err)
		return
	}
	fmt.Println("pid:",pid)
	fmt.Println("offset:",offset)
}

6.2 消费者API

6.2.1 创建所有分区消费

demo:

package main

import (
	"encoding/json"
	"fmt"
	"sync"

	"github.com/Shopify/sarama"
)

// kafka 消费者
func main() {
	var wg sync.WaitGroup
	consumer, err := sarama.NewConsumer([]string{"192.168.0.215:9092"}, nil)
	topicName := "topicName"
	if err != nil {
		fmt.Printf("fail to start consumer, err:%v\n", err)
		return
	}
	partitionList, err := consumer.Partitions(topicName) // 根据topic取到所有的分区
	if err != nil {
		fmt.Printf("fail to get list of partition:err%v\n", err)
		return
	}
	fmt.Println(partitionList)
	for partition := range partitionList { // 遍历所有的分区
		// 针对每个分区创建一个对应的分区消费者
		pc, err := consumer.ConsumePartition(topicName, int32(partition), sarama.OffsetNewest)
		if err != nil {
			fmt.Printf("failed to start consumer for partition %d,err:%v\n", partition, err)
			return
		}
		defer pc.AsyncClose()
		// 异步从每个分区消费信息
		go func(sarama.PartitionConsumer) {
			wg.Add(1)
			for msg := range pc.Messages() {
				a,_:=json.Marshal(msg)
				fmt.Println(string(a))
				fmt.Printf("Partition:%d Offset:%d Key:%v Value:%v\n", msg.Partition, msg.Offset, msg.Key, string(msg.Value))
			}
		}(pc)
	}
	wg.Wait() //等待
}

结果：
[0 1]
{"Key":null,"Value":"dGhpcyBpcyBhIHRlc3QgbG9nMg==","Topic":"topicName","Partition":1,"Offset":34,"Timestamp":"0001-01-01T00:00:00Z","BlockTimestamp":"0001-01-01T00:00:00Z","Headers":null}
Partition:1 Offset:34 Key:[] Value:this is a test log2

6.2.2 创建指定分区消费

demo:

package main

import (
	"encoding/json"
	"fmt"
	"sync"

	"github.com/Shopify/sarama"
)

// kafka consumer

func main() {
	var wg sync.WaitGroup
	wg.Add(1)

	consumer, err := sarama.NewConsumer([]string{"192.168.0.215:9092"}, nil)
	topicName := "topicName"
	if err != nil {
		fmt.Printf("fail to start consumer, err:%v\n", err)
		return
	}
	partitionList, err := consumer.Partitions(topicName) // 根据topic取到所有的分区
	if err != nil {
		fmt.Printf("fail to get list of partition:err%v\n", err)
		return
	}
	fmt.Println(partitionList) //[0 1]
	// 针对其中一个分区创建一个对应的分区消费者
	partition := partitionList[0]
	pc, err := consumer.ConsumePartition(topicName, int32(partition), sarama.OffsetNewest)
	if err != nil {
		fmt.Printf("failed to start consumer for partition %d,err:%v\n", partition, err)
		return
	}
	defer pc.AsyncClose()
	// 异步从每个分区消费信息
	go func(sarama.PartitionConsumer) {
		for msg := range pc.Messages() {
			a, _ := json.Marshal(msg)
			fmt.Println(string(a))
			fmt.Printf("Partition:%d Offset:%d Key:%v Value:%v\n", msg.Partition, msg.Offset, msg.Key, string(msg.Value))
		}
	}(pc)
	wg.Wait() //等待
}

结果：
[0 1]
{"Key":null,"Value":"dGhpcyBpcyBhIHRlc3QgbG9nMg==","Topic":"topicName","Partition":0,"Offset":29,"Timestamp":"0001-01-01T00:00:00Z","BlockTimestamp":"0001-01-01T00:00:00Z","Headers":null}
Partition:0 Offset:29 Key:[] Value:this is a test log2

6.2.3 创建消费者组

同一个组中，同时只有一个消费者消费同一个topic的数据。避免消费者重复消费数据

一个分区只能被同一个消费组的一个消费者消费，如果想要一个分区被多个消费者消费，可以使用多个消费者组
经测试：一个消费者组下的消费者数量<=topic分区数

demo:

package main

import (
	"fmt"
	"os"
	"os/signal"
	_ "regexp"

	cluster "github.com/bsm/sarama-cluster"
)

var Address = []string{"192.168.0.215:9092"}
var Topic = "topicName"

func main() {
  // 消费者组名：demo1
	go syncConsumer("demo1")
	select {}
}

//消费者组
func syncConsumer(groupName string) {
	config := cluster.NewConfig()
	config.Consumer.Return.Errors = true
	config.Group.Return.Notifications = true

	// init consumer
	//可以订阅多个主题
	topics := []string{Topic}
	consumer, err := cluster.NewConsumer(Address, groupName, topics, config)
	if err != nil {
		panic(err)
	}
	//这里需要注意的是defer 一定要在panic 之后才能关闭连接
	defer consumer.Close()

	// trap SIGINT to trigger a shutdown.
	signals := make(chan os.Signal, 1)
	signal.Notify(signals, os.Interrupt)

	// consume errors
	go func() {
		for err = range consumer.Errors() {
			fmt.Println("err:",err)
		}
	}()

	// consume notifications
	go func() {
		for ntf := range consumer.Notifications() {
			fmt.Println("消费通知：",ntf)
		}
	}()

	// 循环从通道中获取message
	//msg.Topic 消息主题
	//msg.Partition  消息分区
	//msg.Offset
	//msg.Key
	//msg.Value 消息值
	for {
		select {
		case msg, ok := <-consumer.Messages():
			if ok {
				fmt.Printf("%s receive message %s---Partition:%d, Offset:%d, Key:%s, Value:%s\n", groupName, msg.Topic, msg.Partition, msg.Offset, string(msg.Key), string(msg.Value))
				consumer.MarkOffset(msg, "") // 上报offset
			}
		case err := <-consumer.Errors():
			{
				fmt.Println(fmt.Sprintf("consumer error:%v", err))
			}
		case <-signals:
			return
		}
	}
}

7 . kafka-eagle监控

7.1 下载安装

http://www.kafka-eagle.org/articles/docs/changelog/changelog.html
此版本下载1.3.7
下载到/opt/software/目录中

//解压
解压：tar -xf kafka-eagle-bin-1.3.7
再解压(因为包了两层):
cd /opt/software/kafka-eagle-bin-1.3.7
tar -xf kafka-eagle-web-1.3.7-bin.tar.gz -C /opt/module/

//改名为eagle
cd /opt/module
mv kafka-eagle-web-1.3.7 eagle

7.2 修改配置

//修改kafka启动命令，开启jmx端口，帮助eagle抓取kafka中的数据，修改kafka中bin/kafka-server-start.sh文件
if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then
    export JMX_PORT="9999"  //添加
    export KAFKA_HEAP_OPTS="-Xmx1G -Xms1G" 
fi

注意：kafka所有机器的启动文件都要修改,java环境变量也要配置

//添加环境变量，因为kafka-eagle启动会读环境变量
export KE_HOME=/opt/module/eagle
export PATH=$PATH:$KE_HOME/bin
[root@sg-15 eagle]# source /etc/profile  //刷新环境变量

//添加执行权限
[root@sg-15 bin]# chmod 777 /opt/module/eagle/bin/ke.sh

// conf目录下文件：
log4j.properties //配置日志文件
system-config.properties //系统配置

// 系统配置，修改/opt/module/eagle/conf/system-config.properties文件
注意：eagle框架可以支持多套kafka集群，用","隔开即可
kafka.eagle.zk.cluster.alias=cluster1
cluster1.zk.list=192.168.0.215:2181,192.168.0.216:2181,192.168.0.217:2181
cluster2.zk.list删掉 //删掉这行
kafka.eagle.webui.port=8048 //ui端口，如果和其他的程序冲突就改
cluster1.kafka.eagle.offset.storage=kafka //保留，因为0.11版本之后offset写在kafka本地
cluster2.kafka.eagle.offset.storage=zookeeper //删除这行，如果是监控的0.11版本之前的kafka集群删除上面一行

kafka.eagle.metrics.charts=true //改为true，监控图表，否则页面看不见图表

//监控异常，发送的邮箱。需要即配置
kafka.eagle.mail.enable=false
kafka.eagle.mail.sa=jeff@163.com
kafka.eagle.mail.username=alert_sa@163.com
kafka.eagle.mail.password=mqslimczkdqabbbh
kafka.eagle.mail.server.host=smtp.163.com
kafka.eagle.mail.server.port=25

//存一些元数据信息，一般存mysql中，需要即配置
kafka.eagle.driver=com.mysql.jdbc.Driver
kafka.eagle.url=jdbc:mysql://192.168.0.215:3306/ke?useUnicode=true&characterEncoding=UTF-8&zeroDateTimeBehavior=convertToNull
kafka.eagle.username=root
kafka.eagle.password=123456

注意：会在mysql中自动创建ke库

7.3 启动kafka-eagle

[root@sg-15 bin]# ./ke.sh start //启动
[root@sg-15 bin]# ./ke.sh status //查看状态

ke.sh [start|status|stop|restart|stats]

如果启动失败，查看日志：/opt/module/eagle/logs

启动成功

web页面：

7.4 kafka-eagle删除需要的token

//在配置文件中/opt/module/eagle/conf/system-config.properties
kafka.eagle.topic.token=keadmin