Kafka底层细节梳理——知识总结

Kafka特点:

  • 高吞吐量、低延迟:kafka每秒可以处理几十万条消息,它的延迟最低只有几毫秒,每个topic可以分多个partition, consumer group 对partition进行consume操作
  • 可扩展性:Kafka集群支持热扩展
  • 持久性、可靠性:消息被持久化到本地磁盘,并且支持数据备份防止数据丢失
  • 容错性:允许集群中节点失败(若副本数量为n,则允许n-1个节点失败)
  • 高并发:支持数千个客户端同时读写

Kafka架构:

  • 多个Producer,一个Kafka Cluster,多个Consumer
    • Producer:消息生产者,就是向 Kafka broker 发消息的客户端
    • Consumer:消息消费者,向 Kafka broker 取消息的客户端
    • Topic:可以理解为一个队列,一个 Topic 又分为一个或多个Partition
    • Consumer Group:这是 Kafka 用来实现一个 Topic 消息的广播(发给所有的 Consumer)和单播(发给任意一个 Consumer)的手段。一个 Topic 可以有多个 Consumer Group
    • Broker:一台 Kafka 服务器就是一个 Broker。一个Kafka集群(Kafka Cluster)由多个 Broker 组成。一个 Broker 可以容纳多个 Topic
    • Partition:为了实现扩展性,一个非常大的Topic 可以分布到多个 Broker上,每个 Partition 是一个有序的队列。Partition 中的每条消息都会被分配一个有序的id(Offset)。将消息发给 Consumer,Kafka 只保证按一个 Partition 中的消息的顺序,不保证一个 Topic 的整体(多个 Partition 间)的顺序
    • Offset:kafka 的存储文件都是按照 offset.kafka 来命名,用 Offset 做名字的好处是方便查找。例如你想找位于 2049 的位置,只要找到 2048.kafka 的文件即可

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c3bfls6w-1628997431930)(https://s3-us-west-2.amazonaws.com/secure.notion-static.com/20b24b15-12b9-42f8-946a-a85bc4cda800/Untitled.png)]

Kafka中Topic分Partition的目的:

  • 分区对于 Kafka 集群的好处是:实现负载均衡。分区对于消费者来说,可以提高并发度,提高效率
    • Kafka 是如何做到消息的有序性:
      • Kafka 中的每个 Partition 中的消息在写入时都是有序的,而且单独一个 Partition 只能由一个消费者组的消费者去消费,可以在里面保证消息的顺序性。但是 Partition之间的消息是不保证有序的
    • 如何保证高可靠性:
      • 数据可靠性:
        • Topic中的Partition副本机制:Kafka 可以保证单个Partition里的事件是有序的,Partition可以在线(可用),也可以离线(不可用)。在众多的Partition副本里面有一个副本是 Leader,其余的副本是 follower,所有的Consumer读写操作都是经过 Leader 进行的,同时 follower 会定期地去 leader 上的复制数据。当 Leader 挂了的时候,其中一个 follower 会重新成为新的 Leader。通过Partition分区副本,引入了数据冗余,同时也提供了 Kafka 的数据可靠性
        • Producer给Kafka写数据时可能会丢失:是通过ACK实现的,ACK为0、1、ALL
      • 数据一致性:
        • 定义:不论是旧的Partition Leader 还是新选举的 Partition Leader,Consumer 都能读到一样的数据

Kafka 在什么情况下会出现消息丢失(数据可靠性):

  • Producer给Kafka写数据时可能会出现数据丢失:

  • Kafka 在 Producer 里面提供了消息确认机制。也就是说我们可以通过配置来决定消息发送到对应分区的几个副本才算消息发送成功。可以在定义 Producer 时通过 ACK参数指定

  • 根据实际的应用场景,我们设置不同的 ACK,以此保证数据的可靠性

    • ACK = 0:
      • Producer只要通过网络将数据发送出去,就认为消息已经写入至Kafka
      • 可能发生数据丢失:发送的对象无能被序列化或者网卡发生故障,分区离线或整个集群长时间不可用
      • 吞吐量:极高
    • ACK = 1:
      • Producer发送完消息, Leader Partition在收到消息并把它写入到分区数据文件(不一定同步到磁盘上)时,就认为消息已经写入至Kafka
      • 可能发生数据丢失:消息已经成功写入 Leader Partition,但在消息被复制到 Follower Partition副本之前 Leader发生崩溃,此时选举Follower Parttion副本作为新的Leader Partition,但是消息并不完整
    • ACK = ALL:
      • Producer发送完消息,Leader Partition在返回确认或错误响应之前,会等待所有Follower Partition副本都收到悄息,Producer会一直重试直到消息被成功提交
      • 不会发生数据丢失
      • 吞吐量:最低,因为Producer在继续发送其他消息之前需要等待所有Follwer Partition副本都收到当前的消息
  • Kafka如何保证数据的一致性(数据一致性):

    • 数据一致性定义:不论是旧的 Leader 还是新选举的 Leader,Consumer 都能读到一样的数据

    • High Water Mark(高水位线):

      • 假设分区的副本为3,其中副本0是 Leader,副本1和副本2是 Follower,并且在 ISR 列表里面
      • 虽然Leader已经写入了 Message4,但是 Consumer 只能读取到 Message2。因为所有的 ISR 都同步了 Message2,只有 High Water Mark 以上的消息才支持 Consumer 读取,而 High Water Mark 取决于 ISR 列表里面偏移量最小的分区

      [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-aw7phjw4-1628997431937)(https://s3-us-west-2.amazonaws.com/secure.notion-static.com/fad358c7-0abb-494d-bc3f-4f3b5b63cbbc/Untitled.png)]

    • ISR(In-Sync Replicas 副本同步队列):

      • 每个 Partition 维护一个 ISR 列表,这个列表里一定会有 Leader,然后还会包含跟 Leader 保持同步的 Follower
      • 只要 Leader 的某个 Follower 一直跟他保持数据同步,那么就会存在于 ISR 列表里
      • 但如果 Follower 因为自身发生一些问题,导致不能及时的从 Leader 同步数据过去,那么这个 Follower 就会被认为是“out-of-sync”,被从 ISR 列表里踢出

ISR,OSR,AR:

  • ISR:In-Sync Replicas 副本同步队列

  • OSR:Out-of-Sync Replicas 非副本同步队列

  • AR:Assigned Replicas 所有副本

  • ISR是由Leader维护,Follower从Leader同步数据有一些延迟,超过相应的阈值会把 Follower 踢出出 ISR, 存入OSR列表,新加入的Follower也会先存放在OSR中。AR=ISR+OSR

数据传输的事务类别:

  • 数据传输的事务定义通常有以下三种级别:
    • 最多一次(At most once):消息不会被重复发送,最多被传输一次,但也有可能一次都不传输。消息可能会丢,但绝不会重复传递
    • 最少一次(At least one):消息不会被漏发送,最少被传输一次,但也有可能被重复传输。消息绝不会丢,但可能会重复传递
    • 精确的一次(Exactly once):不会漏传输也不会重复传输,每个消息都传输被接收

Kafka的pull or push:

  • Producer将消息推送push到Broker,Consumer从Broker拉取pull消息

Kafka如何保证消息的有序:

  • Kafka只能保证一个Partition中的消息被某个Consumer消费时是顺序的
  • 从Topic角度来说,当有多个Partition时,消息仍然不是全局Topic有序的

Kafka如何保证数据不丢失:

  • 数据丢失:
    • acks=1的时候(只保证写入Leader成功),如果刚好Leader挂了。数据会丢失
    • acks=0的时候,使用异步模式的时候,该模式下Kafka无法保证消息,有可能会丢
  • Broker如何保证不丢失:
    • acks=all : 所有副本都写入成功并确认
    • retries(重复写次数)= 一个合理值
    • min.insync.replicas=2 消息至少要被写入到这么多副本才算成功。
    • unclean.leader.election.enable=false 关闭unclean leader选举,即不允许非ISR中的副本被选举为leader,以避免数据丢失
  • Consumer如何保证不丢失
    • 如果在消息处理完成前就提交了offset,那么就有可能造成数据的丢失
    • enabel.auto.commit=false关闭自动提交offset,然后处理完数据之后手动提交
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值