FatPuffer

3.Kafka

1.定义

1.1传统定义

Kafka是一个分布式的基于发布订阅模式的消息队列，主要应用于大数据的实时处理领域
发布订阅：消息发布者不会直接将消息发送给订阅者，而是将发布的消息分为不同的类别，订阅者只接收感兴趣的消息

1.2最新定义

Kafka是一个开源的分布式流平台，被数千家公司用于高性能数据管道、流分析、数据集成、和关键任务应用

2.消息队列

2.1常见消息队列

Kafka
ActiveMQ
RabbitMQ
RocketMQ

2.2应用场景

Kafka更多应用于大数据场景
ActiveMQ、RabbitMQ、RocketMQ多应用于web服务器开发场景

2.3作用

缓存
流量削峰
解耦
异步通信

3.Kafka模式

3.1模式图鉴

点对点模式
- 消费者主动拉取数据，数据收到后清除数据
发布/订阅模式
- 可以有多个Topic主题
- 消费者消费数据后，不删除数据
- 每个消费者相互独立、都可以消费到数据

3.2推拉模式各自优缺点

3.2.1推模式

优点
- 1.消息实时性高， Broker 接受完消息之后可以立马推送给 Consumer。
- 2.对于消费者使用来说更简单，只需要等着，反正有消息来了就会推过来。
缺点
- 1.推送速率难以适应消费速率，推模式的目标就是以最快的速度推送消息，
  当生产者往 Broker 发送消息的速率大于消费者消费消息的速率时，
  随着时间的增长消费者那边可能就“爆仓”了，因为根本消费不过来啊。
  当推送速率过快就像 DDos 攻击一样消费者就傻了。
- 2.并且不同的消费者的消费速率还不一样，身为 Broker 很难平衡每个消费者
  的推送速率，如果要实现自适应的推送速率那就需要在推送的时候消费者告诉
  Broker ，我不行了你推慢点吧，然后 Broker 需要维护每个消费者的状态进行
  推送速率的变更。这其实就增加了 Broker 自身的复杂度。
适用场景
- 适用于消息量不大、消费能力强要求实时性高的情况下

3.2.2拉模式

优点
- 1.消费者可以根据自身的情况来发起拉取消息的请求。假设当前消费者觉得自己消费不过来了，它可以根据一定的策略停止拉取，或者间隔拉取都行。
- 2.拉模式下 Broker 就相对轻松了，它只管存生产者发来的消息，至于消费的时候自然由消费者主动发起，来一个请求就给它消息呗，从哪开始拿消息，拿多少消费者都告诉它，它就是一个没有感情的工具人，消费者要是没来取也不关它的事。
缺点
- 1.消息延迟，毕竟是消费者去拉取消息，但是消费者怎么知道消息到了呢？所以它只能不断地拉取，但是又不能很频繁地请求，太频繁了就变成消费者在攻击 Broker 了。因此需要降低请求的频率，比如隔个 2 秒请求一次，你看着消息就很有可能延迟 2 秒了。
- 2.消息忙请求，忙请求就是比如消息隔了几个小时才有，那么在几个小时之内消费者的请求都是无效的，在做无用功。
- 3.服务端压力变大，长时间消费速度跟不上生产速度，就会使得Broker存储的消息越来越多，极端情况下可能导致服务器内存爆仓
适用场景
- 拉模式可以更合适的进行消息的批量发送，基于推模式可以来一个消息就推送，也可以缓存一些消息之后再推送，但是推送的时候其实不知道消费者到底能不能一次性处理这么多消息。而拉模式就更加合理，它可以参考消费者请求的信息来决定缓存多少消息之后批量发送。

4.架构

4.1基础架构

4.2完整架构

为方便扩展，提高吞吐量，一个topic分为多个partition
配合分区设计，提出消费者组的概念，组内每个消费者并行消费
- 一个分区的数据，只能由消费者组内的一个消费者消费，避免重复消费问题
- 如果没有对消费者分组，那么一个分区的数据可以被多个消费者消费
为提高可用性，为每个partition增加若干副本，类似NameNode HA
- 消费者只能从主partition进行消费，当主partition挂掉后，从partition可成为主partition
Zookeeper（Kafka2.8.0之前必须使用Zookeeper，2.8.0之后可选karft）
- 记录集群中哪些broker服务器上线了
- 记录哪个partition是主

5.下载安装

5.1下载

官网地址：https://kafka.apache.org/downloads

wget https://archive.apache.org/dist/kafka/3.0.0/kafka_2.12-3.0.0.tgz -P /opt/software

解压

tar -zxvf /opt/software/kafka_2.12-3.0.0.tgz -C /opt/moudle

重命名

mv /opt/moudle/kafka_2.12-3.0.0 /opt/moudle/kafka

5.2修改配置

修改server.properties

# 集群中每个broker的身份标识，整个集群中不能存在重复的id
broker.id=0

# 数据存储目录，建议不要使用/tmp临时路径
# log.dirs=/tmp/kafka-logs
log.dirs=/opt/moudle/kafka/datas

# 连接的zookeeper集群
# /kafka为了方便管理数据
# zookeeper.connect=localhost:2181
zookeeper.connect=first-node:2181,second-node:2181,third-node:2181/kafka

5.3集群分发

分发kafka软件包
```
xsync /opt/moudle/kafka
```

修改集群其他节配置文件的broker.id

ssh second-node "sed -i.bak s/broker.id=0/broker.id=1/ /opt/moudle/kafka/config/server.properties"
ssh third-node "sed -i.bak s/broker.id=0/broker.id=2/ /opt/moudle/kafka/config/server.properties"

配置kafka环境变量：sudo vim /etc/profile.d/my_env.sh

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

重新加载环境变量
```
source /etc/profile
```
环境变量配置文件分发
- 如果root用户未配置ssh免密登录，此处需要输入密码
```
sudo /home/fatpuffer/bin/xsync /etc/profile.d/my_env.sh
```
登录集群环境其他节点重新加载环境变量
```
source /etc/profile
```

5.4启动kafka

5.4.1首先需要启动ZK集群

zk.sh start

5.4.2启动Kafka

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

5.4.3停止Kafka

kafka-server-stop.sh

6.Kafka集群

6.1启动停止脚本

1.用户bin目录下创建kfk.sh文件：vim /home/fatpuffer/bin/kfk.sh

#! /bin/bash

case $1 in
"start"){
    for node in first-node second-node third-node
    do
        echo ----------------------kafka $node start--------------------
        ssh $node "kafka-server-start.sh -daemon /opt/moudle/kafka/config/server.properties"
    done
};;
"stop"){
    for node in first-node second-node third-node
    do
        echo ----------------------kafka $node stop--------------------
        ssh $node "kafka-server-stop.sh"
    done
};;
esac

2.修改脚本权限
```
comod +x kfk.sh
```
3.脚本使用
```
kfk.sh start
kfk.sh stop
```

6.2注意事项

启动Kafka前一定要确保ZK集群已经启动成功
必须等待Kafka完全停止，才可以停止Zoopeeper，否则会导致Kafka无法停止

6.3Kafka在ZK集群中的节点

查看节点/kafka信息

[zk: localhost:2181(CONNECTED) 1] ls /kafka
[admin, brokers, cluster, config, consumers, controller_epoch, feature, isr_change_notification, latest_producer_id_block, log_dir_event_notification]

查看节点/kafka/brokers

[zk: localhost:2181(CONNECTED) 16] ls /kafka/brokers
[ids, seqid, topics]

查看节点/kafka/brokers/ids

[zk: localhost:2181(CONNECTED) 11] ls /kafka/brokers/ids
[0, 1, 2]

查看节点/kafka/brokers/topics

[zk: localhost:2181(CONNECTED) 17] ls /kafka/brokers/topics
[]

获取/kafka/brokers/ids/0的数据

[zk: localhost:2181(CONNECTED) 13] get /kafka/brokers/ids/0
{"listener_security_protocol_map":{"PLAINTEXT":"PLAINTEXT"},"endpoints":["PLAINTEXT://first-node:9092"],"jmx_port":-1,"features":{},"host":"first-node","timestamp":"1670480025960","port":9092,"version":5}
[zk: localhost:2181(CONNECTED) 14] get /kafka/brokers/ids/1
{"listener_security_protocol_map":{"PLAINTEXT":"PLAINTEXT"},"endpoints":["PLAINTEXT://second-node:9092"],"jmx_port":-1,"features":{},"host":"second-node","timestamp":"1670480032519","port":9092,"version":5}
[zk: localhost:2181(CONNECTED) 15] get /kafka/brokers/ids/2
{"listener_security_protocol_map":{"PLAINTEXT":"PLAINTEXT"},"endpoints":["PLAINTEXT://third-node:9092"],"jmx_port":-1,"features":{},"host":"third-node","timestamp":"1670480038549","port":9092,"version":5}

7.Kafka基本命令行操做

7.1脚本图鉴

7.2主题命令操做

命令参数

参数	描述
–bootstrap-server	连接的 Kafka Broker主机名称和端口
–topic	操做的Topic名称
–create	创建主题
–delete	删除主题
–alter	修改主题
–list	查看所有主题
–describe	查看主题详细描述
–partitions	设置分区数
–replication-factor	设置分区副本
–config	更新系统默认的配置
–producer-property	将自定义属性传递给生成器的机制，形如：key=value
–producer.config	生产者配置属性文件 [–producer-property] 优先于此配置
–property	自定义消息读取器：parse.key=true\|false key.separator= ignore.error=true
–request-required-acks	生产者请求的确认方式：0、1(默认值)、all
–sync	同步发送消息

查看当前服务器中的所有topic

kafka-topics.sh --bootstrap-server first-node:9092 --list

# 连接多个节点
# kafka-topics.sh --bootstrap-server first-node:9092,second-node:9092,third-node:9092 --list

创建一个名为demo1的主题，设置分区数为1，分区副本为3

kafka-topics.sh --bootstrap-server first-node:9092 --topic demo1 --create --partitions 1 --replication-factor 3

[zk: localhost:2181(CONNECTED) 22] ls /kafka/brokers/topics
[demo1]
[zk: localhost:2181(CONNECTED) 23] ls /kafka/brokers/topics/demo1
[partitions]
[zk: localhost:2181(CONNECTED) 24] ls /kafka/brokers/topics/demo1/partitions
[0]
[zk: localhost:2181(CONNECTED) 25] ls /kafka/brokers/topics/demo1/partitions/0
[state]
[zk: localhost:2181(CONNECTED) 26] ls /kafka/brokers/topics/demo1/partitions/0/state
[]

[zk: localhost:2181(CONNECTED) 27] get /kafka/brokers/topics/demo1
{"removing_replicas":{},"partitions":{"0":[2,1,0]},"topic_id":"D6Lse1d5TduQCu0mh-idwQ","adding_replicas":{},"version":3}

[zk: localhost:2181(CONNECTED) 28] get /kafka/brokers/topics/demo1/partitions/0/state
{"controller_epoch":5,"leader":2,"version":1,"leader_epoch":0,"isr":[2,1,0]}

查看demo1主题详情

kafka-topics.sh --bootstrap-server first-node:9092 --describe demo1 
                                                # 分区数             # 分区副本数              # 分区大小
Topic: demo1	TopicId: D6Lse1d5TduQCu0mh-idwQ	PartitionCount: 1	ReplicationFactor: 3	Configs: segment.bytes=1073741824
	                # 分区开始位置    # 副本中的leader对应的broker   # 分区副本对应的broker（这三个副本分别存储在broker.id=2、broker.id=1、broker.id=0）  
	Topic: demo1	Partition: 0	Leader: 2		            Replicas: 2,1,0 Isr: 2,1,0

生产者和消费者只能针对leader节点进行操做

修改主题demo1分区数为3

kafka-topics.sh --bootstrap-server first-node:9092 --topic demo1 --alter --partitions 3

注意：分区数只能增加，不能减少

[zk: localhost:2181(CONNECTED) 34] ls /kafka/brokers/topics
[demo1]
[zk: localhost:2181(CONNECTED) 35] ls /kafka/brokers/topics/demo1
[partitions]
[zk: localhost:2181(CONNECTED) 36] ls /kafka/brokers/topics/demo1/partitions
[0, 1, 2]
[zk: localhost:2181(CONNECTED) 37] ls /kafka/brokers/topics/demo1/partitions/1
[state]
[zk: localhost:2181(CONNECTED) 38] ls /kafka/brokers/topics/demo1/partitions/1/state
[]

[zk: localhost:2181(CONNECTED) 39] get /kafka/brokers/topics/demo1
{"removing_replicas":{},"partitions":{"2":[1,2,0],"1":[0,1,2],"0":[2,1,0]},"topic_id":"D6Lse1d5TduQCu0mh-idwQ","adding_replicas":{},"version":3}

[zk: localhost:2181(CONNECTED) 40] get /kafka/brokers/topics/demo1/partitions/0/state
					   # 0号分区leader为broker2
{"controller_epoch":5,"leader":2,"version":1,"leader_epoch":0,"isr":[2,1,0]}

[zk: localhost:2181(CONNECTED) 41] get /kafka/brokers/topics/demo1/partitions/1/state
                       # 1号分区leader为broker0 
{"controller_epoch":5,"leader":0,"version":1,"leader_epoch":0,"isr":[0,1,2]}

[zk: localhost:2181(CONNECTED) 55] get /kafka/brokers/topics/demo1/partitions/2/state
					   # 2号分区leader为broker1
{"controller_epoch":5,"leader":1,"version":1,"leader_epoch":0,"isr":[1,2,0]}

[fatpuffer@first-node ~]$ kafka-topics.sh --bootstrap-server first-node:9092 --describe demo1 
Topic: demo1	TopicId: D6Lse1d5TduQCu0mh-idwQ	PartitionCount: 3	ReplicationFactor: 3	Configs: segment.bytes=1073741824
	Topic: demo1	Partition: 0	Leader: 2	Replicas: 2,1,0	Isr: 2,1,0
	Topic: demo1	Partition: 1	Leader: 0	Replicas: 0,1,2	Isr: 0,1,2
	Topic: demo1	Partition: 2	Leader: 1	Replicas: 1,2,0	Isr: 1,2,0

生产者向broker中的demo1主题发送一条消息

kafka-console-producer.sh --bootstrap-server first-node:9092 --topic demo1

消费者连接broker，并且监听deno1主题，broker监控到demo1主题中有消息产生，则将该消息推送给所有demo1主题的监听者

kafka-console-consumer.sh --bootstrap-server first-node:9092 --topic demo1

# --from-beginning可以获取历史数据
kafka-console-consumer.sh --bootstrap-server first-node:9092 --topic demo1 --from-beginning

发送带key的消息

kafka-console-producer.sh --bootstrap-server first-node:9092 --topic demo1 --producer-property parse.key=true

键值之间使用tab键分割

8.生产者（producer）

8.1发送原理

在消息发送过程中，涉及到了两个线程，main线程和sender线程。在main线程中创建了一个双端队列：RecordAccumulator。main线程将消息发送给：RecordAccumulator，sender线程不断从：RecordAccumulator中拉取消息发送到：Kafka Broker

8.2API发送流程

创建配置对象
向配置对象写入kafka集群连接信息
向配置对象写入序列化信息
根据配置对象，创建生产者对象
使用生产者对象发送数据
关闭生产者对象

kafka-python：https://kafka-python.readthedocs.io/en/master/apidoc/KafkaConsumer.html

8.3生产者分区

8.3.1分区好处

便于合理使用存储资源，每个Partion在一个Broker上存储，可以把海量的数据按照分区切割成一块一块数据存储在多台Broker上。合理控制分区的任务，可以实现负载均衡的效果。
提高并行度，生产者可以以分区为单位发送数据；消费者可以以分区为单位进行消费数据

8.3.2生产者发送消息的分区策略

在发送消息时指定了分区，则所有消息发送到该分区
在发送消息时未指定分区，但指定了key
- 将key的hash值与topic的partition数进行取余得到partition值
  - 例如：key1的hash值为5，key2的hash值为6，topic的partition数为2，那么key1对应的value1就写入1号分区，key2对应的value2写入0号分区
在发送消息时未指定分区，也未指定key
- Kafka采用Sticky Partition(黏性分区器)，会随机选择一个分区，并尽可能一直使用该分区，等待该分区的batch.size已满或已完成，Kafka再随机一个分区进行使用（和上一次的分区不同）
  - 例如：第一次随机选择0号分区，等0号分区当前批次（batch.size）已经满了（默认16k），或者linger.ms设置的时间到了，Kafka再随机选择一个分区进行使用（如果是0，还会继续随机）
  - Java：hashcode------------------------->Python：ord("a")

8.3.3自定义分区器

根据发送数据内容进行过滤，将不同类型数据发送到不同分区

8.4提高吞吐量

1.主要涉及两个参数的调优，当linger.ms时常，越接近batch.size：16kb，则效率越高
- 1.batch.size：传输量，16或32
- 2.linger.ms：延迟，5-10ms
2.数据压缩
- compression.type：压缩snappy
3.RecordAccumulator：缓冲区大小，修改为64M

8.5数据可靠性

8.5.1生产者发送过来数据就不管了：`ack=0`，可靠性差，效率高

8.5.2可靠性总结

acks=0，生产者发送过来数据就不管了，可靠性差，效率高
acks=1，生产者发送过来数据，Leader（落盘）应答，可靠性中等，效率中等
acks=-1，生产者发送过来数据，Leader和ISR队列里面的所有Follower应答，可靠性高，效率低
生产环境中，acks=0很少使用；acks=1一般使用传输普通日志，允许丢个别；acks=-1一般用于和钱相关的数据，对可靠性要求比较高的场景。

8.5.2数据重复

1.产生原因

acks=-1(all)：生产者发送过来的数据，Leader和ISR队列里面的所有节点收齐后应答
- 重复原因分析：当Leader收到消息，且已经被其他ISR队列中的Follower同步完成，但是再应答生产者时，Leader挂了，Kafka重新选举出Leader。生产者未收到应答，会再次发送数据，新的Leader拿到数据后，其他ISR队列中的Follower又来拉取一次数据，此时数据就出现了重复。

2.数据传递语义

至少一次（At Least Once）：ACK级别设置为-1 + 分区副本大于等于2 + ISR里应答得最小副本数大于等于2
最多一次（At Most Once）：ACK级别设置为0

3.总结

At Least Once：可以保证数据不丢失，但是不能保证数据不重复
At Most Once：可以保证数据不重复，但是不能保证数据不丢失

4.精确一次（Exact Once）

对于一些非常重要的信息，比如和钱相关的数据，要求数据既不能重复，也不能丢失
Kafka 0.11版本以后，引入了一项重大特性：幂等性和事务

5.幂等性原理

幂等性就是指Producer不论向Broker发送多少次重复数据，Broker端都只会持久化一条，保证了不重复。
精确一次（Exact Once）= 幂等性 + 至少一次（At Least Once）（ack = -1 + 分区副本数 >= 2 + ISR最小副本数 >= 2）

6.重复判断的标准

具有相同主键的消息提交时，Broker只会持久化一条。
- PID是kafka每次重启都会分配一个新的；
- Partition标识分区号；
- Sequence Number是单调自增的。
所以幂等性只能保证的是在单分区单会话内不重复

7.开启幂等性

enable.idempotence，默认为true，false为关闭

8.6事务

1.为什么要使用事务

幂等性只能保证单分区、单会话内数据不重复，一旦kafka挂掉，重启后PID就会变化，此时就无法保证数据不重复
如果分区号变化，也依然无法保证数据不重复

2.事务原理

开启事务，必须开启幂等性

3.API操做

8.7.数据有序

8.8.数据乱序

kafka在1.x版本之前，保证数据单分区有序，条件如下：
- max.in.flight.requests.per.connection=1(不需要考虑是否开启幂等性)
kafka在1.x版本之后，保证数据单分区有序，条件如下：
- 1.未开启幂等性
  - max.in.flight.requests.per.connection=1
- 2.开启幂等性
  - max.in.flight.requests.per.connection需要设置小于等于5
  - 原因说明：因为在kafka1.x之后，启用幂等后，kafka服务端会缓存producer发来的最近5个request的元数据，故无论如何，都可以保证最近的5个request的数据是有序的（根据序列号单调递增，如果有序，直接落盘，遇到无序的，先缓存内存中）

9.Broker

9.1.1ZK存储Kafka信息

9.2Broker工作流程

9.3节点服役退役

9.3.1服役新节点

准备新节点
- 1.基于历史节点克隆（克隆前关机克隆目标节点）
- 2.修改IP地址
- 3.修改主机名hostname
- 4.重新启动克隆目标节点和克隆节点
- 5.修改克隆后节点kafka配置文件中的broker.id
- 6.删除克隆后节点kafka数据文件（datas和logs）
- 7.启动原有集群
- 8.单独启动新克隆节点的kafka

执行负载均衡（历史主题等数据，不会出现在新节点上，所以需要使用负载均衡来迁移）

1.创建一个要均衡的主题：vim topics-to-move.json

{
	"topics": [
		"topic": "demo1"
	],
	"version": 1
}

2.生成一个负载均衡计划

/opt/module/kafka/bin/kafka-reassign-partitions.sh --bootstrap-server first-node:9092 --topics-to-move-json-file topics-to-move.json --broker-list "0,1,2,3" --generate

3.创建副本存储计划（所有副本存储在broker0、broker1、broker2、broker3中）：vim increase-replication-factor.json

来源于上述命令生成结果：Proposed partition reassignment configuration

{"version":1, "partitions":[{"topics":"demo1", "partition":0, "replicase":[3, 1], "log_dirs":["any", "any"]}, {"topics":"demo1", "partition":1, "replicase":[0, 2], "log_dirs":["any", "any"]}, {"topics":"demo1", "partition":2, "replicase":[1, 3], "log_dirs":["any", "any"]}, {"topics":"demo1", "partition":3, "replicase":[2, 0], "log_dirs":["any", "any"]}, {"topics":"demo1", "partition":4, "replicase":[3, 2], "log_dirs":["any", "any"]}, {"topics":"demo1", "partition":5, "replicase":[0, 3], "log_dirs":["any", "any"]}, {"topics":"demo1", "partition":6, "replicase":[1, 0], "log_dirs":["any", "any"]}]}

4.执行副本存储计划

/opt/module/kafka/bin/kafka-reassign-partitions.sh --bootstrap-server first-node:9092 --reassignment-json-file increase-replication-factor.json --execute

出现Successfully started...即表示执行成功

5.验证副本存储计划

/opt/module/kafka/bin/kafka-reassign-partitions.sh --bootstrap-server first-node:9092 --reassignment-json-file increase-replication-factor.json --verify

9.3.1退役旧节点

执行负载均衡操做（将要退役节点数据迁移到其他节点）

1.创建一个要均衡的主题：vim topics-move.json

{
	"topics": [
		"topic": "demo1"
	],
	"version": 1
}

2.创建执行计划

/opt/module/kafka/bin/kafka-reassign-partitions.sh --bootstrap-server first-node:9092 --topics-to-move-json-file topics-to-move.json --broker-list "0,1,2" --generate

3.创建副本存储计划（所有副本存储在broker0、broker1、broker2中）：vim increase-replication-factor.json

{"version":1, "partitions":[{"topics":"demo1", "partition":0, "replicase":[2, 0, 1], "log_dirs":["any", "any", "any"]}, {"topics":"demo1", "partition":1, "replicase":[0, 1, 2], "log_dirs":["any", "any", "any"]}, {"topics":"demo1", "partition":2, "replicase":[1, 2, 0], "log_dirs":["any", "any", "any"]}]}

4.执行副本存储计划

/opt/module/kafka/bin/kafka-reassign-partitions.sh --bootstrap-server first-node:9092 --reassignment-json-file increase-replication-factor.json --execute

出现Successfully started...即表示执行成功

5.验证副本存储计划

/opt/module/kafka/bin/kafka-reassign-partitions.sh --bootstrap-server first-node:9092 --reassignment-json-file increase-replication-factor.json --verify

停止退役后的kafka节点
```
kafka-server-stop.sh
```

9.4kafka副本

9.4.1副本信息

Kafka副本作用：提高数据可靠性
Kafka默认1个副本，生产环境下一般配置2个，保证数据可靠性，太多副本会增加磁盘存储空间，增加网络传输时长，降低效率
Kafka副本分为Leader和Follower。Kafka生产者只会把数据发往Leader，然后Follower找Leader进行数据同步
Kafka分区中的所有副本系统称为AR(Assigned Repllicas)
- AR = ISR + OSR
ISR：标识和Leader保持同步的Follwer集合，如果Follower长时间未向Leader发送通信请求或同步数据，则该Follower将被踢出ISR队列。该时间的阈值由replica.lag.time.max.ms参数设定，默认30s。Leader发生故障后，就会从ISR中选出新的Leader
OSR：标识Follower和Leader副本同步时，延时过多的副本

9.4.2选举流程

Kafka中有一个Broker的Controller会被选举为Controller Leader，负责管理集群broker的上下线，所有topic的分区副本分配和Leader选举等工作
Controller的信息同步工作是依赖于Zookeeper的
1.启动Broker时，在zookeeper中/kafka/brokers/ids下进行注册
2.每个Broker中的Controller抢先注册zookeeper中的/kafka/controller节点，谁抢到了谁就是controller leader
3.controller leader监听/kafka/broker/ids的变化
4.Broker节点启动过半后，Controller开始选举Leader
- 选举规则：在ISR中存活为前提，按照AR中排在前面的优先。例如：ar[1, 0 ,2]，isr[1, 0, 2]，那么leader就会按照1，0，2的顺序轮询
5.Controller选举出Leader后，开始向zookeeper的/kafka/brokers/topics/demo1/partitions/0/state节点写入信息
6.其他Broker上的Controller从zookeeper上同步相关信息，防止成为leader的Controller意外挂掉
7.假首次选举出的leader位于Broker1，此时如果Broker1上的Leader意外挂了
8.此时Controller监测到/kafka/brokers/ids上的变化
9.Controller从/kafka/brokers/topics/demo1/partitions/0/state节点获取ISR信息
10.再次按照选举规则，开始新一轮选举
11.选举完成后更新/kafka/brokers/topics/demo1/partitions/0/state节点信息（主要是leader，isr）

9.4.3手动调整分区副本存储

9.4.3.1原因

在生产环境中，每台服务器的配置和性能可能不一致，但是kafka只会根据自己的代码规则创建对应的分区副本，就会导致个别性能低的服务器存储压力较大，所以需要手动调整分区副本的存储
需求：创建一个新的topic，4个分区，2个副本，名称为demo2，将该topic的所有副本都存储到broker0和broker1两台服务器上

9.4.3.2流程

创建demo2主题

kafka-topics.sh -bootstrap-server first-node:9092 --create --topic demo2 --partitions 4 --replication-factor 2

查看分区副本存储情况

kafka-topics.sh -bootstrap-server first-node:9092 --describe --topic demo2

Topic: demo2	Topicld: -tfY5h@3Rg236b6sooxs7g	PartitionCount: 4	ReplicationFactor: 2	configs; segment. bytes=1073741824

Topic: demo2	Partition: 0	Leader: 2	Replicas: 2,0	Isr: 2,0
Topic: demo2	Partition: 1	Leader: 3	Replicas: 3,2	Isr: 3,2
Topic: demo2	Partition: 2	Leader: 1	Replicas: 1,3	Isr: 1,3
Topic: demo2	Partition: 3	Leader: 0	Replicas: 0,1	Isr: 0,1

创建副本存储计划（将所有副本都指定存储在broker0和broker1中）：vim increase-replication-factor.json

{
	"version": 1,
	"partitions": [
		{"topic": "demo2", "partition": 0, "replicas": [0, 1]},
		{"topic": "demo2", "partition": 1, "replicas": [0, 1]},
		{"topic": "demo2", "partition": 2, "replicas": [0, 1]},
		{"topic": "demo2", "partition": 3, "replicas": [0, 1]},
	]
}

执行副本存储计划

kafka-reassign-partitions.sh -bootstrap-server first-node:9092 --reassignment-json-file increase-replication-factor.json --execute

验证副本存储计划

kafka-reassign-partitions.sh -bootstrap-server first-node:9092 --reassignment-json-file increase-replication-factor.json --verify

查看分区副本存储情况

kafka-topics.sh -bootstrap-server first-node:9092 --describe --topic demo2

9.4.4自动平衡（Leader Partition）

正常情况下，kafka本身会自动把Leader Partition平均分散在各个机器上，来保证每台机器的读写吞吐量都是均匀的。但是如果某些broker宕机，会导致Leader Partition过于集中在其他少部分几台broker上，这会导致少数几台broker的读写请求压力过高，其他宕机broker重启后都是follower partition，读写请求很低，造成负载不均衡。
auto.leader.rebalance.enable：默认是true。自动平衡（如果机器性能不一致，且做了手动调整分区存储，那么不建议将其设置为true）
- 频繁触发自动平衡，是需要消耗大量资源的
leader.imbalance.per.broker.percentage：每个broker允许的不平衡leader的比率，默认10%，如果超过这个值，控制器会触发leader的平衡
leader.imbalance.check.interval.seconds：检查leader负载是否平衡的间隔时间。
示例如下：
红色圈起来的部分，Leader和AR顺序排列不符，说明集群中有broker曾宕机过
针对broker0节点，分区2的AR优先副本是0节点，但是0节点却不是leader节点，所以不平衡数+1，AR副本总数是4
所以broker0节点的不平衡率为：1/4=25%，大于10%，会触发再平衡
broker2和broker3节点和broker0节点不平衡率一样，也会触发再平衡，broker1的不平衡数为0，不需要再平衡

9.4.5增加副本因子

9.4.5.1原因

在生产环境中，由于某个主题的重要等级需要提升，我们考虑增加副本，副本数的增加需要先制定计划，然后根据计划执行

9.4.5.2流程

创建topic

kafka-topics.sh -bootstrap-server first-node:9092 --create --topic demo3 --partitions 3 --replication-factor 1

手动增加副本存储，创建副本存储计划（所有副本都指定存储在broker0、broker1、broker2中）：vim increase-replication-factor.json

	{
		"version": 1,
		"partitions": [
			{"topic": "demo3", "partition": 0, "replicas": [0, 1, 2]},
			{"topic": "demo3", "partition": 1, "replicas": [0, 1, 2]},
			{"topic": "demo3", "partition": 2, "replicas": [0, 1, 2]}
		]
	}