众所周知rabbitmq是一个中间件，作用呢是帮助系统高效处理消息，解决了传统项目复杂业务（多个非核心操作）串行同步，带来的响应时间长，容错能力低，耦合性高。它实现了AMQP协议高级消息队列协议。
如何解决这三个问题（异步处理机制，消息重试机制，设计解耦）
异步处理机制（系统处理完核心操作就给使用者反馈触发生产者将非核心操作（失败不会影响业务核心功能），发送到消息队列，让消费者根据自身情况处理）
消息重试机制（当消息发送给消费者，消费者迟迟不返回ACK消息，则重复几次还是没有->死信队列人工处理）
设计解耦（消费者错误或修改不影响其他角色）
主要包含 生产者 ， 消费者 ，交换机 ，消息队列 四个角色展开活动
消息的传递过程 生产者->交换机->消息队列->消费者
实际业务使用 生产者产生消息并发送给交换机，交换机根据消息中的路由键来判断发送给哪一个消息队列，消费者监听消息队列从而获取消息并且消费消息。
那么其中关撬有很多了，消息在传递过程中丢失了咋办？消息队列占满了咋办？消息一直在消息队列中不管是不是被消费？消费者获取到信息消费失败咋办？rabbitmq容器宕机了咋办？
第一个问题：如何识别消息被接收成功以及触发重新发送 主要是这个 生产者->交换机->消息队列过程
第二个问题：消息队列的删除机制
第三个问题：不是，消息被消费完成，消费者会给队列发送ACK消息，队列收到该消息把对应的消息删除
第四个问题：消息重试，当队列迟迟没有收到ACK消息，重新发送消息给指定消费者
第五个问题：消息以及交换机配置信息持久化
这几个问题就是rabbitmq,设计的核心所在
注意消费者不是系统的使用者，而是监听和处理消息的一个类。
使用者只是业务的触发者。
估计错误有很多记录