Kafka架构原理，也就这么回事！

“.index” 文件存储大量的索引信息，“.log” 文件存储大量的数据，索引文件中的元数据指向对应数据文件中 Message 的物理偏移量。

生产者

分区策略

分区原因：

方便在集群中扩展，每个 Partition 可以通过调整以适应它所在的机器，而一个 Topic 又可以有多个 Partition 组成，因此可以以 Partition 为单位读写了。

可以提高并发，因此可以以 Partition 为单位读写了。

分区原则：我们需要将 Producer 发送的数据封装成一个 ProducerRecord 对象。

该对象需要指定一些参数：

topic：string 类型，NotNull。

partition：int 类型，可选。

timestamp：long 类型，可选。

key：string 类型，可选。

value：string 类型，可选。

headers：array 类型，Nullable。

①指明 Partition 的情况下，直接将给定的 Value 作为 Partition 的值。

②没有指明 Partition 但有 Key 的情况下，将 Key 的 Hash 值与分区数取余得到 Partition 值。

③既没有 Partition 有没有 Key 的情况下，第一次调用时随机生成一个整数(后面每次调用都在这个整数上自增)，将这个值与可用的分区数取余，得到 Partition 值，也就是常说的 Round-Robin 轮询算法。

数据可靠性保证

为保证 Producer 发送的数据，能可靠地发送到指定的 Topic，Topic 的每个 Partition 收到 Producer 发送的数据后，都需要向 Producer 发送 ACK(ACKnowledge 确认收到)。

如果 Producer 收到 ACK，就会进行下一轮的发送，否则重新发送数据。

①副本数据同步策略

何时发送 ACK?确保有 Follower 与 Leader 同步完成，Leader 再发送 ACK，这样才能保证 Leader 挂掉之后，能在 Follower 中选举出新的 Leader 而不丢数据。

多少个 Follower 同步完成后发送 ACK?全部 Follower 同步完成，再发送 ACK。

②ISR

采用第二种方案，所有 Follower 完成同步，Producer 才能继续发送数据，设想有一个 Follower 因为某种原因出现故障，那 Leader 就要一直等到它完成同步。

这个问题怎么解决?Leader维护了一个动态的 in-sync replica set(ISR)：和 Leader 保持同步的 Follower 集合。

当 ISR 集合中的 Follower 完成数据的同步之后，Leader 就会给 Follower 发送 ACK。

如果 Follower 长时间未向 Leader 同步数据，则该 Follower 将被踢出 ISR 集合，该时间阈值由 replica.lag.time.max.ms 参数设定。Leader 发生故障后，就会从 ISR 中选举出新的 Leader。

③ACK 应答机制

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

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

Ack 参数配置：

0：Producer 不等待 Broker 的 ACK，这提供了最低延迟，Broker 一收到数据还没有写入磁盘就已经返回，当 Broker 故障时有可能丢失数据。

1：Producer 等待 Broker 的 ACK，Partition 的 Leader 落盘成功后返回 ACK，如果在 Follower 同步成功之前 Leader 故障，那么将会丢失数据。

-1(all)：Producer 等待 Broker 的 ACK，Partition 的 Leader 和 Follower 全部落盘成功后才返回 ACK。但是在 Broker 发送 ACK 时，Leader 发生故障，则会造成数据重复。

④故障处理细节

LEO：每个副本最大的 Offset。HW：消费者能见到的最大的 Offset，ISR 队列中最小的 LEO。

（编辑：济源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!