消息队列mq 总结整理

防止消息丢失（rabbitmq）

• 生产者弄丢消息（消息发送到mq时半路丢了）
  • 方案：
    • 开启事务：不建议；同步方式；生产者发送数据之前开启rabbitmq事务（channel.txSelect），然后发送消息；吞吐量会下来，太耗性能。
    • 开启confirm模式：建议；异步方式；在生产者那里设置开启confirm模式之后，你每次写的消息都会分配一个唯一的id。写入成功rabbitmq会给你回传一个ack消息，告诉你说这个消息ok了；如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息接收失败，你可以重试或者你可以超时重试。
• rabbitmq弄丢了消息
  • 方案：开启持久化，两个步骤
    • 第一个是创建queue的时候将其设置为持久化的，这样就可以保证rabbitmq持久化queue的元数据，但是不会持久化queue里的数据；
    • 第二个是发送消息的时候将消息的deliveryMode设置为2，就是将消息设置为持久化的。
  • 持久化可和生产者的confirm机制配合用，只有消息被持久化到磁盘之后，才会通知生产者ack了，所以哪怕是在持久化到磁盘之前，rabbitmq挂了，数据丢了，生产者收不到ack，也是可以自己重发的。
• 消费端弄丢了数据
  • rabbitmq的ack机制

防止消息丢失（kafka）

• 生产者弄丢消息（消息发送到mq时半路丢了）
  • 设置了ack=all，一定不会丢，要求是，你的leader接收到消息，所有的follower都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。
• kafka弄丢了消息
  • 场景：某个broker宕机，然后重新选举partiton的leader时，要是此时其他的follower刚好还有些数据没有同步，结果此时leader挂了，然后选举某个follower成leader之后，他就少了一些数据。
  • 所以此时一般是要求起码设置如下4个参数：
    • 1.给这个topic设置replication.factor参数：这个值必须大于1，要求每个partition必须有至少2个副本
    • 2.在kafka服务端设置min.insync.replicas参数：这个值必须大