kafka消费者

1.消费者和生产者分区关系
Kafka 消费者从属于消费者群组。一个群组里的消费者订阅的是同－个主题，每个消费者
接收主题一部分分区的消息。
假设主题 Tl 有 4 个分区，我们创建了消费者 Cl ，它是群组 Gl 里唯一的消费者，我们用
它订阅主题 Tl 。消费者 Cl 将收到主题 Tl 全部 4 个分区的消息，如图 1-1 所示：

如果在群组 Gl 里新增一个消费者 C2 ，那么每个消费者将分别从两个分区接收消息。我们
假设消费者 Cl 接收分区 0 和分区 2 的消息，消费者 C2 接收分区 1 和分区 3 的消息，如图
1-2 所示。

如果群组 G I 有 4 个消费者，那么每个消费者可以分配到一个分区，如图 1-3 所示。

如果我们往群组里添加更多的消费者，超过主题的分区数量，那么有一部分消费者就会被
闲置，不会接收到任何消息，如图 1-4 所示。

在群组中增加消费者是横向伸缩消费能力的主要方式，当Kafak消费者做一些高延迟的操作时，单个消费者无法跟上消息生产的速度，所以可以增加更多消费者，让他们只分担部分分区的消息。不过要注意不要让消费者的数量超过主题分区的数量，多余消费者只会被限制。横向伸缩kafka消费者和消费者群组并不会对性能造成负面影响。

二、消费者群组和分区再均衡

1.再均衡概念

当一个消费者被关闭或发生崩溃时，它就离开群组，原本由它读取的分区将由群组里的其他消费者来读取。在主题发生变
化时 ， 比如管理员添加了新的分区，会发生分区重分配。
分区的所有权从一个消费者转移到另一个消费者，这样的行为被称为再均衡。

2.再均衡的优缺点

优点：再均衡非常重要， 它为消费者群组带来了高可用性和伸缩性（我们可以放心地添加或移除梢费者）。
缺点：再均衡期间，消费者无法读取消息，造成整个群组一小段时间的不可用。另外，当分区被重新分配给另一个消费者时，消费者当前的读取状态会丢失，它有可能还需要去刷新缓存，在它重新恢复状态之前会拖慢应用程序。

3.再均衡的时机

（1）心跳机制
消费者通过向被指派为群组协调器的broker发送心跳来维持它们和群组的从属关系以及它们对分区的所有权关系。消费者会在轮询消息或提交偏移量时发送心跳。如果消费者停止发送心跳的时间足够长，会话就会过期，群组协调器认为它已经死亡，就会触发一次再均衡。
（2）再均衡触发
如果一个消费者发生崩溃，并停止读取消息，群组协调器会等待几秒钟，确认它死亡了才会触发再均衡。在这几秒钟时间里，死掉的消费者不会读取分区里的消息。在清理消费者时，消费者会通知协调器它将要离开群组，协调器会立即触发一次再均衡，尽量降低处理停顿。

三、提交和偏移量

偏移量：消息在分区里的位置
提交：更新分区当前位置的操作
消费者往一个叫作 ＿consul’ler_offset 的特殊主题发送
消息，消息里包含每个分区的偏移量。 如果消费者发生崩溃或者有新的消费者加入群组，就会触发再均衡，完成再均衡之后，每个消费者可能分配到新的分区，而不是之前处理的那个。为了能够继续之前的工作，消费者需要读取每个分区最后一次提交的偏移量，然后从偏移量指定的地方继续处理。

消息重复消费和丢失的原因

如果分区提交的最后一个消息的偏移量小于消费者正在处理的最后一个消息的偏移量，发生再均衡之后，新的消费者会从上一次提交的偏移量位置开始消费，这就导致了消息的重复处理。

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

自动提交

如果 enable .auto.commit 被设为 true ，那么每过5s，消费者会自动把从 poll （） 方告接收到的最大偏移量提交上去。提交时间间隔由 auto.commit.interval.ms 控制，默认值是 5s，这种提交方式用起来很方便，不需用户自己提交，但是自动提交的弊端也很明显，假设我们仍然使用默认的5s提交时间间隔，如果在最后一次提交之后的3s发生了再均衡，再均衡之后，消费者将从最后一次提交的偏移量开始处理消息，但其实这3s内的消息有可能已经被处理过了，所以在提交后的3s内到达的消息会被重复处理。优化方案是修改提交时间间隔来更频繁提交偏移量，减小出现重复消息的几率。

手动提交偏移量

commitSync提交
这个 API 会提交由 poll （） 方能返回 的最新偏移量，提交成
功后马上返回，如果提交失败就抛出异常。不过这种提交方式有一个不足之处，再broker对提交请求作出回应之前，应用程序会一直阻塞，这样会限制应用程序的吞吐量，我们可以通过降低频率来提升吞吐量，但如果发生了再均衡，会增加重复消息的数量。
异步提交commitAsync （）
异步提交API，只需要发送请求，无需等待broker的响应
假设我们发出一个请求用于提交偏移量 2000，这个时候发生了短暂的通信问题 ，服务器收不到请求，自然也不会作出任何响应。与此同时，我们处理了另外一批消息，并成功提交了偏移量 3000。如果CommitAsync （） 重新尝试提交偏移量 2000 ，它有可能在偏移量 3000 之后提交成功。这个时候如果发生再均衡，就会出现重复消息。
commitAsync()也支持回调，在broker作出响应时会执行回调，回调经常被用于记录提交错误或生成度量指标