开始

发送请求测试
image.png
商家收到了消息 又把消息重新发回去
image.png
也就是说这里的ack成功了
image.png
怎么看ack是成功了呢？进入我们的管控台刷新一下
image.png

刚才有1条消息没消费了。
image.png

并且这里没有未确认的消息
image.png

不手动签收，就注释这段代码
image.png

重启服务。
image.png

业务里面，业务都在正常跑。
image.png
管控台里面有一条未被签收的消息。微服务在收到这个消息，实际它都处理好了。但是因为我们开通了手工签收这个特性，代码里面我们没有去签收它，所以它一直在RabbitMQ中，看起来是没有被签收。所以它一直有一条消息在队列里。
image.png

这个时候如果我们的客户端重启了，或者微服务关闭了。先关闭微服务。

刷新页面，
image.png
这条消息从未被签收正在处理的状态，马上就回到了redy状态。相当于一个快递员去送快递，快递的接收者看了半天没签收，它如果一直在看，这个包裹就未签收的状态，他如果看了半天直接把门一关，他不说话了，不理那个快递员了。这个快递会被变成未签收状态。又拿回给快递员了。所以这条消息就又变成了ready状态。
image.png
这种重回和真正的重回队列是不一样的

下面演示下真正的重回队列。

Nack，这个方法会多一个参数，最后衣柜参数设置为true。手动的拒收。表示我们收到这条消息，我们手动的拒收，让它重回队列。
image.png
它不断的在重复一条消息。微服务直接卡死了。
image.png
因为我们收到这条消息后，进行手动的拒收。它会直接把这个消息塞回队列。问题是塞回队列后，还是当前这个微服务在监听队列。
image.png
用ack之后服务挂了再回重回ready状态。
用Nack是主动把消息踢回MQ，这样就遭到业务的死循环。
所以手动强制Nack重回队列，这里不太强制使用。

签收多条

用ack，然后是多条。
image.png
但是我们不能来一条消息就签收多条。
每发5条消息就手动签收。能被5整除。
image.png

启动服务测试。
image.png
2条没有签收的。上面测试死循环的时候有1条。刚才又发了1条。
image.png
再点击一次
image.png
变成3条
image.png

再发一条
image.png

4条
image.png

再发一条，5条的时候，会同时被签收
image.png

image.png

手动建channel

用这种类变量的形式有点low。能不能用一些高级的方法，把channel注入进来。
image.png
手动新建channel，然后把这个channel复制进来。
在这里新建connectionFactory，新建channel
image.png

image.png

通过spring注入进来。
image.png

image.png
image.png

所有的channel都是自动注入进来的
image.png

会从config里面找，它的Bean是channel
image.png
重启商家微服务 测试。连续点击5次。
image.png

一次性被签收
image.png

结束