这里主要对比：Kafka、RocketMQ、RabbitMQ
介绍一下消息生产、存储、消费三者的架构形式。
消息丢失可能存在的场景：
情况一： 生产者发送给MQ的过程消息丢失
在写消息的过程中因为网络的原因，还没到mq消息就丢失了；或者是到了mq，还没返回确认收到消息，消息丢失了，怎么处理？
情况二： Broker存储消息丢失
mq的master节点在接受到消息后，还没来得及同步给slave上面的follower副本，master节点直接宕机了，消息还在内存中，丢失消息了，怎么处理？
情况三： 消费者拉取消息后，消息丢
消费者拉取到了消息，但是还没来得及消费，消费者实例挂掉了，mq以为这条消息已经消费了，怎么处理？
针对“情况一”的解决思路：
方法1：
AMQP很多都支持事务机制，那是不是说我们可以生产者采用同步模式给mq发送消息的过程，打开事务机制，发送一条，mq接受到后返回确认信息后再发送下一条消息？这样肯定行不通的，会使生产者的吞吐量直线下降。
方法2：
对于 RabbitMQ：
它提供了一个异步confirm机制，发完了生产者就不用管了，rabbitmq接收到消息会回调生产者的本地一个接口告诉你消息接收成功了，如果rabbitmq在接收消息是报错了，就会回调这个接口，告诉你这个消息接收失败了，可以重试发送了，不会阻塞下一条消息的发送。对于RocketMQ：它提供了一个异步接收模式， Async
API，Producer只需要把消息发送给mq就可以。mq处理完成之后，调用producer定义好的回调函数，就可以确认是否收到对应messageID的回调确认消息，没有收到就触发retry机制。
对于Kafka：它也提供了异步（async）处理模式，send()方法会返回Futrue对象，通过调用Futrue对象的get()方法，等待直到结果返回。
针对“情况二”MQ把消息弄丢了的解决思路：
1、必须开启持久化，就是消息写入mq后就会刷盘，就算mq自己挂掉了，恢复之后也会读取存储的数据，一般不会丢失，除非还没来得及持久化就挂掉了，这种情况很少，概率极低。
2、配合producer的confirm机制，只有消息被持久化或者大多数副本同步完成后，才返回ack；
3、kafka消费者丢失消息，跟rabbitmq处理机制是一样的，如：kafka
broker自己把消息给丢失了，生产者将消息发送给partion
leader，但是接收完，leader就宕机了，还没同步给follower，而马上另外的partion
follower被选举成了leader，这一块数据丢失了，怎么处理？必须将kafka的副本参数设置大于1，就是说至少有2个副本；kafka还需要设置副本leader至少感知不到一个follower挂掉了，才算leader挂掉了，才能重新选举；broker副本的follower全部同步成功时，才能算生产者写入消息队列写入成功【这样可以保证一条不丢】。
针对“情况三”消费者拉取消息后，消息丢失的解决思路：
1、消费者丢失消息：一般是消费者打开了autoAck的机制，自动提交，但还在处理中，消费者系统宕机了，mq以为消费完了，造成了消费者丢失消息，怎么处理？
解决办法：关闭autoAck，每次处理完了再提交ack/offset，如果还没处理完就宕机了，长时间收不到ack，mq也会重新将这条消息分配给其他的消费者去处理。但是此时你需要自己保证消息的幂等性，因为如果消费者将消息已经消费了，但是返回给mq的确认信息失败了，mq以为你没消费，它会把消息发送给给另外的消费者，或者等该实例恢复后再次发送，引起消息的重复消费，此时，你可以将messageID做唯一键处理。
如果保证消息一条不丢，必须关闭消息过期清理的机制，否则消息积压会触发消息清理的机制，也会造成消息丢失。
