rabbitmq如何保证消息的可靠性
1、保证消息不丢失
1.1、开启事务（不推荐）
1.2、开启confirm（推荐）
1.3、开启RabbitMQ的持久化（交换机、队列、消息）
1.4、关闭RabbitMQ的自动ack（改成手动）2、保证消息不重复消费
2.1、幂等性（每个消息用一个唯一标识来区分，消费前先判断此标识有没有被消费过，若已消费过，则直接ACK）rabbitmq如何保证消息的顺序性
将消息放入同一个交换机，交给同一个队列，这个队列只有一个消费者，这个消费者只允许同时开启一个线程rabbitMQ保证消息不丢失的具体方案
前提：
(1)开启confirm
(2)开启RabbitMQ的持久化（交换机、队列、消息）
(3)关闭RabbitMQ的自动ack（改成手动）
(4)配置消费重试次数，消费重试间隔时间等
1、保证投放消息不丢失
（1）先将消息放入生产者Redis（此时消息的状态为未投放），再放入队列
（2）根据conform（ReturnCallback和ConfirmCallback）的结果来确定消息是否投递成功，
投递成功的，修改生产者redis中此消息的投递状态为已投递
投递失败的将会放入失败的Redis，并从生产者Redis中删除，由定时任务定期扫描并重新投递
（3）需要一个专门的定时任务扫描生产者Redis中存放了一定时间，但是状态还是未投放的消息
此消息会被认为已经投递，但是没有任何反馈结果（由于不可知因素，导致没有ReturnCallback，也没有ConfirmCallback），
此类消息被扫描到后，会放入失败的Redis，并从生产者Redis中删除，由定时任务定期扫描并重新投递
（4）还需要一个专门的定时任务扫描生产者Redis中存放了很久，仍然未消费的数据（状态为已投递），此类消息被扫描到后，会放入失败的Redis，并从生产者Redis中删除，由定时任务定期扫描并重新投递
（5）扫描失败的Redis的定时任务都遵循一条原则，一条消息最多被重新投递三次，若投递了三次仍然失败，则记录日志，记录到数据库，不会再投递，需要人工干预处理
2、保证消费消息不丢失
（1）消费者取到消息后，从消息中取出唯一标识，先判断此消息有没有被消费过，若已消费过，则直接ACK（避免重复消费）
（2）正常处理成功后，将生产者Redis中的此消息删除，并ACK（告诉server端此消息已成功消费）
（3）遇到异常时，捕获异常，验证自己在消息中设定的重试次数是否超过阀值，若超过，则放入死信队列，若未超过，则向将消息中的重试次数加1，抛出自定义异常，进入重试机制
（4）有专门的消费者用于处理死信队列中消费多次仍未消费成功的数据，可以记录日志，入库，人工干预处理
集群部署方案
rabbitmq有两种集群部署方案
1、普通模式
rabbit01和rabbit02两个节点仅有相同的元数据，即队列的结构
消息实体只存在于其中一个节点rabbit01（或者rabbit02）
当消息进入rabbit01节点的Queue后，consumer从rabbit02节点消费时，RabbitMQ会临时在rabbit01、rabbit02间进行消息传输，把A中的消息实体取出并经过B发送给consumer
2、镜像模式
把需要的队列做成镜像队列，存在与多个节点，消息实体会主动在镜像节点间同步，属于RabbitMQ的HA方案。
副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。
