本节主要内容

数据写入流程

分区策略

ACK应答机制

leader异常处理

follower异常处理

数据写入流程

数据写入流程(图1)

1、确定分区，producer确认数据写入哪个分区

2、发送数据，到leader分区

3、leader写入完成，follower分区从leader分区拉取数据

4、确定数据是否写入成功

成功

5、返回ack给producer

6、producer接收到ack，数据写入成功，继续发送下一批数据

失败

7、数据没有写入成功，producer重发数据

图1

分区策略

分区原因

1、方便扩展

2、提高并发

分区原则

1、指明partition的情况下，直接发送数据到对应的partition

2、没有指明partition，但有key的情况下，将key的hash值与topic的partition数进行取余得到partition值。

3、既没有指明partition，又没有key的情况下，第一次随机生成一个整数，之后每次调用都在这个整数上自增，将该值与可用的partitions总数取余得到partition值，即round-robin算法

ACK应答机制

acks参数配置，提供以下三个选项

0：producer不等待ack，不管是否写入成功，能提供最低延迟，会丢数据

1：producer等待ack，leader写入成功返回ack，不管follower是否写入成功，会丢失数据

-1：producer等待ack，leader和follower全部写入成功返回ack，极端情况下，如果follower同步完成后，发送ack之前，leader发生故障，会造成数据重复。

leader异常情况处理

leader异常，需要解决两个问题

1.读一致性

2. 写一致性

先解释两个概念： LEO与HW(图2)

LEO - Log End Offset，每个副本最后一个offset

HW - High Watermark，所有副本中，最小的LEO

图2

leader异常，读一致性问题(图3)

问题描述

leader和follower当前存储数据状况：leader当前数据记录到 9, follower 0同步完成7, follower 1同步完成8

1、consumer从leader读取数据消费到9

2、leader故障

3、重新选举follower1 为leader

新leader中记录数据只到8，消费者无法继续消费9以后的数据

解决方案

Consumer只能读取 HW之前的数据，当leader发生故障时，不会影响consumer读取数据

图3

leader异常，写一致性问题(图4)

问题描述

1、leader故障

2、重新选举follower1 为leader

3、原来的leader恢复正常，变为follower 1，此刻，其数据是9，大于新leader的8

这种情况下follower如何从leader同步数据？

解决方案

4、follower 1读取HW，将HW这后的数据删除，从leader拉取数据，起始位置为8

图4

follower异常(图5)

问题描述

ack配置为-1时，需要确定所有follower写成功才能返回ack，如果单个follower挂掉，leader需要一直等待，直到follower写入成功，影响数据写入

解决方案

Leader动态维护ISR(in-sync replica set)，记录和leader保持正常同步的follower集合，保证ISR中的follower全部写入成功即可发送ack。

当follower在限定时间内(通过参数replica.log.time.max.ms配置)未从leader拉取数据，则该follower将被踢出ISR。

处理流程

1、leader写入数据完成，follower开始从leader拉取数据

2、follower 1异常，不能从leader正常拉取数据

3、leader在限定时间内未收到follower 1同步请求，确定follower 1异常，从ISR中移除follower 1

4、follower 0完成同步，ISR中记录的follower全部成功

5、返回ack给producer

数据写入成功，继续发送下一批次数据

图5

学习交流，如有问题，请指证，感谢！！！

总结

以上是生活随笔为你收集整理的拉取数据_Apache Kafka-数据写入过程的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。