所有消息队列都可能发生的问题
针对这类问题,三种消息队列都提供了生产者消息发送确认的模式,例如将kafka的acks参数设置为大于0,将rabbitMQ的信道设置为confirm模式。而在rocketMQ中会返回消息发送状态码。其中rabbitMQ和rocketMQ还提供了生产者事务操作。
只有某些消息队列才会发生的问题
与生产者类似,若消费者在消费消息失败时未告知消息队列,此消息丢失。kafka,rabbitMQ,rocketMQ都提供了相似的消费成功确认机制来解决这个问题,rabbitMQ通过auto_ack参数设置自动确认或手动确认。
而rocketMQ和kafka通过消息偏移量来控制信息消费,rocketMQ在pull模式下需要自己维护偏移量。
这个很好理解,例如rabbitMQ默认将消息保存再内存中,如果队列崩溃,消息自然丢失
kafka保证同一分区内消息的顺序,也就是说,如果要让某一topic内消息全部有序,只能为该topic设置一个分区,这会降低该主题的吞吐量。通常使用消息的key值将消息散布到不同分区上,以此保证消息的局部有序性,但这种局部有序性的保证仅仅在消息写入分区时是有序的才能保证,例如生产者按顺序消息写入消息A,消息B,消息A写入失败,消息B写入成功,生产者重发消息A且成功,这时候两个消息的顺序就颠倒了,解决方式是设定max.in.flight.requests.per.connection为1,指定生产者在收到消息成功发送的确认之前不允许发送其他信息,但这种方式也会严重降低吞吐量。
另一个问题是kafka默认的分区器使用散列算法将消息的key值映射到对映的分区上,如果增加了分区,key值映射的分区可能会与之前的不一致。在kafka中,一个分区只能被一个消费者消费,保证了消息消费的局部有序性。
rocketMQ的队列(Message Queue)与kafka的分区在概念上相似,所以rocketMQ在消息有序性的保证上自然也是基于队列(Message Queue)的,同kafka一样,如果要让某一主题内的消息有序,必须将此主题内的独写队列数量设为1,但和kafka一样,这种操作会大量降低该主题的吞吐量。
rocketMQ中在发送消息时传入自定义的MessageQueueSelector保证消息生产的局部有序性,在消费消息时push模式下通过MessageListenerOrderly保证顺序消费。
对于rabbitMQ,我没有找到相关的资料,个人猜测,rabbitMQ同一队列内消息的有序性应该是有保障的,但大多数人会在生产者和消费者中增加消息有序性判断
几乎所有的消息队列中都未能提供不重复消息的保证,而且消息重复与消息丢失几乎是二选一的问题,大多数情况下我们选择保证消息不丢失而容忍一部分消息重复,最广泛的解决消息重复的方式是在消费者端对消息进行验证或者保证消费的幂等性