前言
上一节提到的问题，关于在消费端消费了消息后进行回调处理作出应答的机制，再通过RPC的方式进行调用生产端把没有正常消费的消息进行重复的投递的过程，产生的疑问都归结于，broker没有及时的作出回应的情况如何处理的问题，而本节就针对这个生产端以及broker端的应答作出详细的解说，结合上一节的内容作出一个补偿的方案，把项目的优化推进。
broker的确认机制
这个表示生产端发送消息，broker端接收到消息后，会回应，而回应被生产端监听到。
这里只需要配置channel的设置就可以实现
Channel.confirmSelect();
Channel.addConfirmListener;
生产端的伪代码关键的部分是addConfirmListener的内部类的方法，分别是有应答以及没有应答的动作
消费端的代码跟上节的基本都一样，但是生产的时候就可以通过注解的方式来实现
当然，会出现网络问题 ，不管成功还是失败都没有回复，这时候就需要定时任务捉取中间状态的消息进行处理。
Broker的return机制
有些生产的消息不一定都可以到达broker端，这时候就需要return
生产端关键的伪代码，监控不可达的消息，重写匿名内部类里面的方法handleReturn()
消费端的伪代码，只需正常的绑定队列以及交换机
路由规则最好是通过管控台确认，看vhost，看exchange，队列的绑定情况等等，没有问题就可以启动程序。
而生产端的return消息设置为mandatory的话就会把路由不到是消息删除，队列不做存储。
自定义消费端
关键的点就是自定义消费者类，这个类继承DefaultConsumer这个类，
设置签收模式也就是重写handleDelivery()这个方法
