Kafka常见问题总结

Posted by Yezhiwei on May 25, 2018

在使用 Kafka 时,我们经常会遇到的问题有哪些?

  • 会不会丢消息?
  • Offset 怎么保存?
  • Consumer 重复消费问题怎么处理?
  • 如何保证消息的顺序?
  • 数据倾斜怎么处理?
  • 一个 Topic 分配多少个 Partiton 合适以及修改 Partiton有哪些限制?

如何保证消息不丢失?

  • 消息不丢失对于消息队列来说至关重要,但要实现这一点也是非常困难。因为服务器可能会宕机,磁盘可能会坏,所以对于 Kafka 的消息不丢失主要指以下两方面:
  1. 如果发送失败,发送方要能对它进行重试或者相应处理。
  2. 如果发送成功,要确保当一部分数量的 Kafka 服务器全部被物理销毁,这个消息依旧能够被持久化保存下来。

如何保证消息发布的可靠性

以下引用之前分享的部分PPT内容

  • 当 Producer 将一个 Message 发送到 Topic 被写入到 Leader Partition 中后,并被所有 ISR 给同步到本地,此时只要 ISR 的机器有一台还存活着且磁盘完好,这个消息就能够正常存在。如果在 Leader 刚写入完,但此时 Leader 立马挂了,会导致这个消息永久丢失。如果要实现绝对意义的不丢失,就需要 Producer 当且仅当获到确认通知后,才认为消息发送是成功的。但这种等待的性能损耗会随着 Replication 的数量增多而线形增多。

  • 在有些场景下,我们可以只要求 Leader 写入完成就告诉我们成功了(不用等待写入副本集)。但会存在一个消息重发的情况:当 Leader 写入完成后通知 Producer 时,由于网络原因丢包了,导致 Producer 没收到确认信息,误以为发送失败了,此时又继续发送了同一份消息,这个时候可能会存两份。 此时,Consumer 需要在消费 Message 的时候明确处理这种情况,比如可以在每条消息里加一个全局唯一 ID 去标识一个消息,在消费的时候去判断是否消费过这个消息。

  • 如果在能够接受 Message 丢失的情况,只要不去关注 Leader 的写入成功信息即可,每个消息仅发送一次,不在乎发送是否成功。

  • 在 Kafka 中,我们可以有以下三个参数来处理上述情况:

    1. acks=0: Producer 不等待 Broker 的 acks。发送的消息可能丢失,但永远不会重发。
    2. acks=1: Leader 不等待其他 Follower 同步,Leader 直接写 log 然后发送 acks 给 Producer。
    3. acks=all: Leader 等待所有 Follower 同步完成才返回 acks。

如何保证消息消费的可靠性

以下引用之前分享的部分PPT内容

纠正:在0.8版本之前,Kafka一直将 Consumer 的 Offset 信息记录在 ZooKeeper 中。由于 ZooKeeper 并不适合大批量的频繁写入操作,从0.8.2版本开始 Kafka 开始支持将 Consumer 的 Offset 信息保存在 Kafka 内部的 Topic 中(从0.9.0版本开始默认将 Offset 存储到系统 Topic 中)

  • 在正常情况下,希望消息队列里的消息仅被消费一次,且一定会被消费一次,并且处理结果一定是成功的。
  • Kafka 的 Consumer 机制只是提供了一个保存 Offset 的接口,由于在没有过期的情况下,Kafka 并不会主动去删除消息,所以我们的问题仅仅在于如何去确保保存 Offset 和处理消息成功这两个操作是一个原子操作。

以下引用之前分享的部分PPT内容

  • At most once 至多一次:当可以接受个别消息没有被处理的情况,我们也可以选择先保存 Offset ,再处理消息。

  • At least once 至少一次:如果我们的 Consumer 是一个幂等函数,相同的输入执行多次也不会影响到最终结果。那么我们就能够接受重复处理消息的情况。而此时只要确保所有的消息都能够被至少消费一次就行了。这种场景我们可以选择先处理消息,再保存 Offset 。

  • Exactly once 有且仅有一次:一般情况下,如果 Consumer 仅仅只是做无状态的操作,我们完全不需要考虑它是否多次消费的问题。但大部分时候 IO 操作是有状态的,如将计算结果保存到数据库中的操作。有一种解决方案是,如借助 MySQL insert ingore把每次消费的 Offset 作为一个字段(唯一键或唯一键的一部分)一起存入数据库中。

如何保证消息的顺序

  • Kafka 每个 Partition 都是相互独立的,Kafka 只能保证单个 Partition 下的有序。
  • 局部有序:当我们所需要的有序其实是针对单个用户的有序,而不要求全局有序。我们可以以用户的 ID 作为 key , 确保单个用户一定会被分配到某个固定的 Partition 上(可能会引起数据倾斜问题),这样我们就能够实现单个用户维度的有序了。
  • 如果一定要全局的有序,所有消息都使用同一个 key ,这样他们一定会被分配到同一个 Partition 上,这种做法适用于临时性且数据量不大的小需求,消息量大了会有性能压力。

数据倾斜怎么处理?

  • 为 Producer 选择合适的 Key
  • 假设一个场景,我们需要将每个用户的 Page View 信息给存入 Kafka ,此时我以 userId 来作为 key 。理想情况下这种选择是不会错的,但如果有爬虫来模拟用户操作时,此用户的访问量可能是正常用户的百倍甚至千倍,这时,虽然 userId 作为 key 是均匀分布的,但其背后的数据量却并不一定是均匀分布的,就可能产生数据倾斜的情况,导致各个 Partition 数据量分布不均匀

如何选择 Partiton 的数量

  • 在创建 Topic 的时候可以指定 Partiton 数量,也可以在创建完后手动修改。但 Partiton 数量只能增加不能减少。中途增加 Partiton 会导致各个 Partiton 之间数据量的不平等。
  • Partition 的数量直接决定了该 Topic 的并发处理能力。但也并不是越多越好。Partition 的数量对消息延迟性会产生影响。
  • 一般建议选择 Broker Num * Consumer Num ,这样平均每个 Consumer 会同时读取 Broker 数目个 Partition , 这些 Partition 压力可以平摊到每台 Broker 上。

如有不当之处请指出,后续逐步完善更正