第3章、Kafka工作流程分析

一、Kafka工作流程及文件存储机制

1.1、Kafka 工作流程

  1. Kafka中消息是以 topic 进行分类的，生产者生产消息，消费者消费消息，都是面向 topic的。
  2. topic是逻辑上的概念，而partition是物理上的概念，每个partition对应于一个log文件，该log文件中存储的就是producer生产的数据。
  3. Producer生产的数据会被不断追加到该log文件末端，且每条数据都有自己的offset。消费者组中的每个消费者，都会实时记录自己消费到了哪个offset，以便出错恢复时，从上次的位置继续消费。
  4. kafka消息不能保证全局消息有序性，能保证分区内有序。

1.2、Kafka文件存储机制

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

00000000000000000000.index
00000000000000000000.log(存储topic内容 最大默认1G,超过1G，则新建一个，)
00000000000000170410.index
00000000000000170410.log(名字为当前log中最小的偏移量)
00000000000000239430.index
00000000000000239430.log

　　index和log文件以当前segment的第一条消息的offset命名。下图为index文件和log文件的结构示意图。

  • “.index”文件存储大量的索引信息，
  • “.log”文件存储大量的具体数据，索引文件中的元数据指向对应数据文件中message的物理偏移地址。
  • .index”文件中存储的每一条数据的大小相同，通过二分查找，查找速度快。

二、Kafka生产者

2.1、分区策略

2.2.1、分区的原因

  1. 方便在集群中扩展，每个Partition可以通过调整以适应它所在的机器，而一个topic又可以有多个Partition组成，因此整个集群就可以适应任意大小的数据了；
  2. 可以提高并发，因为可以以Partition为单位读写了。

2.2.2、分区的原则

　　我们需要将 producer 发送的数据封装成一个 ProducerRecord 对象。

  1. 指明partition的情况下，直接将指明的值直接作为partiton值；（指明分区）
  2. 没有指明partition值但有key的情况下，将key的hash值与topic的partition数进行取余得到partition值；（没有指定分区，按照key的值和分区数去莫）
  3. 既没有partition值又没有key值的情况下，第一次调用时随机生成一个整数（后面每次调用在这个整数上自增），将这个值与topic可用的partition总数取余得到partition值，也就是常说的round-robin(轮询)算法。（key为空，轮询，第一次不确定）

2.2、数据可靠性保证

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

2.2.1、 副本数据同步策略

方案 优点 缺点

半数以上完成 同步 ， 就发
送 送 ack

 延迟低

选举新的 leader 时，容忍 n 台
节点的故障，需要 2n+1 个副
本

全部完成同步 ，才发送
ack

选举新的 leader 时，容忍 n 台
节点的故障，需要 n+1 个副
本

 延迟高

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

  1. 同样为了容忍n台节点的故障，第一种方案需要2n+1个副本，而第二种方案只需要n+1个副本，而Kafka的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。
  2. 虽然第二种方案的网络延迟会比较高，但网络延迟对Kafka的影响较小。

2.2.2、ISR

  1. 采用第二种方案之后，设想以下情景：leader收到数据，所有follower都开始同步数据，但有一个follower，因为某种故障，迟迟不能与leader进行同步，那leader就要一直等下去，直到它完成同步，才能发送ack。这个问题怎么解决呢？
  2. Leader维护了一个动态的in-syncreplicaset(ISR：同步副本队列)，和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后，leader就会给follower发送ack。
  3. 如果follower长时间未向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.lag.time.max.ms 参数设定。Leader 发生故障之后，就会从 ISR 中选举新的 leader。

2.2.3、ack 解决数据重复/丢失问题

  1. 　　对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等ISR中的follower全部接收成功。
  2. 　　所以Kafka为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置。
  3. 　　acks参数配置：
    • acks：0：producer不等待broker的ack，这种操作提供了最低的延迟，broker一直接收，不做重发，存在没有写入磁盘的情况就已经返回，当broker故障时有可能丢失数据；
    • acks：1：producer等待broker的ack，只等待partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据；下面是acks = 1 数据丢失案例；

    • acks：-1（all）：producer 等待 broker 的 ack，会重试，partition 的 leader 和 follower （ISR的follower，假设有3个follower，一个是在ISR）全部落盘成功后才返回ack。但是如果在 follower 同步完成后，broker 发送 ack 之前，leader 发生故障，那么会造成数据重复。下面时acks = -1 数据重复案例。

2.2.4、 故障处理细节

  •  Log文件中的HW和LEO

  • LEO（最大offset） ：指的是每个副本最大的offset；
  • HW (高水位)：指的是消费者能见到的最大的offset ，ISR队列中最小的LEO 。

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

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

2.3、Exactly Once语义

　　将服务器的ACK级别设置为-1，可以保证Producer到Server之间不会丢失数据，即AtLeastOnce语义。相对的，将服务器ACK级别设置为0，可以保证生产者每条消息只会被发送一次，即AtMostOnce语义。AtLeastOnce可以保证数据不丢失，但是不能保证数据不重复；相对的，AtLeastOnce可以保证数据不重复，但是不能保证数据不丢失。但是，对于一些非常重要的信息，比如说交易数据，下游数据消费者要求数据既不重复也不丢失，即ExactlyOnce语义。在0.11版本以前的Kafka，对此是无能为力的，只能保证数据不丢失，再在下游消费者对数据做全局去重。对于多个下游应用的情况，每个都需要单独做全局去重，这就对性能造成了很大影响。0.11版本的Kafka，引入了一项重大特性：幂等性。所谓的幂等性就是指Producer不论向Server发送多少次重复数据，Server端都只会持久化一条。幂等性结合AtLeastOnce语义，就构成了Kafka的ExactlyOnce语义。即：AtLeastOnce + 幂等性 = Exactly Once

  • 启用幂等性，只需要将Producer的参数中enable.idompotence设置为true即可。
  • Kafka的幂等性实现其实就是将原来下游需要做的去重放在了数据上游。开启幂等性的Producer在初始化的时候会被分配一个PID(ProducerId)，发往同一Partition的消息会附带SequenceNumber。
  • Broker端会对<PID,Partition,SeqNumber>做缓存，当具有相同主键的消息提交时，Broker只会持久化一条。
  • 但是PID重启就会变化，同时不同的Partition也具有不同主键，所以幂等性无法保证跨分区、跨会话的ExactlyOnce。

三、Kafka消费者 

3.1、消费方式

　　consumer采用pull（拉）模式从broker中读取数据。

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

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

3.2、分区分配策略

　　https://www.cnblogs.com/hongdada/p/16921205.html

　　一个 consumer group 中有多个 consumer，一个 topic 有多个 partition，所以必然会涉及到 partition 的分配问题，即确定那个 partition 由哪个 consumer 来消费。

　　Kafka 有两种分配策略，一是 RoundRobin（轮询），一是 Range。

  • 分区分配策略之RoundRobin
    • 消费者组中订阅的toipic要一样

  •  分区分配策略之Range(默认)

3.3、offset的维护

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

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

  •  修改配置文件 consumer.properties
exclude.internal.topics=false
  • 读取 offset
# 0.11.0.0 之前版本:
bin/kafka-console-consumer.sh  --topic  __consumer_offsets  
--zookeeper  broker2:2181  
--formatter "kafka.coordinator.GroupMetadataManager\$OffsetsMessageFormatter"
--consumer.config config/consumer.properties --from-beginning
# 0.11.0.0 之后版本(含):
bin/kafka-console-consumer.sh  --topic  __consumer_offsets  
--zookeeper  broker2:2181  
--formatter "kafka.coordinator.group.GroupMetadataManager\$OffsetsMessageFormatter"  
--consumer.config  config/consumer.properties  --from-beginning

3.4、消费者组案例

　　需求：测试同一个消费者组中的消费者，同一时刻只能有一个消费者消费。

  • 在broker0、broker1上修改/usr/loacl/kafka/config/consumer.properties 配置文件中的 group.id 属性为任意组名。
vim consumer.properties
group.id=jdy
  • 在broker0、broker1分别启动消费者
  • 在broker2上启动生产者
  • 查看 broker0、broker1的接收者。同一时刻只有一个消费者接收到消息。

四、Kafka 高效读写数据

4.1、顺序写磁盘

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

4.2、零复制技术

五、Zookeeper在Kafka中的作用

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

　　Controller 的管理工作都是依赖于 Zookeeper 的。

　　以下为 partition 的 leader 选举过程：

六、Kafka事务

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

6.1、Producer事务

　　为了实现跨分区跨会话的事务，需要引入一个全局唯一的 Transaction ID，并将 Producer获得的PID和Transaction ID绑定。这样当Producer重启后就可以通过正在进行的TransactionID 获得原来的 PID。

　　为了管理Transaction，Kafka引入了一个新的组件TransactionCoordinator。Producer就是通过和TransactionCoordinator交互获得TransactionID对应的任务状态。TransactionCoordinator还负责将事务所有写入Kafka的一个内部Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

6.2、Consumer事务

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

posted @ 2021-02-09 17:02  jingdy  阅读(97)  评论(0)  编辑  收藏  举报