丢数据的情况分两种：
1.mq自己弄丢的
2.消费者消费的时候弄丢的
以rabbitMQ为例：
rabbitMQ可能存在消息丢失的问题：
1.生产者往MQ写消息的时候，消息没到MQ，在网络传输过程中丢了或者是消息到了MQ但是MQ内部出错导致没有保存下来
选择使用的rabbitMQ的事务功能，就是生产者发送消息之前开启rabbit MQ的事务（channel.txSelect),然后发送消息，如果消息没有被rabbitMQ接收到，那么生产者会收到异常报错，此时就可以回滚事务（channel.txRollback),然后重试发送消息；如果收到了消息，那么提交事务（channel.txCommit)。但是问题是rabbitMQ事务机制一搞，基本上吞吐量会下来，因为太耗性能了。
执行如下图所示代码：
//第一步先开启事务机制
channel.txSelect
try{
//发送消息
}catch(Exception e){
channel.txRollback
//再次重试发送这条消息
}
channel.txCommit开启事务机制，是同步的，生产者发送这个消息会同步阻塞住，等待你是成功还是失败。
所以一般使用第二种方式：开启confirm模式。
先把channel设置为confirm模式；
发送一个消息
发送消息完就不用管了
rabbitMQ如果接收到了这条消息，就会回调你生产者本地的一个接口，告诉你说这条消息我已经接收到了
rabbitMQ如果在接收消息的时候报错了，就会回调你的接口，告诉你这个消息接收失败，你可以再次重发一次这个消息
channel.confirm
//发送一个消息
//然后就ok了不用管了
//你会在生产者哪里提供一个供回调的一个回调接口的实现
public void ack(String messageId){
}
public void nack(String messageId){
//再次重发一次这个消息
}生产者这块如果是要保证消息不丢，一般是用confirm机制，异步模式，你发送消息之后不会阻塞，直接可以发送下一个消息
2.rabbitMQ接收到消息，暂存在内存里，消费者还没来得及消费，MQ挂掉了导致内存中的消息丢失
设置持久化，第一个是创建queue的将其设置为持久化的，这样就可以保证rabbitMQ持久化queue的元数据了，但是不会持久化queue里面的数据；
第二个就是发送消息的时候将消息的deliveryMode设置为2，就是将消息设置为持久化，此时rabbitMQ就会将消息持久化到磁盘上去
必须要同时设置这两个持久化。而且持久化可以跟生产者那边的confirm机制配合，只有消息被持久化到磁盘上以后，才会通知生产者ack。
3.消费者消费到消息，但是还没来得及处理，消费者自己挂掉了，但是MQ以为消费者已经处理完了
你打开了消费者的autoAck机制
你消费到了数据之后，消费者会自动通知rabbitMQ说，OK，已经消费了这条数据
如果你消费到了一条消息，还在处理中，没有处理完，此时消费者就自动autoAck了，通知rabbitMQ说这条消息已经消费了
此时不巧，消费者系统宕机了，那条消息就会丢失，但没处理完，而且rabbitMQ还以为这条消息已经处理掉了
解决办法：消费者层面需要将autoAck机制关闭，然后每次自己确定已经处理完了这套消息之后在发送ack给rabbitMQ
如果还没处理完就宕机了，此时rabbitMQ没收到消费者的ACK消息
然后rabbitMQ就会将这条消息重新分配给其他消费者去处理
以Kafka为例：
1）消费端弄丢数据
唯一可能导致消费者弄丢数据的情况，就是消费者消费到了消息，然后消费者那边自动提交了offset，让Kafka以为消费者已经消费好了消息，
其实消费者刚准备处理这条消息，但是还没处理消费者就挂了，此时这条消息就丢了
2）Kafka弄丢数据
生产者给Kafka发送一条消息，消息传到了Kafka的leader，此时Kafka还没有把数据同步到follower上就宕机了。
解决办法：
一般要求起码设置如下4个参数：
给这个topic设置replication.factor参数：这个值必须大于1，要求每个partition至少有两个副本
在Kafka服务端设置min.insync.replicas参数：这个值必须大于1，这个是要求一个leader感知到至少1个follower还跟自己保持联系
在producer端设置acks=all：这个是要求每条数据必须写入所有replica之后才能认为是写成功了
在producer端设置retries=MAX（很大很大很大的一个值，无限次重试的意思）：这个是要求一旦写入失败，就无限重试，卡在这里
3）生产者不会弄丢数据
如果按照上述的思路设置了ack=all，一定不会丢，要求是，你的leader接收到消息，所有的follower都同步到了消息之后，才认为本次写成功了。
如果没满足这个条件，生产者会自动不断的重试，重试无限次。
