nosql-rabbitmq-消息可靠性

nosql-rabbitmq-消息可靠性、幂等性

1.1 消息发送到Broker

出现失败的原因: 例如设备故障等导致消息发送失败，生产者不能确定Broker有没有正确接收。这就需要给生产者发送消息的接口一个应答。
 
解决方案： 1) 事务模式 2) Confirm模式
分两种：
一种是消息不可达时，把不可达消息写到文本文件中。
二种：消息不可达，把不可达消息写到备份交换机中。（最好方式）

消息队列中存储

导致原因： 重启可能导致内存消息消失，这就要把消息本身和元数据（队列，交换机，绑定）都保存到磁盘。

解决方案： 1）队列持久化 2）交换机持久化 3）消息持久化
 

1.4 消息投递到消费者

1) 自动Ack 2）手动Ack

1.5 消费者回调（根据业务来 重点）

从生产者到Broker，交换机到队列，队列本身，队列到消费者，都有响应的方法知道msg是否正常流转。但是服务端收到ack或者nack之后，生产者知道吗？根据经验是不知道的。但是如果为了保证一致性，生产者必须知道消费者有没有成功消费，怎么办？ 这个是需要从业务层面来进行，两种方式： （1）回调，消费者收到消息，处理完毕后，调用生产者的API。 （2）消费者发送一条响应消息给生产者。

1.6 补偿机制

如果生产者的API没有被调用，也没有收到消费者的响应消息，该如何做？ 这时候可以稍微等一下，可能是消费者处理时间太长或者网络超时，超时之后还没有得到响应的消息才确定为失败，消费失败以后重发消息。 但是问题又来了，谁来发，多久发一次，一共发几次，发一模一样的消息吗？消费者如何进行幂等呢