大数据 -- kafka学习笔记：知识点整理（部分转载）

目录

• 一 为什么需要消息系统
  • 1.解耦
  • 2.冗余
  • 3.扩展性
  • 4.灵活性 & 峰值处理能力
  • 5.可恢复性
  • 6.顺序保证
  • 7.缓冲
  • 8.异步通信
• 二 kafka 架构
  • 1、 拓扑结构
  • 2、相关概念
  • 3、 zookeeper 节点
• 三  producer 发布消息
  • 1、写入方式
  • 2、消息路由
  • 3 、写入流程
  • 4、producer delivery guarantee
• 四、broker 保存消息
  • 1、存储方式
  • 2 、存储策略
  • 3、topic 创建与删除
• 五、kafka HA
  • 1 replication
  • 2、leader failover
  • 3、broker failover
• 4、controller failover
• 六 consumer 消费消息
  • 1、The high-level consumer API
  • 2、The SimpleConsumer API
  • 3、 consumer group
  • 4、消费方式
  • 5、Kafka提交offset机制
  • 5 consumer rebalance
  • 6、API使用

目录

• 一 为什么需要消息系统
  • 1.解耦
  • 2.冗余
  • 3.扩展性
  • 4.灵活性 & 峰值处理能力
  • 5.可恢复性
  • 6.顺序保证
  • 7.缓冲
  • 8.异步通信
• 二 kafka 架构
  • 1、 拓扑结构
  • 2、相关概念
  • 3、 zookeeper 节点
• 三  producer 发布消息
  • 1、写入方式
  • 2、消息路由
  • 3 、写入流程
  • 4、producer delivery guarantee
• 四、broker 保存消息
  • 1、存储方式
  • 2 、存储策略
  • 3、topic 创建与删除
• 五、kafka HA
  • 1 replication
  • 2、leader failover
  • 3、broker failover
• 4、controller failover
• 六 consumer 消费消息
  • 1、The high-level consumer API
  • 2、The SimpleConsumer API
  • 3、 consumer group
  • 4、消费方式
  • 5、Kafka提交offset机制
  • 5 consumer rebalance
  • 6、API使用

回到顶部

一 为什么需要消息系统

1.解耦

允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

2.冗余

消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。

3.扩展性

因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。

4.灵活性 & 峰值处理能力

在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

5.可恢复性

系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

6.顺序保证

在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。（Kafka 保证一个 Partition 内的消息的有序性）

7.缓冲

有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。

8.异步通信

很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

回到顶部

二 kafka 架构

1、 拓扑结构

2、相关概念

kafka 相关名词解释如下：

• producer：消息生产者，发布消息到 kafka 集群的终端或服务。
• broker：kafka 集群中包含的服务器。
• topic：每条发布到 kafka 集群的消息属于的类别，即 kafka 是面向 topic 的。
• partition：partition 是物理上的概念，每个 topic 包含一个或多个 partition。kafka 分配的单位是 partition。
• consumer：从 kafka 集群中消费消息的终端或服务。
• Consumer group：high-level consumer API 中，每个 consumer 都属于一个 consumer group，每条消息只能被 consumer group 中的一个 Consumer 消费，但可以被多个 consumer group 消费。
• replica：partition 的副本，保障 partition 的高可用。
• leader：replica 中的一个角色， producer 和 consumer 只跟 leader 交互。
• follower：replica 中的一个角色，从 leader 中复制数据。
• controller：kafka 集群中的其中一个服务器，用来进行 leader election 以及各种 failover。
• zookeeper：kafka 通过 zookeeper 来存储集群的 meta 信息。

3、 zookeeper 节点

kafka 在 zookeeper 中的存储结构如下图所示：

Zookeeper 主要用来跟踪Kafka 集群中的节点状态, 以及Kafka Topic, message 等等其他信息. 同时, Kafka 依赖于Zookeeper, 没有Zookeeper 是不能运行起来Kafka 的。

zookeeper服务开启后，进入客户端的命令：

zkCli.sh

zookeeper客户端更多常用命令参考博客：Kafka在zookeeper中存储结构和查看方式。

回到顶部

三  producer 发布消息

1、写入方式

producer 采用 push 模式将消息发布到 broker，每条消息都被 append 到 patition 中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障 kafka 吞吐率）。

2、消息路由

producer 发送消息到 broker 时，会根据分区算法选择将其存储到哪一个 partition。其路由机制为：

• 指定了 patition，则直接使用；
• 未指定 patition 但指定 key，通过对 key 的 value 进行hash 选出一个 patition；
• patition 和 key 都未指定，使用轮询选出一个 patition。

 附上 java 客户端分区源码，一目了然：

//创建消息实例
public ProducerRecord(String topic, Integer partition, Long timestamp, K key, V value) {
     if (topic == null)
          throw new IllegalArgumentException("Topic cannot be null");
     if (timestamp != null && timestamp < 0)
          throw new IllegalArgumentException("Invalid timestamp " + timestamp);
     this.topic = topic;
     this.partition = partition;
     this.key = key;
     this.value = value;
     this.timestamp = timestamp;
}

//计算 patition，如果指定了 patition 则直接使用，否则使用 key 计算
private int partition(ProducerRecord<K, V> record, byte[] serializedKey , byte[] serializedValue, Cluster cluster) {
     Integer partition = record.partition();
     if (partition != null) {
          List<PartitionInfo> partitions = cluster.partitionsForTopic(record.topic());
          int lastPartition = partitions.size() - 1;
          if (partition < 0 || partition > lastPartition) {
               throw new IllegalArgumentException(String.format("Invalid partition given with record: %d is not in the range [0...%d].", partition, lastPartition));
          }
          return partition;
     }
     return this.partitioner.partition(record.topic(), record.key(), serializedKey, record.value(), serializedValue, cluster);
}

// 使用 key 选取 patition
public int partition(String topic, Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster) {
     List<PartitionInfo> partitions = cluster.partitionsForTopic(topic);
     int numPartitions = partitions.size();
     if (keyBytes == null) {
          int nextValue = counter.getAndIncrement();
          List<PartitionInfo> availablePartitions = cluster.availablePartitionsForTopic(topic);
          if (availablePartitions.size() > 0) {
               int part = DefaultPartitioner.toPositive(nextValue) % availablePartitions.size();
               return availablePartitions.get(part).partition();
          } else {
               return DefaultPartitioner.toPositive(nextValue) % numPartitions;
          }
     } else {
          //对 keyBytes 进行 hash 选出一个 patition
          return DefaultPartitioner.toPositive(Utils.murmur2(keyBytes)) % numPartitions;
     }
}

3 、写入流程

producer 写入消息序列图如下所示：

流程说明：

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

4、producer delivery guarantee

一般情况下存在三种情况：

• At most once 消息可能会丢，但绝不会重复传输；
• At least one 消息绝不会丢，但可能会重复传输；
• Exactly once 每条消息肯定会被传输一次且仅传输一次。

当 producer 向 broker 发送消息时，一旦这条消息被 commit，由于 replication 的存在，它就不会丢。但是如果 producer 发送数据给 broker 后，遇到网络问题而造成通信中断，那 Producer 就无法判断该条消息是否已经 commit。虽然 Kafka 无法确定网络故障期间发生了什么，但是 producer 可以生成一种类似于主键的东西，发生故障时幂等性的重试多次，这样就做到了 Exactly once，但目前还并未实现。所以目前默认情况下一条消息从 producer 到 broker 是确保了 At least once，可通过设置 producer 异步发送实现At most once。

回到顶部

四、broker 保存消息

1、存储方式

物理上把 topic 分成一个或多个 patition（可以通过配置 server.properties 中的 num.partitions指定默认值），每个 patition 物理上对应一个文件夹（该文件夹存储该 patition 的所有消息和索引文件），如下：

topic为zy-test分区为0的数据保存在000000000000000000000000.log文件中。这个数据是序列化之后的。

2 、存储策略

无论消息是否被消费，kafka 都会保留所有消息。有两种策略可以删除旧数据：

• 基于时间：log.retention.hours=168
• 基于大小：log.retention.bytes=1073741824

需要注意的是，因为Kafka读取特定消息的时间复杂度为O(1)，即与文件大小无关，所以这里删除过期文件与提高 Kafka 性能无关。

3、topic 创建与删除

创建 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。

删除 topic 的序列图如下所示：

流程说明：

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。

回到顶部

五、kafka HA

1 replication

如图2.1所示，同一个 partition 可能会有多个 replica。没有 replica 的情况下，一旦 broker 宕机，其上所有 patition 的数据都不可被消费，同时 producer 也不能再将数据存于其上的 partition。引入replication 之后，同一个 partition 可能会有多个 replica，而这时需要在这些 replica 之间选出一个 leader，producer 和 consumer 只与这个 leader 交互，其它 replica 作为 follower 从 leader 中复制数据。

Kafka 分配 replica 的算法如下：

• 将所有 broker（假设共 n 个 broker）和待分配的 partition 排序 ；
• 将第 i 个 partition 分配到第（i mod n）个 broker 上 ；
• 将第 i 个 partition 的第 j 个 replica 分配到第（(i + j) mode n）个 broker上。

2、leader failover

当 partition 对应的 leader 宕机时，需要从 follower 中选举出新 leader。在选举新leader时，一个基本的原则是，新的 leader 必须拥有旧 leader commit 过的所有消息。

kafka 在 zookeeper 中（/brokers/.../state）动态维护了一个 ISR（in-sync replicas），由3.3节的写入流程可知 ISR 里面的所有 replica 都跟上了 leader，只有 ISR 里面的成员才能选为 leader。对于 f+1 个 replica，一个 partition 可以在容忍 f 个 replica 失效的情况下保证消息不丢失。

当所有 replica 都不工作时，有两种可行的方案：

• 等待 ISR 中的任一个 replica 活过来，并选它作为 leader。可保障数据不丢失，但时间可能相对较长;
• 选择第一个活过来的 replica（不一定是 ISR 成员）作为 leader。无法保障数据不丢失，但相对不可用时间较短。

kafka 0.8.* 使用第二种方式。

kafka 通过 Controller 来选举 leader，流程请参考5.3节。

3、broker failover

kafka broker failover 序列图如下所示：

流程说明： 

1. controller 在 zookeeper 的 /brokers/ids/[brokerId] 节点注册 Watcher，当 broker 宕机时 zookeeper 会 fire watch；
2. controller 从 /brokers/ids 节点读取可用broker；
3. controller决定set_p，该集合包含宕机 broker 上的所有 partition；
4. 对 set_p 中的每一个 partition：
    4.1 从/brokers/topics/[topic]/partitions/[partition]/state 节点读取 ISR；
    4.2 决定新 leader（如4.3节所描述）；
    4.3 将新 leader、ISR、controller_epoch 和 leader_epoch 等信息写入 state 节点；
5. 通过 RPC 向相关 broker 发送 leaderAndISRRequest 命令。

回到顶部

4、controller failover

当 controller 宕机时会触发 controller failover。每个 broker 都会在 zookeeper 的 "/controller" 节点注册 watcher，当 controller 宕机时 zookeeper 中的临时节点消失，所有存活的 broker 收到 fire 的通知，每个 broker 都尝试创建新的 controller path，只有一个竞选成功并当选为 controller。

当新的 controller 当选时，会触发 KafkaController.onControllerFailover 方法，在该方法中完成如下操作：

1. 读取并增加 Controller Epoch；
2. 在 reassignedPartitions Patch(/admin/reassign_partitions) 上注册 watcher；
3. 在 preferredReplicaElection Path(/admin/preferred_replica_election) 上注册 watcher；
4. 通过 partitionStateMachine 在 broker Topics Patch(/brokers/topics) 上注册 watcher；
5. 若 delete.topic.enable=true（默认值是 false），则 partitionStateMachine 在 Delete Topic Patch(/admin/delete_topics) 上注册 watcher；
6. 通过 replicaStateMachine在 Broker Ids Patch(/brokers/ids)上注册Watch；
7. 初始化 ControllerContext 对象，设置当前所有 topic，“活”着的 broker 列表，所有 partition 的 leader 及 ISR等；
8. 启动 replicaStateMachine 和 partitionStateMachine；
9. 将 brokerState 状态设置为 RunningAsController；
10. 将每个 partition 的 Leadership 信息发送给所有“活”着的 broker；
11. 若 auto.leader.rebalance.enable=true（默认值是true），则启动 partition-rebalance 线程；
12. 若 delete.topic.enable=true 且Delete Topic Patch(/admin/delete_topics)中有值，则删除相应的Topic。

回到顶部

六 consumer 消费消息

kafka 提供了两套 consumer API：

• The high-level Consumer API ；

• The SimpleConsumer API。

其中 high-level consumer API 提供了一个从 kafka 消费数据的高层抽象，而 SimpleConsumer API 则需要开发人员更多地关注细节。

1、The high-level consumer API

high-level consumer API 提供了 consumer group 的语义，一个消息只能被 group 内的一个 consumer 所消费，且 consumer 消费消息时不关注 offset，最后一个 offset 由 zookeeper 保存。

使用 high-level consumer API 可以是多线程的应用，应当注意：

• 如果消费线程大于 patition 数量，则有些线程将收不到消息；
• 如果 patition 数量大于线程数，则有些线程多收到多个 patition 的消息；
• 如果一个线程消费多个 patition，则无法保证你收到的消息的顺序，而一个 patition 内的消息是有序的。

2、The SimpleConsumer API

如果你想要对 patition 有更多的控制权，那就应该使用 SimpleConsumer API，比如：

• 多次读取一个消息；
• 只消费一个 patition 中的部分消息；
• 使用事务来保证一个消息仅被消费一次。

但是使用此 API 时，partition、offset、broker、leader 等对你不再透明，需要自己去管理。你需要做大量的额外工作：

亲爱的读者和支持者们，自动博客加入了打赏功能，陆陆续续收到了各位老铁的打赏。在此，我想由衷地感谢每一位对我们博客的支持和打赏。你们的慷慨与支持，是我们前行的动力与源泉。

日期	姓名	金额
2023-09-06	*源	19
2023-09-11	*朝科	88
2023-09-21	*号	5
2023-09-16	*真	60
2023-10-26	*通	9.9
2023-11-04	*慎	0.66
2023-11-24	*恩	0.01
2023-12-30	I*B	1
2024-01-28	*兴	20
2024-02-01	QYing	20
2024-02-11	*督	6
2024-02-18	一*x	1
2024-02-20	c*l	18.88
2024-01-01	*I	5
2024-04-08	*程	150
2024-04-18	*超	20
2024-04-26	.*V	30
2024-05-08	D*W	5
2024-05-29	*辉	20
2024-05-30	*雄	10
2024-06-08	*:	10
2024-06-23	小狮子	666
2024-06-28	*s	6.66
2024-06-29	*炼	1
2024-06-30	*!	1
2024-07-08	*方	20
2024-07-18	A*1	6.66
2024-07-31	*北	12
2024-08-13	*基	1
2024-08-23	n*s	2
2024-09-02	*源	50
2024-09-04	*J	2
2024-09-06	*强	8.8
2024-09-09	*波	1
2024-09-10	*口	1
2024-09-10	*波	1
2024-09-12	*波	10
2024-09-18	*明	1.68
2024-09-26	B*h	10
2024-09-30	岁	10
2024-10-02	M*i	1
2024-10-14	*朋	10
2024-10-22	*海	10
2024-10-23	*南	10
2024-10-26	*节	6.66
2024-10-27	*o	5
2024-10-28	W*F	6.66
2024-10-29	R*n	6.66
2024-11-02	*球	6
2024-11-021	*鑫	6.66
2024-11-25	*沙	5
2024-11-29	C*n	2.88

创作不易，喜欢的话，请考虑支持一下！关注公众号查看全文！（微信扫码）