RabbitMQ-生产者消息发布时可靠性权衡

 不做任何配置的情况下，生产者是不知道消息是否真正到达RabbitMQ，也就是说消息发布操作不返回任何消息给生产者。怎么保证我们消息发布的可靠性？有以下几种常用机制。

1.无保障：生产着发完即走，不保证消息是否发送到队列

2.失败通知：生产者将消息发送到交换机的时候，发现没有可用路由的队列，发送一个失败通知给生产者

3.发布确认：

         1)、一般确认:消息投递到匹配的队列后返回ACK，否则返回NACK，每发一条都要同步等待服务端返回

         2)、批量确认:每发完一批消息后，同步等待服务端返回消息的接收情况

         3)、异步监听确认:提供一个回调方法，服务端确认收到一条或者多条消息后返回给客户端会回调这个方法进行处理

                三种性能比较：一般确认  <  批量确认  <  异步监听确认 （最快）  

4.备用交换机：当消息没能正常路由到某一个具体的队列时，将消息路由到一个备用队列，保证消息不被丢失

5.高可用队列：队列之间配置镜像队列

6.事务：生产者发送消息之前先开启一个事务，然后发送消息，然后提交事务，等服务端ACK确认事务处理成功，
              此时消息才算发送成功。事务发送会严重降低MQ性能，降低2倍以上

7.事务+高可用队列：

8.消息持久化：可以设置消息持久化，队列持久化。当设置队列和消息持久化后，MQ重启后消息依然存在。
                         1)、只设置队列持久化，MQ重启后消息会丢失
                         2)、只设置消息持久化，重启之后队列消失，继而消息也会丢失，队列都丢了，消息也会丢失