4.kafka系统架构

4.kafka系统架构

Broker

  • Kafka 集群包含一个或多个服务器，服务器节点称为broker。

Topic (类似表)

  • 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。
  • 类似于数据库的表名或者ES的Index
  • 物理上不同Topic的消息分开存储
  • 逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消 费数据而不必关心数据存于何处）
  • 创建流程
1.controller在ZooKeeper的/brokers/topics节点上注册watcher，当topic被创建，
则 controller会通过watch得到该topic的partition/replica分配。
2.controller从/brokers/ids读取当前所有可用的broker列表，对于set_p中的每一个 partition：
  2.1从分配给该partition的所有replica（称为AR）中任选一个可用的broker作为新的 leader，
并将AR设置为新的ISR
  2.2将新的leader和ISR写 入/brokers/topics/[topic]/partitions/[partition]/state
3.controller通过RPC向相关的broker发送LeaderAndISRRequest。
  • 删除流程
1.controller在zooKeeper的/brokers/topics节点上注册watcher，当topic被删除，
则controller会通过watch得到该topic的partition/replica分配。
2.若delete.topic.enable=false，结束；否则controller注册在/admin/delete_topics上 的watch被fire,
controller通过回调向对应的broker发送StopReplicaRequest。

Partition (分区表的)

  • topic中的数据分割为一个或多个partition。
  • 每个topic至少有一个partition,当生产者产生数据的时候，根据分配策略,选择分区,然后将消息追 加到指定的分区的末尾（队列）
## Partation数据路由规则
1. 指定了 patition，则直接使用；
2. 未指定 patition 但指定 key，通过对 key 的 value 进行hash 选出一个 patition
3. patition 和 key 都未指定，使用轮询选出一个 patition。
  • 每条消息都会有一个自增的编号
    • 标识顺序
    • 用于标识消息的偏移量
  • 每个partition中的数据使用多个segment文件存储。
  • partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。
  • 如果topic有多个partition，消费数据时就不能保证数据的顺序。严格保证消息的消费顺序的场景 下，需要将partition数目设为1。

Leader (读写)

每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的 partition。

1. producer 先从 zookeeper 的 "/brokers/.../state" 节点找到该 partition 的 leader
2. producer 将消息发送给该 leader
3. leader 将消息写入本地 log
4. followers 从 leader pull 消息，写入本地 log 后 leader 发送 ACK
5. leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，
最后 commit 的 offset） 并向 producer 发送 ACK

Follower (只备份)

  • Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower， Follower与Leader保持数据同步。
  • 如果Leader失效，则从Follower中选举出一个新的Leader。
  • 当Follower挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中 删除，重新创建一个Follower。

replication (Follower的另外一个叫法)

  • 数据会存放到topic的partation中，但是有可能分区会损坏
  • 我们需要对分区的数据进行备份（备份多少取决于你对数据的重视程度）
  • 我们将分区的分为Leader(1)和Follower(N)
    • Leader负责写入和读取数据
    • Follower只负责备份
    • 保证了数据的一致性
  • 备份数设置为N，表示主+备=N(参考HDFS)
## Kafka 分配 Replica 的算法如下
1. 将所有 broker（假设共 n 个 broker）和待分配的 partition 排序
2. 将第 i 个 partition 分配到第（i mod n）个 broker 上
3. 将第 i 个 partition 的第 j 个 replica 分配到第（(i + j) mode n）个 broker 上

producer

  • 生产者即数据的发布者，该角色将消息发布到Kafka的topic中。
  • broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件 中。
  • 生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。

consumer

  • 消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。
  • kafka 提供了两套 consumer API：
1. The high-level Consumer API
2. The SimpleConsumer API
  • high-level consumer API 提供了一个从 kafka 消费数据的高层抽象，而 SimpleConsumer API 则 需要开发人员更多地关注细节。

Consumer Group

  • 每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不 指定group name则属于默认的group）。
  • 将多个消费者集中到一起去处理某一个Topic的数据，可以更快的提高数据的消费能力
  • 整个消费者组共享一组偏移量(防止数据被重复读取)，因为一个Topic有多个分区

offset偏移量

  • 可以唯一的标识一条消息
  • 偏移量决定读取数据的位置，不会有线程安全的问题，消费者通过偏移量来决定下次读取的消息
  • 消息被消费之后，并不被马上删除，这样多个业务就可以重复使用kafka的消息
  • 我们某一个业务也可以通过修改偏移量达到重新读取消息的目的,偏移量由用户控制
  • 消息最终还是会被删除的，默认生命周期为1周（7*24小时）

Zookeeper

  • kafka 通过 zookeeper 来存储集群的 meta 信息。