大数据开发学习1.11-Kafka Broker

老土拨鼠
1,608 阅读5分钟

Kafka Broker工作流程

Kafka Broker工作流程图

Kafka Broker总体工作流程.png

其中，需要注意Leader的选举机制

当Leader挂掉的时候，也就是broker挂掉的时候，Controller监听到zk的/brokers/ids节点下的数据发生变化，此时controller会读取ISR，在ISR表示存活的节点，按照AR中的顺序轮询，前提是该节点在ISR中存活，按照此规则选举出新的Leader

Broker重要参数

  • replica.lag.time.max.ms

ISR中，如果Follower长时间未向Leader发送通信请求或同步数据，则该Follower将被踢出ISR。该时间阈值，默认30s。

  • auto.leader.rebalance.enable

默认是true。 自动Leader Partition 平衡。

  • leader.imbalance.per.broker.percentage

默认是10%。每个broker允许的不平衡的leader的比率。如果每个broker超过了这个值，控制器会触发leader的平衡。

  • leader.imbalance.check.interval.seconds

默认值300秒。检查leader负载是否平衡的间隔时间。

  • log.segment.bytes

Kafka中log日志是分成一块块存储的，此配置是指log日志划分 成块的大小，默认值1G。

  • log.index.interval.bytes

默认4kb，kafka里面每当写入了4kb大小的日志（.log），然后就往index文件里面记录一个索引。

  • log.retention.hours

Kafka中数据保存的时间，默认7天。

  • log.retention.minutes

Kafka中数据保存的时间，分钟级别，默认关闭。

  • log.retention.ms

Kafka中数据保存的时间，毫秒级别，默认关闭。

  • log.retention.check.interval.ms

检查数据是否保存超时的间隔，默认是5分钟。

  • log.retention.bytes

默认等于-1，表示无穷大。超过设置的所有日志总大小，删除最早的segment。

  • log.cleanup.policy

默认是delete，表示所有数据启用删除策略； 如果设置值为compact，表示所有数据启用压缩策略。

  • num.io.threads

默认是8。负责写磁盘的线程数。整个参数值要占总核数的50%。

  • num.replica.fetchers

副本拉取线程数，这个参数占总核数的50%的1/3

  • num.network.threads

默认是3。数据传输线程数，这个参数占总核数的50%的2/3 。

  • log.flush.interval.messages

强制页缓存刷写到磁盘的条数，默认是long的最大值，9223372036854775807。一般不建议修改，交给系统自己管理。

  • log.flush.interval.ms

每隔多久，刷数据到磁盘，默认是null。一般不建议修改，交给系统自己管理。

Kafka 副本

副本基本信息

  • Kafka副本作用：提高数据可靠性。

  • Kafka默认副本1个，生产环境一般配置为2个，保证数据可靠性；太多副本会增加磁盘存储空间，增加网络上数据传输，降低效率

  • Kafka中副本分为：Leader和Follower。Kafka生产者只会把数据发往Leader，然后Follower找Leader进行同步数据

  • Kafka分区中的所有副本统称为AR（Assigned Repllicas） AR = ISR + OSR ISR(In-Sync Replicas)，表示和Leader保持同步的Follower集合。如果Follower长时间未向Leader发送通信请求或同步数据，则该Follower将被踢出ISR。该时间阈值由replica.lag.time.max.ms参数设定，默认30s。Leader发生故障之后，就会从ISR中选举新的Leader。

    OSR(Out-Sync Replicas)，表示Follower与Leader副本同步时，延迟过多的副本(超过replica.lag.time.max.ms参数，默认30s)，了解即可。

Leader和Follower故障处理细节

LEO（Log End Offset）：每个副本的最后一个offset，LEO其实就是最新的offset + 1

HW（High Watermark）：所有副本中最小的LEO

Follower故障

  1. Follower发生故障后会被临时踢出ISR
  2. 这个期间Leader和Follower继续接收数据
  3. 待该Follower恢复后，Follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向Leader进行同步
  4. 等该Follower的LEO大于等于该Partition的HW，即Follower追上Leader之后，就可以重新加入ISR了

Leader故障

  1. Leader发生故障之后，会从ISR中选出一个新的Leader，选举规则如前文的选举规则
  2. 为保证多个副本之间的数据一致性，其余的Follower会先将各自的log文件高于HW的部分截掉，然后从新的Leader同步数据

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

文件存储机制

graph TB
Topic-->Partition0
Topic-->Partition1
Topic-->Partition2
Partition0-->log0[log]
Partition1-->log1[log]
Partition2-->log2[log]
log1-->Segement0[Segement]
log1-->Segement1[Segement]
log1-->Segement2[Segement]
Segement1-->A[000000000000000.index]
Segement1-->B[000000000000000.log]
Segement1-->C[000000000000000.timeindex]

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

高效读写数据

  • Kafka本身是分布式集群，可以采用分区技术，并行度高

  • 读数据采用稀疏索引，可以快速定位要消费的数据

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

  • 页缓存 + 零拷贝技术

    零拷贝：Kafka的数据加工处理操作交由Kafka生产者和Kafka消费者处理。Kafka Broker应用层不关心存储的数据，所以就不用走应用层，传输效率高。

    PageCache页缓存：Kafka重度依赖底层操作系统提供的PageCache功能。当上层有写操作时，操作系统只是将数据写入PageCache。当读操作发生时，先从PageCache中查找，如果找不到，再去磁盘中读取。实际上PageCache是把尽可能多的空闲内存都当做了磁盘缓存来使用。

avatar
文章
阅读
粉丝