kafka传递保证语义

Delivery guarantee semantic

  • At most once :消息可能会丢失，但绝不会重复传递。
  • At least once :消息绝不会丢失，但可能会重复传递。
  • Exactly once :每条消息只会被传递一次。

At least once + consumer 幂等。

如何实现Exactly once：

实现Exactly once 需要生产者与消费者两部分共同决定。

生产者

有两个可选的方案：

  • 每个分区只有一个生产者写入消息，出现异常或超时的情况时，生产者就要查询此分区的最后一个消息，用来决定后续操作是重传还是继续发送。
  • 为每个消息添加一个全局唯一主键，生产者不做其他特殊处理，可能会重传，但由消费者对消息去重，实现“Exactly once ”

消费者

消费者处理消息与提交offset的顺序，在很大程度上决定了消费者的语义。

  • 第一种情况，先处理消息，再提交offset。
    假如poll() 返回了10条消息，再处理完第5条时， 消费者宕机。当消费者重新启动 就会从最后提交的offset重新消费。这个时候 有10条消息会被重复消费，其中的5条已经被处理过，会重复处理。这就是 （At least once 语义，每个消息最少被处理一次，可能被重复处理。）
  • 第二种情况，先提交offset，再处理消息.
    假如poll玩消息， 提交offset为8，consumer消费到8， 预期处理到8这个位置 。当处理的消息的offset 为5 ，还没处理到8 . 此时，消费者宕机，再重启 是从8开始消费的。所以有3条消息就丢失了。 （At most once ， 每个消息至多被消费一次，这就导致了有的消息可能不会被处理）

消费者实现Exactly once

一种方案：消费者关闭自动提交offset 、关闭手动提交offset。这样就不适用 kafka中的 Offsets Topic 中记录的offset,由消费者自己保存offset。
利用数据库事务的原子性来实现Exactly once 。 将消息处理结果 与 offset落库放入同一个事务中，事务执行成功 则此消息被消费，否则事务回滚重新消费。
当消费者宕机重启或者Rebalance操作时，消费者可以从关系型数据库中找到对应的offset ,然后调用KafkaConsumer.seek() 方法手动设置消费位置，从此offset处开始消费。
新的问题： 消费者并不知道 消费者组什么时候发生Rebalance。
可以通过 ConsumerRebalanceListener接口 的两个回调方法解决该问题：

  • onPratitionRevoked() 调用时机是停止拉取数据之后，Rebalance之前。可以在这个方法中手动提交offset,避免重复消费。

  • onPratitionAssigned() 调用时机是Rebalance之后，重新拉取数据之前，可以再该方法中手动调整消费者offset的值，用于重新消费。

以上两个方法 解决了Rebalance操作可能带来的问题。