Kafka 系列（二）文件存储机制与Producer架构原理---怎样保证数据可靠性？？

指明partition的情况下，直接将指明的值直接作为partition值
没有指明partition值但由key的情况下，会将key的hash值与topicpartition进行取余得到partition值
没有指明partition值也没有key的情况下，第一次调用随机生成一个整数（后面每次调用在整数上自增），将这个值与topic可用的partition总数取余得到partition值，也就是round-robin算法。

二：数据可靠性保证策略：

生产者到Kafka端发送数据：

producer给leader发送完数据后，leader会将follower同步完成后，leader再发送ack，这样才能保证leader挂掉之后，能再follower中选举出合适的leader，

副本数据同步策略：

kafka由于会存放大量数据，不会去选择半数存活机制，半数会造成大量数据冗余。
因为都是部署在一个机架上的，所以网络延迟对kafka影响比较小

多少个follower同步完成后发送ack？

半数以上,因为为了防止脑裂同时参与投票也需要半数以上，

在这里插入图片描述

ISR：动态集合in-sync replica set

当有follower完成数据同步后，follower就给leader发送ack，follower长时间未响应，将被踢出ISR，leader故障，从ISR中选举新的leader

踢出时间阈值由：

replica.lag.time.max.ms #参数设定

故障节点发生处理细节：

LEO（log-end-offset）：每个副本的最后一个offset

HW（high watemark）：所有副本中最小的LEO

follower故障：

follower会被踢出ISR，follower读取本地磁盘的记录得HW，高于log文件得全部删掉，从HW开始进行向leader同步

等该 follower 的 LEO 大于等于该 Partition 的 HW，即 follower 追上 leader 之后，就可以重新加入 ISR 了。

leader故障：

leader发生故障后，从ISR中选出一个新的leader之后，，之后，为保证多个副本之间的数据一致性，其余的 follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 leader同步数据。

只能保证副本得数据一致性

ack应答机制：

ack参数等级
- 0：producer不等待broker的ack，broker已接受到还没写入磁盘就返回成功，可能会造成数据丢失
- 1：producer等待broker的ack，partition的leader落盘成功返回ack，follower同步成功之前leader故障，数据可能会丢失
- -1（all）：leader和follower全部落盘成功才返回ack**，当follow同步完成之后，leader挂了，producer又发了一次写入broker请求，结果在另外一个leader又写了一次，造成数据重复**

Exactly Once语义:

保证每条信息被发送且仅被发送一次

0.11后，kafka引入幂等性机制（dempotent）（实例化一次机制），配合acks = -1时得at least once语义（会重复不丢失），完成了exactly once

只需将enable.idempotence属性设置为true，kafka自动将acks属性设为-1

幂等性实现：

开启幂等性的 Producer 在初始化的时候会被分配一个 PID，发往同一 Partition 的消息会附带 SequenceNumber。而 Broker 端会对<PID,Partition,SeqNumber>做缓存，当具有相同主键的消息提交时，Broker 只会持久化一条。
但是 PID 重启就会变化，同时不同的 Partition 也具有不同主键，所以幂等性无法保证跨分区跨会话的 ExactlyOnce

Kafka 系列（二）文件存储机制与Producer架构原理---怎样保证数据可靠性？？

文章目录

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

工作流程：

topic底层存储：

Producer生产者架构：

一：分区存储策略：

1.分区的原因：

2.分区的原则：

ProducerRecord构造器：

二：数据可靠性保证策略：

生产者到Kafka端发送数据：

副本数据同步策略：

ISR：动态集合in-sync replica set

故障节点发生处理细节：

ack应答机制：

Exactly Once语义:

幂等性实现：

猜你喜欢