rabbitmq持久化,确认机制

一 rabbitmq 持久化
交换机，队列，消息的三者的持久化,交换机，队列的持久化保证rabbitmq服务出现异常，重启后，交换机，队列依然健在，由此保证消费端可以按正常流程找到到对应的交换机，队列,但是如果消息没有持久化是没有意义的.

exchange 持久化

队列持久化

消息持久化,在发送消息的时候持久化

二 消息传递过程可能会丢失的环节
将queue，exchange, message等都设置了持久化之后就能保证100%保证数据不丢失了嚒？
答案是否定的。
首先，从consumer端来说，如果这时autoAck=true，那么当consumer接收到相关消息之后，还没来得及处理就crash掉了，那么这样也算数据丢失，这种情况也好处理，只需将autoAck设置为false(方法定义如下)，然后在正确处理完消息之后进行手动ack（channel.basicAck）

2 从producer端来说,生产者发送消息, 先发送消息到Exchange, 然后Exchange再路由到Queue, 这中间就需要确认两个事情

(1)确认消息是否成功发送到Exchange
(2)确认消息是否从Exchange成功路由到Queue

(1.1) 确认消息是否成功发送到Exchange
有2种方式, 一种是重量级的事务消息机制。采用类事务的机制把消息投递到MQ，可以保证消息不丢失，但是性能极差，经过测试性能会呈现几百倍的下降。
所以说现在一般是不会用这种过于重量级的机制，而是会用轻量级的confirm机制.

(1.2)另一种方式是confirm机制, 跟手动ack机制类似, 生产者将消息投递到RabbitMQ, 且将消息持久化到硬盘后, RabbitMQ会通过一个回调方法将confirm信息回传给生产端, 这样, 如果生产端的服务接收到了这个confirm消息，就知道是已经持久化到磁盘了。否则如果没有接收到confirm消息，那么就说明这条消息可能半路丢失了，此时你就可以重新投递消息到MQ去，确保消息不会丢失。（以下回调函数未成功，还请大神会贴指正是哪个地方的错误 ）

(2) 确认消息是否从Exchange成功路由到Queue(以下方法也未实现成功，不上代码了)
实现ReturnCallback并重写returnedMessage回调方法, 可以确认消息从EXchange路由到Queue失败, 注意: 这里的回调是一个失败回调, 只有消息从Exchange路由到Queue失败才会回调这个方法

三 unack消息的积压问题
什么叫unack消息的积压问题, 简单来说就是消费者处理能力有限, 无法一下将MQ投递过来的所有消息消费完, 如果MQ推送消息过多, 比如可能有几千上万条消息积压在某个消费者实例内存中, 此时这些积压的消息就处于unack状态, 如果一直积压, 就有可能导致消费者服务实例内存溢出、内存消耗过大、甚至内存泄露所以, RabbitMQ是必须要考虑一下消费者服务的处理能力的。

php中amqp的相关的接口地址 [http://docs.php.net/manual/da/book.amqp.php] ,(http://docs.php.net/manual/da/book.amqp.php)

参考文章:https://segmentfault.com/a/1190000004924668