RabbitMQ消息队列(九)：Publisher的消息确认机制.docxVIP

RabbitMQ 消息队列（九） ：Publisher 的消息确认机制 在前面的文章中提到了 queue和consumer之间的消息确 认机制：通过设置 ack。那么Publisher能不到知道他post的 Message有没有到达queue，甚至更近一步，是否被某个 Consumer 处理呢？毕竟对于一些非常重要的数据，可能 在我们Publisher 需要确认某个消息已经被正确处理。 在我们 的系统中，我们没有是实现这种确认，也就是说，不管 Message是否被 Consume 了，Publisher 不会去 care。他只是 将自己的状态 publish 给上层，由上层的逻辑去处理。如果 Message没有被正确处理，可能会导致某些状态丢失。但是 由于提供了其他强制刷新全部状态的机制，因此这种异常情 况的影响也就可以忽略不计了。对于某些异步操作， 况的影响也就可以忽略不计了。 对于某些异步操作， 比如客户端需要创建一个 Filesystem，这个可能需要比较长 的时间，甚至要数秒钟。 这时候通过 RPC 可以解决这个问题。 那么，有因此也就不存在 Publisher 端的确认机制了。 那么，有 没有一种机制能保证 Publisher能够感知它的Message有没有 被处理的？答案肯定的。在这里感谢笑天居士同学：他在我 的《 RabbitMQ 消息队列（三） ：任务分发机制》文后留言 起讨论了问题，而且也查找了一些资料。在这里我整理了 他转载和一篇文章和原创的一篇文章。衔接已经附后。 事务机制 Vs Publisher Confirm 如果采用标准的 AMQP 协议，则唯一能够保证消息不会丢失的方式是利用事务机制 -- 令 channel 处于transactional 模式、向其 publish 消息、执行 commit 动作。在这种方式下，事务机制会带来大量的多余开销，并会导致吞吐量下降 250% 。为了补救事务带来的问题，引入了confirmation 机制(即 Publisher Confirm )。为了使能confirm 机制， 如果采用标准的 AMQP 协议，则唯一能够保证消息 不会丢失的方式是利用事务机制 -- 令 channel 处于 transactional 模式、向其 publish 消息、执行 commit 动作。 在这种方式下，事务机制会带来大量的多余开销，并会导致 吞吐量下降 250% 。为了补救事务带来的问题，引入了 confirmation 机制(即 Publisher Confirm )。 为了使能 confirm 机制， client 首先要发送 confirm.select 方法帧。取 决于是否设置了 no-wait 属性， broker 会相应的判定是否以 confirm.select-ok 进行应答。一旦在 channel 上使用 confirm.select 方法， channel 就将处于 confirm 模式。处于 transactional 模式的 channel 不能再被设置成 confirm 模 式，反之亦然。 旦 channel 处于 confirm 模式， broker 和 client 都将启动消息计数（以 confirm.select 为基础从 1 开始计数）。 broker 会在处理完消息后，在当前 channel 上 通过发送 basic.ack 的方式对其进行 confirm 。 delivery-tag 域的值标识了被 confirm 消息的序列号。 broker 也可以通过 设置 basic.ack 中的 multiple 域来表明到指定序列号为止 的所有消息都已被 broker 正确的处理了。 在异常情 broker 将况中， broker 将无法成功处理相应的消息，此时 发送 basic.nack 来代替 basic.ack broker 将 basic.nack 中各域值的含义与 basic.ack 中相应各域含义是 相同的，同时 requeue 域的值应该被忽略。通过 nack 一或多条消息， broker 表明自身无法对相应消息完成处理，并拒 绝为这些消息的处理负责。在这种情况下， client 可以选择 将消息 re-publish 将消息 re-publish 。 在 channel 被设置成 confirm 模 式之后，所有被 publish 的后续消息都将被 confirm （即 ack） 或者被 nack 一次。但是没有对消息被 confirm 的快 慢做任何保证，并且同一条消息不会既被confirm 慢做任何保证，并且同一条消息不会既被 confirm 又被 nack 。 消息在什么时候确认 broker 将在下面的情况