kafka操作2

kafka副本

副本的基本信息

• kafka副本的作用，提高数据可靠性。
• kafka默认副本1个，生产环境一般配置2个，保证数据可靠性；太多副本会增加磁盘存储空间，增加网络上数据传输，降低效率。
• kafka副本分为leader和follower，kafka生产者只会把数据发往leader，然后fallower找leader进行同步数据。
• kafka分区中的所有副本统称为AR（Assigned Repllicas）
  ISR，表示和leader保持同步的follower集合，如果follower长时间未向leader发送通信请求或同步数据，则该follower将被踢出ISR。该时间阈值由 replica.lag.time.ms参数设定，默认为30s。leader发生故障之后，就会从ISR中选举新的leader。
  OSR，表示follower与leader副本同步时，延迟过多的副本。

leader选举流程

kafka集群中有一个broker的controller会被选举为controller leader，负责管理集群broker的上下线，所有topic的分区副本分配和leader选举等工作。

• 创建一个新的topic，3个分区，3个副本

bin/kafka-topics.sh --bootstrap-server hadoop101:9092 --create --topic second --partitions 3 --replication-factor 3

• 查看leader分布情况

bin/kafka-topics.sh --bootstrap-server hadoop101:9092 --describe--topic second

• 停止掉hadoopxxx的kafka进程，并查看leader分区情况

bin/kafka-server-stop.sh
bin/kafka-topics.sh --bootstrap-server hadoop101:9092 --describe--topic second

follower故障处理细节

LEO：每个副本的最后一个offset，LEO其实就是最新的offset+1（Log End Offset）
HW：所有副本中最小的LEO（High Watermark）
follower故障：

• follow发生故障后会被临时踢出ISR
• 这个期间leader和follower继续接收数据
• 待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。
• 等该follower的LEO大于等于该Partition的HW，即follower追上leader之后，就可以重新加入ISR了。
  leader故障
• leader发生故障之后，会从ISR中选出一个新的leader
• 为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据。
• 这样只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。

分区副本分配

如果kafka服务器只有三个节点，那么设置kafka的分区数大于服务器台数，在kafka底层如何分配存储副本呢？

• 创建16个分区，3个副本

 ./kafka-topics.sh --bootstrap-server hadoop101:9092 --create --topic second --partitions 16 --replication-factor 3

• 查看分区和副本情况。

./kafka-topics.sh --bootstrap-server hadoop101:9092 --describe --topic second

可以看到分区副本均匀分布

手动调整分区副本储存

在生产环境中，每台服务器的配置和性能不一致，但是kafka只会根据自己的代码规则创建对应的分区副本，就会导致个别服务器的存储压力较大。所有需要手动调整分区副本的存储。手动调整分区副本储存的步骤如下：

• 创建一个新的topic，名称为three

 ./kafka-topics.sh --bootstrap-server hadoop101:9092 --create --topic three --partitions 4 --replication-factor 2

• 查看分区副本存储情况

./kafka-topics.sh --bootstrap-server hadoop101:9092 --describe --topic three

• 创建副本存储计划（所有副本都指定存储在broker0和broker1中）

vim increase-replication-factor.json
# 输入以下内容
{
	"version" : 1,
	"partitions" : [ { "topic" : "three" , "partition" : 0, "replicas" : [0,1]},
	{ "topic" : "three" , "partition" :2, "replicas" : [1,0]},{ "topic" : "three" , "partition" : 3, "replicas" : [1,0]}]
}

• 执行副本存储计划

bin/kafka-reassign-partitions.sh --bootstrap-server hadoop101:9092 --reassignment-json-file increase-replication-factor.json --execute

• 验证副本存储计划

bin/kafka-ressign-partitions.sh --bootstarp-server hadoop101:9092 --reassignment-json-file increase-replication-factor.json --verify

• 查看分区副本存储情况

bin/kafka-ressign-partitions.sh --bootstarp-server hadoop101:9092 --describe --topic three

leader partition自动平衡

• 正常情况下，Kafka本身会自动把Leader Partition均匀分散在各个机器上，来保证每台机器的读写吞吐量都是均匀的。但是如果某些broker宕机，会导致Leader Partition过于集中在其他少部分几台broker上，这会导致少数几台broker的读写请求压力过高，其他宕机的broker重启之后都是follower partition，读写请求很低，造成集群负载不均衡。
  auto.leader.rebalance.enable，默认为true。自动leader partition平衡。
• leader.imbalance.per.broker.percentage，默认是10%。每个broker允许的不平衡leader的比率。如果每个broker超过了这个值，控制器会触发leader的平衡
• leader.imbalance.check.interval.seconds，默认值为300秒。检查leader负载是否平衡的间隔时间

增加副本因子

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

1. 创建topic

bin/kafka-topics.sh --bootstrap-server hadoop101:9092 --create --topic second --partitions 3 --replication-factor 1 --topic four

2. 手动增加副本存储

# 创建副本存储计划（所有副本都指定存储在broker0、broker1和broker2中）
vim increase-replication-factor.json
输入以下内容
{ "version" :1, "partitions" : [ { "topic" : "four" , "partition":0,"replicas" : [0,1,2]},{ "topic" : "four" , "partition" : 1, "replicas" : [0,1,2]},{"topic" : "four" , "partition" :2, "replicas" :[0,1,2]}]}
执行副本存储计划
bin/kafka-reassign-partitions.sh --bootstrap-server hadoop101:9092 --reassignment-json-file increase-replication-factor.json --execute

kafka文件存储机制

Topic是逻辑上的概念，而partition是物理上的概念，每个partition对应于一个log文件，该log文件中存储的就是Producer生产的数据。Producer生产的数据会被不断追加到该log文件末端，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，将每个partition分为多个segment。每个segment包括: “.index”文件、”.log”文件和.timeindex等文件。这些文件位于一个文件夹下，该文件夹的命名规则为: topic名称+分区序号，例如: first-0。
.log日志文件，.index偏移量索引文件，.timeindex时间戳索引文件，其他文件
index和log文件以当前segment的第一条消息的offset命名

 1. 启动生产者，并发送消息
bin/kafka-console-produce.sh --bootstrap-server hadoop101:9092 --topic first
hello world
 2. 查看hadoop101的/opt/module/kafka/datas/first-1路径上的文件
 3. 直接查看log日志是乱码
 4. 通过工具查看index和log信息
kafka-run-class.sh kafka.tools.DumpLogSegment --first ./xxx.index

Log文件和Index文件详解

1. index为稀疏索引，大约每往log文件写入4kb数据，会往index文件写入一条索引。参数log.index.interval.bytes默认为4kb
2. index文件中保存的offset为相对offset，这样能确保offset的值所占空间不会过大，因此能将offset的值控制在固定大小

文件清理策略

kafka中默认的日志保存时间为7天，可以通过调整如下参数修改保存时间

• log.retention.hours，最低优先级小时，默认七天
• log.retention.minutes，分钟
• log.retention.ms，最高优先级毫秒
• log.retention.check.intervel.ms，负责设置检查周期，默认为5分钟
  那么日志一旦超过了设置的时间，怎么处理呢？
  kafka中提供的日志清理策略有delete和compact两种

1. delete日志删除：将过期数据删除

- log.cleanup.policy = delete 所有数据启用删除策略
- 基于时间：默认打开。以segment中所有记录中的最大时间戳作为该文件时间戳
- 基于大小：默认关闭。超过设置的所有日志总大小，删除最早的segment。log.retention.bytes，默认等于-1，表示无穷大。

2. compact日志压缩

compact日志压缩：对于相同的key的不同value值，只保留最后一个版本。
- log.cleanup.policy = compact 所有的数据启用压缩策略

压缩后的offset可能是不连续的，比如上图中没有6，当从这些offset消费消息时，将会拿到比这个offset打的offset对应的消息，实机上会拿到offset为7的消息，并从这个位置开始消费。这种策略只适用于特殊场景，比如消息的key是用户ID，value是用户的资料，通过这种压缩策略，整个消息集里就保存了所有用户最新的资料。

高效读写数据

1. kafka本身是分布式集群，可以采用分区技术，并行度高
2. 读数据采用稀疏索引，可以快速定位要消费的数据
3. 顺序写磁盘。kafka的producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。这与磁盘的机械结构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。
4. 页缓存和零拷贝技术。零拷贝：kafka的数据加工处理操作交由kafka生产者和kafka的消费者处理，kafka应用层不关心存储的数据，所以就不用走应用层，传输效率高。PageCache页缓存，kafka重度依赖底层操作系统提供的PageCache功能，当上层有写操作时，操作系统只是将数据写入PageCache，当读操作发生时，先从PageCache中查找，如果找不到，再从磁盘中读取。实际上PageCache是把尽可能多的空闲内存都当做了磁盘缓存来使用。