今天在项目中引入AMQP的依赖，版本为 3.2.0，在配置文件中配置发布者确认消息时，显示
publisher-confirms: true已经过时，取而代之的是publisher-confirm-type:后面有三个值可选：simple、correlated、none
源码
发布者确认策略有三种：官网描述如下
Streaming Confirms
单独发布信息并使用流式确认（异步 API 元素：确认事件处理程序、未来/承诺等）。
- 在通道(channel)上启用publisher confirms
- 为每个已发布的信息添加一个映射条目(map entry)，将当前序列号映射到信息上
- 当收到ack肯定应答时，删除条目
- 当收到否定回执时，删除该条目，并将其信息安排为重新发布（或其他合适的方式）。
在 RabbitMQ Java 客户端中，确认处理器(
confirm handler)通过 ConfirmCallback 和 ConfirmListener 接口公开。必须为通道添加一个或多个监听器
Batch Publishing
发布一批信息并等待所有未确认的信息。这种策略包括分批发布信息并等待整批信息得到确认。对批次进行重试。
- 在通道(channel)上启用publisher confirms
- 对于每批已发布的message，等待所有尚未确认的message
- 当所有确认结果均为成功时，发布下一批消息
- 如果出现负确认或超时，则重新发布整批或仅发布相关信息
有些客户端提供了方便的 API 元素，用于等待所有未完成的确认。例如，在 Java 客户端中就有 Channel#waitForConfirms(timeout)。
由于这种方法需要等待确认，因此会对发布者的吞吐量产生负面影响。批量越大，影响就越小。
Publish-and-Wait
发布一条信息，然后立即等待未收到的确认信息。这可以看作是上述批量发布策略，其中批量大小等于 1。这种方法会对吞吐量产生极大的负面影响，因此不推荐使用。
实际测试下来，发现除了none，另外两个参数simple和correlated都可以通过ConfirmCallback监听器获取到id和ack信息。
