fakak详解（2）

Kafka和Flume整合

Kafka与flume整合流程

Kafka整合flume流程图

flume主要是做日志数据(离线或实时)地采集。

图-21 数据处理

图-21显示的是flume采集完毕数据之后，进行的离线处理和实时处理两条业务线，现在再来学习flume和kafka的整合处理。

配置flume.conf文件

配置如下：

//为我们的source channel sink起名

a1.sources = r1

a1.channels = c1

a1.sinks = k1

//指定我们的source收集到的数据发送到哪个管道

a1.sources.r1.channels = c1

//指定我们的source数据收集策略

a1.sources.r1.type = spooldir

a1.sources.r1.spoolDir = /opt/module/flumedata

a1.sources.r1.deletePolicy = never

a1.sources.r1.fileSuffix = .COMPLETED

a1.sources.r1.ignorePattern = ^(.)*\\.tmp$

a1.sources.r1.inputCharset = UTF-8

//指定我们的channel为memory,即表示所有的数据都装进memory当中

a1.channels.c1.type = memory

//指定我们的sink为kafka sink，并指定我们的sink从哪个channel当中读取数据

a1.sinks.k1.channel = c1

a1.sinks.k1.type = org.apache.flume.sink.kafka.KafkaSink

a1.sinks.k1.kafka.topic = hadoop

a1.sinks.k1.kafka.bootstrap.servers = hadoop101:9092,hadoop102:9092,hadoop103:9092

a1.sinks.k1.kafka.flumeBatchSize = 20

a1.sinks.k1.kafka.producer.acks = 1

启动flume和kafka的整合测试

1)消费者监听读取的数据。

[root@hadoop102 kafka]$ bin/kafka-console-consumer.sh \

--topic test \

--bootstrap-server hadoop101:9092,hadoop102:9092,hadoop103:9092 \

--from-beginning

2)启动flume-agent。

[root@hadoop101 flume]$ bin/flume-ng agent --conf conf --conf-file conf/flume_kafka.conf --name a1 -Dflume.root.logger=INFO,console

3)发送与接收数据验证。

4)验证结果：显示的发送与接收数据，可以说明flume和kafka的整合成功。

Kafka架构

Kafka内部分析

Kafka架构图

通常，一个典型的Kafka集群中包含若干Producer(可以是web前端产生的Page View，或者是服务器日志，系统CPU、Memory等)，若干broker(Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高)，若干Consumer Group，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息，如图-22所示。

图-22 kafka架构

Kafka分布式模型

kafka分布式主要是指分区被分布在多台server(broker)上，同时每个分区都有leader和follower(不是必须)，即老大和小弟的角色，这儿是老大负责处理，小弟负责同步，小弟可以变成老大，形成分布式模型。

kafka的分区日志(message)被分布在kafka集群的服务器上，每一个服务器处理数据和共享分区请求。每一个分区是被复制到一系列配置好的服务器上来进行容错。

每个分区有一个server节点来作为leader和零个或者多个server节点来作为followers。leader处理指定分区的所有读写请求，同时follower被动复制leader。如果leader失败，follwers中的一个将会自动地变成一个新的leader。每一个服务器都能作为分区的一个leader和作为其它分区的follower，因此kafka集群能被很好地平衡。kafka集群是一个去中心化的集群。官网:http://kafka.apache.org/intro.html//intro_distribution。

kafka消费的并行度就是kaka topic分区的个数，或者分区的个数决定了同一时间同一消费者组内最多可以有多少个消费者消费数据。

如图-23所示。

图-23 kafka生产消费模型

Kafka文件存储

Kafka文件存储结构，可以通过图-24说明清楚。

图-24 kafka文件存储模型

在kafka集群中，分单个broker和多个broker。每个broker中有多个topic，topic数量可以自己设定。在每个topic中又有1到多个partition，每个partition为一个分区。kafka分区命名规则为topic的名称+有序序号，这个序号从0开始依次增加。

每个partition中有多个segment file。创建分区时，默认会生成一个segment file，kafka默认每个segment file的大小是1G。当生产者往partition中存储数据时，内存中存不下了，就会往segment file里面刷新。在存储数据时，会先生成一个segment file，当这个segment file到1G之后，再生成第二个segment file 以此类推。每个segment file对应两个文件，分别是以.log结尾的数据文件和以.index结尾的索引文件。在服务器上，每个partition是一个目录，每个segment是分区目录下的一个文件。

每个segment file也有自己的命名规则，每个名字有20个字符，不够用0填充。每个名字从0开始命名，下一个segment file文件的名字就是，当前segment file中.log文件中第一条数据的offset。

在.index文件中，存储的是key-value格式的，key代表在.log中按顺序开始第n条消息，value代表该消息的位置偏移。但是在.index中不是对每条消息都做记录，它是每隔一些消息记录一次，避免占用太多内存。即使消息不在index记录中，在已有的记录中查找，范围也大大缩小了。

.index中存放的消息索引是一个稀疏索引列表。

topic中的partition

为什么要分区

可以想象，如果一个topic就一个分区，要是这个分区有1T数据，那么kafka就想把大文件划分到更多的目录来管理，这就是kafka所谓的分区。

分区的好处

1)方便在集群中扩展。因为一个topic由一个或者多个partition构成，而每个节点中通常可以存储多个partition，这样就方便分区存储与移动，也就增加其扩展性。同时也可以增加其topic的数据量。

2)可以提高并发。因为一个主题多个partition，而每个主题读写数据时，其实就是读写不同的partition，所以增加其并发。

单节点partition的存储分布

Kafka集群只有一个broker，默认/var/log/kafka-log为数据文件存储根目录，在Kafka broker中server.properties文件配置(参数log.dirs=/opt/module/kafka/data)，例如创建2个topic名称分别为test-1、test-2, partitions数量都为partitions=4。

存储路径和目录规则为：

|--test-1-0

|--test-1-1

|--test-1-2

|--test-1-3

|--test-2-0

|--test-2-1

|--test-2-2

|--test-2-3

在Kafka文件存储中，同一个topic下有多个不同partition，每个partition为一个目录，partiton命名规则为:topic名称+分区编号(有序)，第一个partiton序号从0开始，序号最大值为partitions数量减1。

多节点partition存储分布

Kafka多节点partition存储分布如图-25所示。

图-25 kafka多节点partition存储

数据分配策略

前面已经讲过了。

1)如果指定了partition，进入该partition。

2)如果没有指定该partition，但是指定key，通过key的字节数组信息的hashcode值和partition数求模确定partition。

3)如果都没有指定，通过轮询方式进入对应的partition。

Kafka的发送与存储策略

partition中文件存储

如图-26是一个partition-0的一个存储示意图。

图-26 partition存储

1)每个分区一个目录，该目录中是一堆segment file(默认一个segment是1G)，该目录和file都是物理存储于磁盘。

2)每个partition(目录)相当于一个巨型文件被平均分配到多个大小相等segment(段)数据文件中。但每个段segment file消息数量不一定相等，这种特性方便old segment file快速被删除。

3)每个partiton只需要支持顺序读写就行了，segment文件生命周期由服务端配置参数决定。

4)这样做的好处就是能快速删除无用文件，有效提高磁盘利用率。

kafka分区中的segemnt

通过上一节我们知道Kafka文件系统是以partition方式存储，下面深入分析partitiion中segment file组成和物理结构，如图-27和图-28。

图-27 partition物理目录组成

索引文件与数据文件的关系

既然它们是一一对应成对出现，必然有关系。索引文件中元数据指向对应数据文件中message的物理偏移地址

比如索引文件中3,497代表：数据文件中的第三个message,它的偏移地址为497。再来看数据文件中，Message 368772表示：在全局partiton中是第368772个message。

注：segment index file采取稀疏索引存储方式，它减少索引文件大小，通过mmap可以直接内存操作，稀疏索引为数据文件的每个对应message设置一个元数据指针,它比稠密索引节省了更多的存储空间，但查找起来更耗时。

图-28 segment文件物理结构

通过上面两张图，我们已经知道topic、partition、segment、.log、.index等文件的关系，下面深入看看segment相关组成原理。

1)segment file组成：由2大部分组成，分别为index file和log file(即数据文件)，这2个文件一一对应，成对出现，后缀".index"和“.log”分别表示为segment索引文件、数据文件。

2)segment文件命名规则：partition全局的第一个segment从0开始，后续每个segment文件名为当前segment文件段.log文件当中第一条数据的offset。数值最大为64位long大小，20位数字字符长度，不够的左边用0填充。

3)查看segment文件内容如下：

查看.log脚本：

${KAFKA_HOME}/bin/kafka-run-class.sh kafka.tools.DumpLogSegments \

--files 00000000000000000000.log --print-data-log

结果：

Starting offset: 0

offset: 0 position: 0 CreateTime: 1577994283622 isvalid: true keysize: -1 valuesize: 1 magic: 2 compresscodec: NONE producerId: -1 producerEpoch: -1 sequence: -1 isTransactional: false headerKeys: [] payload: a

offset: 1 position: 69 CreateTime: 1577994466159 isvalid: true keysize: -1 valuesize: 1 magic: 2 compresscodec: NONE producerId: -1 producerEpoch: -1 sequence: -1 isTransactional: false headerKeys: [] payload: 1

offset: 2 position: 138 CreateTime: 1577994474463 isvalid: true keysize: -1 valuesize: 1 magic: 2 compresscodec: NONE producerId: -1 producerEpoch: -1 sequence: -1 isTransactional: false headerKeys: [] payload: 4

查看.index脚本：

${KAFKA_HOME}/bin/kafka-run-class.sh kafka.tools.DumpLogSegments \

--files 00000000000000000000.index --print-data-log

结果：

Dumping 00000000000000000000.index

offset: 0 position: 0

Kafka中的push和pull

一个较早问题是我们应该考虑是消费者从broker中pull数据还是broker将数据push给消费者。kakfa遵守传统设计和借鉴很多消息系统，这儿kafka选择producer向broker去push消息，并由consumer从broker pull消息。一些logging-centric system，比如Facebook的Scribe和Cloudera的Flume,采用非常不同的push模式。事实上，push模式和pull模式各有优劣。

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

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

kafka中数据发送保障

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

图-29 数据发送流程

副本数据同步策略：

表-1 同步策略

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

Kafka选择了第二种方案，原因如下：

1)同样为了容忍n台节点的故障，第一种方案需要2n+1个副本，而第二种方案只需要n+1个副本，而Kafka的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。

2)虽然第二种方案的网络延迟会比较高，但网络延迟对Kafka的影响较小。

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

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

需要注意的是：

1)生产者发送到特定主题分区的消息是将按照发送的顺序来追加。也就是说，如果消息M1和消息M2由相同的生产者发送，并且M1是先发送的，那么M1的偏移量将比M2低，并出现在日志的前面。

2)消费者是按照存储在日志中记录顺序来查询消息。

3)对于具有n个副本的主题，我们将容忍最多N-1个服务器失败故障，从而不会丢失提交到日志的任何消息记录。

ack应答机制

对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等ISR中的follower全部接收成功。

所以Kafka为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置，如图-30所示。

图-30 ack应答机制

故障处理细节，如图-31所示。

图-31 故障处理机制

故障机制分为了follower和leader故障，如图-31所示的，具体解释如下：

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同步数据。

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

Kafka msg flush and retention

Flush策略

# Log Flush Policy

# Messages are immediately written to the filesystem but by default we only fsync() to sync

# the OS cache lazily. The following configurations control the flush of data to disk.

# There are a few important trade-offs here:

# 1. Durability: Unflushed data may be lost if you are not using replication.

# 2. Latency: Very large flush intervals may lead to latency spikes when the flush does occur as there will be a lot of data to flush.

# 3. Throughput: The flush is generally the most expensive operation, and a small flush interval may lead to excessive seeks.

# The settings below allow one to configure the flush policy to flush data after a period of time or

# every N messages (or both). This can be done globally and overridden on a per-topic basis.

# The number of messages to accept before forcing a flush of data to disk

// 每当每一个topic接收到10000条message的时候，就会将数据flush到磁盘

log.flush.interval.messages=10000

# The maximum amount of time a message can sit in a log before we force a flush

//每隔1s flush一次数据

log.flush.interval.ms=1000

为了提供kafka的读写数据能力，首先接收数据到kafka内存，不可能无限制的保存在内存，所以必然会将数据flush到磁盘(partition的segement)文件，在flush的时候做了Durability(持久性)和Latency(延迟)和Throughput(吞吐量)的权衡与取舍。

Retention策略

# Log Retention Policy

# The following configurations control the disposal of log segments. The policy can

# be set to delete segments after a period of time, or after a given size has accumulated.

# A segment will be deleted whenever *either* of these criteria are met. Deletion always happens

# from the end of the log.

# The minimum age of a log file to be eligible for deletion due to age

// 日志最小的保留时间：7天，超过这个时间，数据可能会被清理掉

log.retention.hours=168

//log.retention.days=7

# A size-based retention policy for logs. Segments are pruned(裁剪) from the log unless the remaining

# segments drop below log.retention.bytes. Functions independently of log.retention.hours.

// segement文件如果超过log.retention.bytes的配置，将会可能被裁剪，直到小于log.retention.bytes配置

#log.retention.bytes=1073741824

# The maximum size of a log segment file. When this size is reached a new log segment will be created.

// 一个segment文件最大的大小，超过log.segment.bytes一个G，将会创建一个新的segment文件

log.segment.bytes=1073741824

# The interval at which log segments are checked to see if they can be deleted according

# to the retention policies

// 每隔5分钟，检测一次retention策略是否达到

log.retention.check.interval.ms=300000

partition对应的文件，就保存在一个个的segment文件中，每一个文件默认大小是1G，但是log.retention.check.interval.ms监测频率是5分钟一次。

所以segment文件可能会超过1G，此时就会启动retion策略，将文件裁剪到log.retention.bytes配置，如果超过了log.segment.bytes=1G配置，将会创建一个新的segment文件；默认情况，segment文件会保留7天。

Kafka高性能之道

Kafka高性能原因

高效使用磁盘

1)顺序写磁盘，顺序写磁盘性能高于随机写内存。

2)Append Only 数据不更新，无记录级的数据删除(只会整个segment删s除)。读操作可直接在page cache内进行。如果进程重启，JVM内的cache会失效，但page cache仍然可用。

3)充分利用Page Cache：I/O Scheduler将连续的小块写组装成大块的物理写从而提高性能。I/O Scheduler会尝试将一些写操作重新按顺序排好，从而减少磁盘头的移动时间。

4)充分利用所有空闲内存(非JVM内存)：应用层cache也会有对应的page cache与之对应，直接使用pagecache可增大可用cache，如使用heap内的cache，会增加GC负担

5)可通过如下参数强制flush，但并不建议这么做。

log.flush.interval.messages=10000

log.flush.interval.ms=1000

6)支持多Directory(目录)。

零拷贝

传统方式实现：

先读取、再发送，实际经过 1~4 四次 copy。

分别是：

第一次：将磁盘文件，读取到操作系统内核缓冲区；

第二次：将内核缓冲区的数据，copy 到 application 应用程序的 buffer；

第三步：将 application 应用程序 buffer 中的数据，copy 到 socket 网络发送缓冲区(属于操作系统内核的缓冲区)；

第四次：将 socket buffer 的数据，copy 到网卡，由网卡进行网络传输。

kafka 作为 MQ 也好，作为存储层也好，无非是两个重要功能，一是 Producer 生产的数据存到 broker，二是 Consumer 从 broker 读取数据；我们把它简化成如下两个过程：

网络数据持久化到磁盘 (Producer 到 Broker)

磁盘文件通过网络发送（Broker 到 Consumer）

批处理和压缩

1)Producer和Consumer均支持批量处理数据，从而减少了网络传输的开销。

2)Producer可将数据压缩后发送给broker，从而减少网络传输代价。目前支持Snappy，Gzip和LZ4压缩。

Partition

1)通过Partition实现了并行处理和水平扩展。

2)Partition是Kafka(包括kafka Stream)并行处理的最小单位。

3)不同Partition可处于不同的Broker，充分利用多机资源。

4)同一Broker上的不同Partition可置于不同的Directory。

ISR

1)ISR(in-sync-replica)实现了可用性和一致性的动态平衡。

//如果这个时间内follower没有发起fetch请求，被认为dead，从ISR移除

replica.log.time.max.ms=10000

//如果follower相比leader落后这么多以上消息条数，会被从ISR移除

replica.log.max.messages=4000

2)ISR可容忍更多的节点失败：Majority Quorum如果要容忍f个节点失败，至少需要2f+1个节点(zookeeper，journalnode)。ISR如果要容忍f个节点失败，至少需要f+1个节点。

3)如何处理Replica Crach：Leader crash后，ISR中的任何replica皆可竞选成为Leader。如果所有replica都crash，可选择让第一个recover的replica或者第一个在ISR中的replica成为leader。unclean.leader.election.enable=true