kafka 笔记

apache kafka

AMQP

  • Advanced Message Queueing Protocol(高级消息队列协议)
  • 是一个标准开放的应用层的消息中间件(Message Oriented Middleware)协议。
    AMQP定义了通过网络发送的字节流的数据格式。因此兼容性非常好,
    任何实现AMQP协议的程序都可以和与AMQP协议兼容的其他程序交互,可以很容易做到跨语言,跨平台。

介绍:

  • apache kafka 是一个分布式流媒体平台。
    • 功能:
    • 1.发布和订阅消息流,类似于消息队列和企业级消息系统。这也是kafka归结为消息队列框架的原因。
    • 2.以容错的方式来记录消息流,kafka以文件的方式来存储消息流。
    • 3.可以在消息发布的时候进行处理。

使用场景:

  • 日志收集:
  • 消息队列:解耦和生产者,消费者,消息缓存。
  • 用户活动跟踪
  • 运营指标:
  • 流式处理:
  • 事件源:

基本概念:

  • broker: kafka以集成的方式运行,可以有一个或者多个服务组成,每个服务就叫一个broker.
  • producer:往broker的topic中生产消息。
  • consumer:往broker的某个topic中读取消息。
  • topic:kafka消息的分类方式,每一类的消息称为一个topic。
  • partition:topic物理上的分组,一个topic可以分为多个partition。
  • replication: 副本partition的备份,保证partition的高可用。
  • segment: partition物理上由多个segment组成。
  • message:也叫record,是有一个key, value和时间戳组成的。
  • controller:负责管理分区和副本的状态并执行,以及这些分区的重新分配。
  • ISR:同步副本组
  • leader:replication的一个角色,producer和consumer只跟leader进行交互。
  • follower:replication的一个角色,从leader中复制数据。
  • controller:kafka集群中的一个broker,用来进行leader选举以及各种failover
  • zookeeper:kafka 通过 zookeeper 来存储集群的 meta 信息。

设计思想:

broker controller

  • 在早期的版本中,对于分区和副本的状态管理依赖于zookeeper的watcher和队列。每一个broker都会在zookeeper注册Watcher。
    所以,就会出现大量的watcher,如果宕机的broker上的partition比较多,会造成多个watcher的触发,造成集群内大规模的调整。
    每一个replica都要去再次zookeeper上注册监视器,当集群规模很大的时候,zookeeper负担很重。
    这种设计很容易出现脑裂和羊群效应以及zookeeper集群过载。
  • 新版本该变了这种设计,使用KafkaController。
    Leader会向zookeeper上注册Watcher,其他broker几乎不用监听zookeeper的状态变化。
  • 当broker启动时,都会创建broker controller,但是集群中只有一个broker controller对外提供服务。
    这些每个节点上的KafkaController会在指定的zookeeper路径下创建临时节点,
    只有第一个成功创建的节点的KafkaController才可以成为leader,其余的都是follower。
    当leader故障后,所有的follower会收到通知,再次竞争在该路径下创建节点从而选举新的leader
  • Kafka集群中多个broker,有一个会被选举为controller leader,负责管理整个集群中分区和副本的状态,
    比如partition的leader 副本故障,由controller 负责为该partition重新选举新的leader 副本;
    当检测到ISR列表发生变化,有controller通知集群中所有broker更新其MetadataCache信息;
    或者增加某个topic分区的时候也会由controller管理分区的重新分配工作

    producer生产消息:

    • 1.producer采用push模式讲消息发送到broker,每条消息都被append到partition中,属于顺序写磁盘。
      (顺序写入的效率比随机写入的效率要高,保障kafka的吞吐率。)
    • 2.消息发送到broker时,会根据分区算法选择将其存储到哪一个 partition。
      • 其算法为
      • 2.1 指定了partition,则直接使用
      • 2.2 没有指定partition,指定了key,则使用key的value,进行hash取余选出一个partition.
      • 2.3 key和partition都没有指定,就采用轮询的方法选出一个partition.
    • 3.kafka接收到proucer发送过来的消息之后,将其持久化到硬盘,并设置保留消息的时长。不关注消息是否被消费者消费。
    • 4.consumer从kafka集群中pull数据,并记录offset。

消息写入的流程:

  • producer从zk的"/brokers/.../state"节点找到partition对应的leader
  • producer把消息发送给对应的leader
  • leader把消息写入本地log
  • followers从leader处pull消息,写入本地log后,向leader发送ACK。
  • leader收到所有ISR中的replica的ACK后,增加 HW(high watermark,最后 commit 的 offset) 并向 producer 发送 ACK
    file

    producers的参数acks设置

    request.required.acks:

    • 0:producer不会等待broker发送ack
    • 1:在leader已经接收到数据后,producer会得到一个ack
    • -1:所有的ISR都接收到数据后,producer才得到一个ack

topic

topic的注册流程

  • controller在ZK的/brokers/topics节点上注册watcher.当topic被创建时,controller会通过watcher得到该
    topic的partition和replica的分配情况。
  • controller从/brokers/ids中读取当前可用的broker列表。对于set_p中的每一个partition.
    • 从分配给该 partition 的所有 replica(称为AR)中任选一个可用的 broker 作为新的 leader,并将AR设置为新的 ISR
    • 将新的 leader 和 ISR 写入 /brokers/topics/[topic]/partitions/[partition]/state
    • controller 通过 RPC 向相关的 broker 发送 LeaderAndISRRequest。

consumer

consumer group

  • 是kafka提供的可扩展的具有容错性的消费机制。
  • 组内有多个消费者或者消费者实例,共享一个group id.
  • 组内所有的消费者协调在一起来消费订阅的topic中的所有分区。
  • 每一个分区只能由一个组内的一个消费者消费。其他的组也可以订阅同一个topic.

rebalance

  • 其本质是一种协议,规定了consumer group下所有的consumer如何达成一致来分配订阅topic的每个分区。
  • 什么时候触发:
    • 1.当消费组中的consumer发生变化时,(新consumer加入,有consumer主动离开,consumer崩溃)
    • 2.订阅的主题数发生变更
    • 3.主题的分区数发生变化
  • 两种策略:
    • range:将消费者的线程总数除以分区个数,如果有余数。那么前面几个消费者将会多消费几个分区。
      例如:一个topic有10个分区,有3个消费线程,那消费者分配的分区就是:
      • C1-0 将消费 0, 1, 2, 3 分区
      • C2-0 将消费 4, 5, 6 分区
      • C2-1 将消费 7, 8, 9 分区
    • roundrobin:

关于partition

  • 一个partition只能被同组的一个consumer消费。同组的其他的consumer起到负载的作用。
  • 可以被多个消费组消费。即一个消息被消费多次。
  • 一个topic中partition的数量,是userGroup的最大并行数量。

    负载均衡

    • kafka集群中的任何一个broker,都可以向producer提供metadata信息,
      这些metadata中包含"集群中存活的servers列表"/"partitions leader列表"等信息。
      当producer获取到metadata信息之后, producer将会和Topic下所有partition leader保持socket连接;
      消息由producer直接通过socket发送到broker,中间不会经过任何"路由层".

    • 异步发送,将多条消息暂且在客户端buffer起来,并将他们批量发送到broker;
      小数据IO太多,会拖慢整体的网络延迟,批量延迟发送事实上提升了网络效率;
      不过这也有一定的隐患,比如当producer失效时,那些尚未发送的消息将会丢失。

关于 leader election算法

  • 本质上是一个分布式锁,有两种方式实现基于ZK的分布式锁
    • 1.节点名称唯一性:多个客户端创建一个临时节点,创建成功的客户端获得锁。
    • 2.临时顺序节点:所有客户端在某个目录下创建一个临时节点,序号最小的那个获得锁。

不卑不亢,不慌不忙,这才是生活的模样。

讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!