Kafka 生产者数据安全(ACK机制,ACK时机,ACK应答机制,故障处理,Exactly Once)

Kafka 生产者数据安全(ACK机制,ACK时机,ACK应答机制,故障处理,Exactly Once),第1张

Kafka 生产者数据安全(ACK机制,ACK时机,ACK应答机制,故障处理,Exactly Once) 生产者数据安全 一、数据分区
图解

分区原因
  • 1、方便在集群中扩展,每个 Partition 可以通过调整以适应它所在的机器
  • 2、一个 Topic 又可以有多个 Partition 组成,因此可以以 Partition 为单位读写了‘
  • 3、可以提高并发,因此可以以 Partition 为单位读写
分区原则
  • 将 Producer 发送的数据封装成一个 ProducerRecord 对象。对象包含:

    • topic:string 类型,NotNull。
    • partition:int 类型,可选。
    • timestamp:long 类型,可选。
    • key:string 类型,可选。
    • value:string 类型,可选。
    • headers:array 类型,Nullable。
二、数据可靠性保证
ACK机制
  • 1、为保证 Producer 发送的数据,能可靠地发送到指定的 Topic
  • 2、Topic 的每个 Partition 收到 Producer 发送的数据后,都需要向 Producer 发送ACK(ACKnowledge 确认收到)。
  • 3、如果 Producer 收到 ACK,就会进行下一轮的发送,否则重新发送数据。
ACK时机
  • 1、半数以上 Follower 与 Leader 同步完成,Leader 发送 ACK

  • 2、全部 Follower 与 Leader 同步完成,Leader 发送 ACK。

  • 3、ISR(部分)

    • 1、关键词

      • AR : Assigned Replicas 用来标识副本的全集
      • OSR :out -sync Replicas 离开同步队列的副本
      • ISR :in -sync Replicas 加入同步队列的副本
      • ISR = Leader + 没有落后太多的副本;
      • AR = OSR+ ISR。
    • 2、Leader维护了一个动态的 in-sync replica set(ISR 和 Leader 保持同步的 Follower 集合)

    • 3、如果 Follower 长时间未向 Leader 同步数据,则该 Follower 将被踢出 ISR 集合,判断标准:

      • 超过10秒钟没有同步数据

        • replica.lag.time.max.ms=10000
      • 主副节点差4000条数据

        • rerplica.lag.max.messages=4000
    • 4、Leader 发生故障后,就会从 ISR 中选举出新的 Leader。

      • kafka采用一种降级措施来处理:
      • 选举第一个恢复的node作为leader提供服务,以它的数据为基准,这个措施被称为脏leader选举
  • 图解

ACK应答机制
  • 说明

    • Kafka 为用户提供了三种可靠性级别,用户根据可靠性和延迟的要求进行权衡
  • 注意

    • Producers可以选择是否为数据的写入接收ack,有以下几种ack的选项:request.required.acks

      • acks=0:

        • 这意味着 Producer无需等待来自 Leader的确认而继续发送下一批消息。
        • 当 Broker 故障时有可能丢失数据。
      • acks=1:

        • Producer 在 ISR 中的Leader 已成功收到的数据并得到确认后发送下一条 Message
        • 如果在 Follower 同步成功之前 Leader 故障,那么将会丢失数据。
      • acks=-1:

        • Producer 需要等待 ISR 中的所有 Follower 都确认接收到数据后才算一次发送完成,可靠性最高。
        • 在 Broker 发送 ACK 时,Leader 发生故障,则会造成数据重复。
  • 图解

故障处理
  • 图解

  • 注意

    • 1、LEO:每个副本最大的 Offset。

    • 2、Follower 故障:

      • 1、Follower 发生故障后会被临时踢出 ISR 集合,待该 Follower 恢复后,Follower 会 读取本地磁盘记录的上次的 HW,并将 log 文件高于 HW 的部分截取掉,从 HW 开始向 Leader 进行同步数据 *** 作。
      • 2、等该 Follower 的 LEO 大于等于该 Partition 的 HW,即 Follower 追上 Leader 后,就可以重新加入 ISR 了。
    • 3、Leader 故障:

      • 1、Leader 发生故障后,会从 ISR 中选出一个新的 Leader,之后,为保证多个副本之间的数据一致性,其余的 Follower 会先将各自的 log 文件高于 HW 的部分截掉,然后从新的 Leader 同步数据。
      • 2、注意:这只能保证副本之间的数据一致性,并不能保证数据不丢失或者不重复。
Exactly once 语义
  • 说明

    • 1、将服务器的 ACK 级别设置为 -1,可以保证 Producer 到 Server 之间不会丢失数据,即 At Leastonce 语义

    • 2、将服务器 ACK 级别设置为 0,可以保证生产者每条消息只会被发送一次,即 At Most once 语义。

      • At Least once 可以保证数据不丢失,但是不能保证数据不重复;
      • At Most once 可以保证数据不重复,但是不能保证数据不丢失。
  • 注意

    • Exactly Once

      • 1、重要数据既不重复也不丢失
      • 2、0.11 版本的 Kafka,引入了幂等性:Producer 不论向 Server 发送多少重复数据,Server 端都只会持久化一条。
      • 3、At Least once + 幂等性 = Exactly Once
      • 4、要启用幂等性,只需要将 Producer 的参数中 enable.idompotence 设置为 true 即可。
      • 5、开启幂等性的 Producer 在初始化时会被分配一个 PID,发往同一 Partition 的消息会附带Sequence Number
      • 6、而 Borker 端会对 做缓存,当具有相同主键的消息提交时,Broker 只会持久化一条。
      • 7、但是 PID 重启后就会变化,同时不同的 Partition 也具有不同主键,所以幂等性无法保证跨分区会话的 Exactly Once。

我是底线。。。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/5635573.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-16
下一篇 2022-12-16

发表评论

登录后才能评论

评论列表(0条)

保存