开始

在此基础上演示多条同步确认机制

循环发10次，不推荐使用这方式，我们这里来演示一下为什么不推荐。
image.png

image.png
启动服务，postman测试，发送了10条消息， 确认返回了一条。
返回了成功，但是并不知道是不是发送的10条都成功了。
image.png

异步确认方法

最麻烦的，看起就来最高级的异步确认方法

new ConfirmListener的时候会自动让我们重写这两个方法。
image.png
deliveryTag：是发送端的编号，发送端的消息序号。就是我们上面的channel发的第几条消息。
multiple：是多条还是单挑的意思。如果是true那么就是多条，false就是确认单条消息，
image.png

如果确认成功了 handleAck会被调用，如果确认失败了 handleNack会被调用。
image.png

加入到channel里面
image.png
发完10条消息后，让线程休眠一下。如果发送完消息线程直接退出了 那么ack和Nack就收不到了。我们的线程首先要活着
image.png
复杂的是实际业务需求中，你成功后去怎么做，失败后去做么做
image.png

重启项目做测试。
image.png

image.png
确认的是第四条及前面的
image.png
7条消息前面的都确认，也就是 567 这三条。
image.png
确认第八条消息，这条消息是个单条的消息
image.png
确认的是9 10这两条
image.png

那么怎么看出来是异步的呢？log这里是线程编号。
image.png
回调的时候用的线程，这是Spring boot应用，启的新的线程。
image.png
来做的异步的确认。确认和我们的业务线程是跑在不同的线程上的。
image.png

异步的线程是不知道 我们发送的第4条消息，它是不知道的
image.png
上面的线程变量里面是知道发送的 第4条消息是啥。
image.png
这个异步线程是不知道的。那么它怎么能知道呢？就需要一些线程之间通信的技术。一般是把消息存到数据库里，存消息是什么，发送编号是什么，等这个异步线程起来之后，再从数据库里把消息查出来。哪条下次的deliveryTag是4，它成功了没，失败了就要重发，或者设置为失败的订单。这样很麻烦，并且有很大的并发问题 。这个发送编号和channel相关。而且它不是全局唯一的。如果我们取了多个横向扩展的orderService 服务多个同时发送的消息之中，它的deliveryTag很可能是重复的。

最终结论，同步单项确认机制，最优。

结束