概述

核心概念

Kafka将生产者发布的消息发布到topic中，需要这些消息的消费者可以订阅这些主题。
下面这张图也为我们引出了，Kafka 比较重要的几个概念：

• Producer（生产者） : 产生消息的一方。

• Consumer（消费者） : 消费消息的一方。

• Broker（代理 / 单个kafka实例）:可以看作是一个独立的Kafka实例。

  • 多个Kafka Broker组成一个Kafka Cluster。
  • 每个 Broker 中又包含了 Topic 以及 Partition这两个重要的概念

• Topic（主题） : Producer将消息发送到特定的主题，Consumer通过订阅特定的 Topic(主题) 来消费消息。

• Partition（分区 / 队列） : Partition 属于 Topic 的一部分。一个 Topic 可以有多个 Partition ，并且同一 Topic 下的 Partition 可以分布在不同的 Broker 上，这也就表明一个 Topic 可以横跨多个 Broker
  划重点：Kafka 中的 Partition（分区） 实际上可以对应成为消息队列中的队列。

• 消费者组：同一个消费者组中，多个消费者订阅同一个topic，只有一个消费者可以接收到消息。

生产者

示例

同步 / 异步发送消息

生产者参数配置

ack-确认机制

retries - 重试次数

compression_type - 消息压缩类型

分区机制

kafka分区机制，允许消息存放在不同broke的不同分区上。

分区策略

默认是轮询。

消费者

消息有序性

消息都发给同一个分区，就可以保证消息有序性。

提交和偏移量

消费者在消费消息时，可以追踪消息再分区的位置（偏移量），并自动向一个叫做_consumer_offset的特殊topic发送消息，包含了分区的偏移量。

如果消费者发送崩溃或者有新的消费者加入群组，会触发再平衡。例如消费者2挂掉了，那么分区3和分区4将被再平衡机制，指向到其他消费者。

在自动提交偏移量模式下，再平衡机制可能会引发问题，因为挂掉的消费者提交的消息偏移量与新指定的消费者正在处理的消息偏移量是不一致的。
提交偏移量小于正在处理的偏移量：

如果提交的偏移量小于正在处理的最后一个消息的偏移量，那么处于两个偏移量之间的消息就会被重复处理。

提交偏移量大于正在处理的偏移量：

如果提交的偏移量大于正在处理的最后一个消息的偏移量，那么处于两个偏移量之间的消息将会丢失。

偏移量提交方式

手动提交

首先将自动提交设置为false：

同步提交
使用 commitSync() 提交偏移量最简单也最可靠。这个 API 会提交由 poll() 方法返回的最新偏移量，提交成功后马上返回，如果提交失败就抛出异常。

commitSync() 将会提交由 poll() 返回的最新偏移量，所以在处理完所有记录后要确保调用了 commitSync()，否则还是会有丢失消息的风险。

如果发生了再均衡，从最近一批消息到发生再均衡之间的所有消息都将被重复处理。

同时在这个程序中，只要没有发生不可恢复的错误，commitSync() 方法会一直尝试直至提交成功。如果提交失败，我们也只能把异常记录到错误日志里。

异步提交
同步提交有一个不足之处，在 broker 对提交请求作出回应之前，应用程序会一直阻塞，这样会限制应用程序的吞吐量。我们可以通过降低提交频率来提升吞吐量，但如果发生了再均衡，会增加重复消息的数量。 这个时候可以使用异步提交 API。我们只管发送提交请求，无需等待 broker 的响应。

在成功提交或碰到无法恢复的错误之前，commitSync() 会一直重试，但是 commitAsync() 不会，这也是 commitAsync() 不好的一个地方。 它之所以不进行重试，是因为在它收到服务器响应的时候，可能有一个更大的偏移量已经提交成功。假设我们发出一个请求用于提交偏移量 2000，这个时候发生了短暂的通信问题，服务器收不到请求，自然也不会作出任何响应。与此同时，我们处理了另外一批消息，并成功提交了偏移量 3000。如果 commitAsync() 重新尝试提交偏移量 2000，它有可能在偏移量 3000 之后提交成功。这个时候如果发生再均衡，就会出现重复消息。 commitAsync() 也支持回调，在 broker 作出响应时会执行回调。回调经常被用于记录提交错误或生成度量指标。如果要用它来进行重试，则一定要注意提交的顺序。

同步和异步混合提交
一般情况下，针对偶尔出现的提交失败，不进行重试不会有太大问题，因为如果提交失败是因为临时问题导致的，那么后续的提交总会有成功的。 但如果这是发生在关闭消费者或再均衡前的最后一次提交，就要确保能够提交成功。因此在这种情况下，我们应该考虑使用混合提交的方法：

高可用设计

1. 集群方式（cluster），一个kafka集群由多个broke组成，一个broke宕机，其他机器上的broke依然可以对外服务。

2. 备份机制（replication）：kafka中为了保证消息的安全性，将信息进行了备份，并且定义了两类副本：
   • 领导者副本：生产者首先将消息发送到领导者副本进行备份，领导者副本只有一个。
   • 追随者副本 ：领导者副本，将自己的消息与追随者副本进行同步。追随者副本可以有多个，且可以分为两类：
     • ISR（in - sync replica）：需要同步复制保存的follower。
     • 普通： 与领导者副本之间是异步保存。
   • 当leader失效后，需要选出新的leader，选举原则如下：
     • 优先从ISR中选择，因为ISR中的消息数据是与leader同步的
     • 如果ISR列表中的follower都不行了，就只能从其他follow中选取。
     • 极端情况：所有副本都失效了，这时有两种方案：
       • 等待ISR中的一个活过来，选为leader，数据可靠，但是时间不确定。
       • 选择第一个活过来的副本为leader，不一定位ISR中的， 以最快速度恢复可用性，但是数据不一定完整。

SpringBoot集成Kafka

基本使用

传递对象消息