1.消息丢失

1.生产者发送失败

所有消息队列都可能发生的问题

1. 生产者发送消息后，队列未成功接收（网络原因或其他）而生产者不知情，消息丢失
2. 生产者发送消息后，队列接收成功->生产者确认，但消息并未持久化，队列崩溃，消息丢失

针对这类问题，三种消息队列都提供了生产者消息发送确认的模式，例如将kafka的acks参数设置为大于0，将rabbitMQ的信道设置为confirm模式。而在rocketMQ中会返回消息发送状态码。其中rabbitMQ和rocketMQ还提供了生产者事务操作。

只有某些消息队列才会发生的问题

1. kafka和rabbitMQ在集群状态下当前首领不可用时会进行首领选举。在kafka中，如果把acks设置为1（只要首领节点收到生产者发送的消息即确认发送成功）时，若当前首领收到的消息但还未同步至从任一节点就崩溃了，kafka会在还来不及判定的非同步从节点中选举出首领，这时消息丢失，解决方式是将acks设置未all，即全部从节点同步成功再确认。而在rabbitMQ中，新加入的镜像节点不会同步在此之前的消息，当老的消息还未完全消费完，老节点全部崩溃时，新节点被选举为首领时，会丢失所有未消费的旧消息（目前好像没有什么好的解决方式）。
2. kafka中，即使及时的将所有未同步消息的节点成功判定未非同步节点，也要在消息丢失和系统不可用之间做出权衡，如果不希望消息丢失，则在首领节点恢复前整个系统不可用，通过参数unclean.leader.election.enable可以设置非同步副本是否能成为首领节点。
   
3. rocketMQ集群环境下，broker主从使用异步复制模式时，若master节点崩溃且数据无法恢复，会丢失还未同步至从节点的部分消息，解决方式是使用同步双写的方式同步消息，但会降低吞吐率。

2.消费者消费失败

与生产者类似，若消费者在消费消息失败时未告知消息队列，此消息丢失。kafka，rabbitMQ，rocketMQ都提供了相似的消费成功确认机制来解决这个问题，rabbitMQ通过auto_ack参数设置自动确认或手动确认。而rocketMQ和kafka通过消息偏移量来控制信息消费，rocketMQ在pull模式下需要自己维护偏移量。

3.队列因为自身体原因丢失数据

这个很好理解，例如rabbitMQ默认将消息保存再内存中，如果队列崩溃，消息自然丢失

2.消息顺序

1.kafka

kafka保证同一分区内消息的顺序，也就是说，如果要让某一topic内消息全部有序，只能为该topic设置一个分区，这会降低该主题的吞吐量。通常使用消息的key值将消息散布到不同分区上，以此保证消息的局部有序性，但这种局部有序性的保证仅仅在消息写入分区时是有序的才能保证，例如生产者按顺序消息写入消息A，消息B，消息A写入失败，消息B写入成功，生产者重发消息A且成功，这时候两个消息的顺序就颠倒了，解决方式是设定max.in.flight.requests.per.connection为1,指定生产者在收到消息成功发送的确认之前不允许发送其他信息，但这种方式也会严重降低吞吐量。另一个问题是kafka默认的分区器使用散列算法将消息的key值映射到对映的分区上，如果增加了分区，key值映射的分区可能会与之前的不一致。在kafka中，一个分区只能被一个消费者消费，保证了消息消费的局部有序性。

2.rocketMQ

rocketMQ的队列（Message Queue）与kafka的分区在概念上相似，所以rocketMQ在消息有序性的保证上自然也是基于队列（Message Queue）的，同kafka一样，如果要让某一主题内的消息有序，必须将此主题内的独写队列数量设为1，但和kafka一样，这种操作会大量降低该主题的吞吐量。rocketMQ中在发送消息时传入自定义的MessageQueueSelector保证消息生产的局部有序性，在消费消息时push模式下通过MessageListenerOrderly保证顺序消费。

3.rabbitMQ

对于rabbitMQ，我没有找到相关的资料，个人猜测，rabbitMQ同一队列内消息的有序性应该是有保障的，但大多数人会在生产者和消费者中增加消息有序性判断

3.消息重复

几乎所有的消息队列中都未能提供不重复消息的保证，而且消息重复与消息丢失几乎是二选一的问题，大多数情况下我们选择保证消息不丢失而容忍一部分消息重复，最广泛的解决消息重复的方式是在消费者端对消息进行验证或者保证消费的幂等性