kafka带回调的生产者 回调不起作用 kafka消息回溯

文章目录

• 各大消息队列对比：
• 区别主要包含四个方面：
• 消息队列特征功能

• 时间回溯
• 粘性分配
• 死信
• 延迟队列
• Push模式消费

• 重点：解耦了 partition 与消费者的关联，解决了 Reblance时性能抖动 的问题

• 生产、消费支持并行生产、并行消费，提高生产和消费吞吐量
• 消息轨迹，消息查找，支持以定义方式查询
• 消息端批量消费功能

• 强烈建议阅读

各大消息队列对比：

区别主要包含四个方面：

消息队列特征功能

时间回溯

一般消息在消费完成之后就被处理了，之后再也不能消费到该条消息。消息回溯正好相反，是指消息在消费完成之后，还能消费到之前被消费掉的消息。对于消息而言，经常面临的问题是“消息丢失”，至于是真正由于消息中间件的缺陷丢失还是由于使用方的误用而丢失一般很难追查，如果消息中间件本身具备消息回溯功能的话，可以通过回溯消费复现“丢失的”消息进而查出问题的源头之所在。消息回溯的作用远不止与此，比如还有索引恢复、本地缓存重建，有些业务补偿方案也可以采用回溯的方式来实现。

支持两种回溯的方式：

• 按照 Offset 回溯
• 按照 时间戳 回溯（kafka已经支持了 offset 回溯，所以只需要实现 时间戳到 offset的映射 即可）

粘性分配

是指每次有消费者上线或者下线，都会触及到全部partition重新参与分配，这样每次发送变动的partition数量就会比较多，造成消息消费抖动，为了优化这种场景，实现粘性分配特性，每次分配只变动最少数量的partition，从而避免其他partition受到影响。

如何实现：一个消费者只能消费一个分区，而分区的部署是提前就部署好的，所以只要机器变动，其实不需要整个服务端的 Rebalance，只需要替换这一个分区的消费者即可，我觉得可以让这个分区暂时积压。

死信

死信是消息队里的最基本功能之一，Mafka死信背后是依靠延迟消息来完成的。
当用户遇到暂时不能处理的消息后，可以先投递到死信队列，继续消费后边的消息，等设定的时间到达后，再次消费之前未成功的消息。 同时Mafka还支持设置最大消费次数，达到次数之后不再重复投递，打印消息到日志里后跳过。

延迟队列

• 当你在网上购物的时候是否会遇到这样的提示：“三十分钟之内未付款，订单自动取消”?这个是延迟队列的一种典型应用场景。
• 延迟队列存储的是对应的延迟消息，所谓“延迟消息”是指当消息被发送以后，并不想让消费者立刻拿到消息，而是等待特定时间后，消费者才能拿到这个消息进行消费。
• 延迟队列一般分为两种：基于消息的延迟和基于队列的延迟。基于消息的延迟是指为每条消息设置不同的延迟时间，那么每当队列中有新消息进入的时候就会重新根据延迟时间排序，当然这也会对性能造成极大的影响。
• 实际应用中大多采用基于队列的延迟，设置不同延迟级别的队列，比如5s、10s、30s、1min、5mins、10mins等，每个队列中消息的延迟时间都是相同的，这样免去了延迟排序所要承受的性能之苦，通过一定的扫描策略(比如定时)即可投递超时的消息。

Mafka 支持每个消息改签、撤销、统计等功能。且已经发送给Mafka的延迟消息，可以在消息到期之前重新设定投递时间，或撤销掉，另外还可以在平台上查询统计到未来一段时间即将到期的被投递的消息数量。

Push模式消费

重点：解耦了 partition 与消费者的关联，解决了 Reblance时性能抖动 的问题

生产、消费支持并行生产、并行消费，提高生产和消费吞吐量

消息轨迹，消息查找，支持以定义方式查询

消息端批量消费功能