（七）「消息队列」之 RabbitMQ 发布者确认（使用 .NET 客户端）-Toy模板网

这篇具有很好参考价值的文章主要介绍了（七）「消息队列」之 RabbitMQ 发布者确认（使用 .NET 客户端）。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

发布者确认（Publisher Confirms）

发布者确认是一个 RabbitMQ 扩展，用于实现可靠的发布。当在通道上启用发布者确认时，客户端发布的消息将由代理异步确认，这意味着它们已在服务器端得到处理。

0、引言

先决条件

本教程假设 RabbitMQ 已安装并且正在 本地主机 的标准端口（5672）上运行。如果您使用了不同的主机、端口或凭证，则要求调整连接设置。

获取帮助

如果您在阅读本教程时遇到问题，可以通过邮件列表或者 RabbitMQ 社区 Slack 与 RabbitMQ 官方取得联系。

在本教程中，我们将使用发布者确认来确保已发布的消息已安全到达代理。我们将介绍几种使用发布者确认的策略，并解释它们的利弊。

原文链接：https://www.rabbitmq.com/tutorials/tutorial-seven-dotnet.html

1、在通道上启用发布者确认

发布者确认是 RabbitMQ 对 AMQP 0.9.1 协议的扩展，所以默认情况下它们是不启用的。使用 ConfirmSelect 方法可以在通道层级启用发布者确认：

var channel = connection.CreateModel();
channel.ConfirmSelect();

您必须在期望启用发布者确认的每个通道上调用该方法。确认只需要启用一次，而不是对每条发布的消息都启用。

策略 #1：单独发布消息

让我们从实现带确认的发布的最简单途径开始吧，那就是，发布一条消息并同步等待它确认

while (ThereAreMessagesToPublish())
{
    byte[] body = ...;
    IBasicProperties properties = ...;
    channel.BasicPublish(exchange, queue, properties, body);
    // uses a 5 second timeout
    channel.WaitForConfirmsOrDie(TimeSpan.FromSeconds(5));
}

在前面的示例中我们像往常一样发布消息并使用 Channel#WaitForConfirmsOrDie(TimeSpan) 方法等待它确认。该方法在消息确认后立即返回。如果在超时时间内消息未得到确认或者如果消息已 nack(Negative-Acknowledgement) 了（意味着代理由于某些原因无法处理它），方法会抛出一个异常。异常的处理通常包括记录一个错误消息日志并/或重新尝试发送消息。

不同的客户端库有不同的方式去同步处理发布者确认，所以确保仔细阅读您正在使用的客户端的文档。

这个技术非常简单但也有一个巨大的缺点：它会显著降低发布速度，因为某条消息的确认会堵塞后续消息的发布。这种方法提供的吞吐量不会超过每秒几百条已发布的消息。不过，这对于某些应用程序来说已经足够好了。

发布者确认是异步的吗

在开头我们提到代理是异步确认已发布的消息的，但在第一个例子中，代码是同步等待直至消息确认的。客户端实际上异步接收确认，并相应地解除对 WaitForConfirmsOrDie 的调用阻塞。可以将 WaitForConfirmsOrDie 看作是一个同步 helper，它依赖于底层的异步通知。

策略 #2：批量发布消息

为了改进上面的例子，我们可以发布一批消息并等待这一批消息全部得到确认。如下是一个使用 100 一批次的示例：

var batchSize = 100;
var outstandingMessageCount = 0;
while (ThereAreMessagesToPublish())
{
    byte[] body = ...;
    IBasicProperties properties = ...;
    channel.BasicPublish(exchange, queue, properties, body);
    outstandingMessageCount++;
    if (outstandingMessageCount == batchSize)
    {
        channel.WaitForConfirmsOrDie(TimeSpan.FromSeconds(5));
        outstandingMessageCount = 0;
    }
}
if (outstandingMessageCount > 0)
{
    channel.WaitForConfirmsOrDie(TimeSpan.FromSeconds(5));
}

等待一批消息的确认比等待单个消息的确认大大提高了吞吐量（在远程 RabbitMQ 节点上最多可提高 20-30 倍）。一个缺点是，如果出现故障，我们不知道究竟是哪里出了问题，因此我们可能不得不在内存中保存整个批处理，以记录一些有意义的内容或重新发布消息。这个解决方案仍然是同步的，因此它阻止消息的发布。

策略 #3：异步处理发布者确认

代理异步确认已发布的消息，只需要在客户端上注册一个回调就可以收到这些确认的通知：

var channel = connection.CreateModel();
channel.ConfirmSelect();
channel.BasicAcks += (sender, ea) =>
{
  // code when message is confirmed
};
channel.BasicNacks += (sender, ea) =>
{
  //code when message is nack-ed
};

这儿有两个回调：一个用于已确认的消息，一个用于已 nack 的消息（可以认为是代理丢失的消息）。两个回调都有相应的 EventArgs 参数（ea）包含：

delivery tag

标识已确认或已 nack 消息的序列号。我们将很快看到如何将其与发布的消息关联起来。

multiple

这是一个布尔值。如果为 false，则仅有一条消息确认/nack-ed；如果为 true，所有序列号 小于等于该序列号的消息都确认/nack-ed。

在发布前，可以通过 Channel#NextPublishSeqNo 获得消息的序列号：

var sequenceNumber = channel.NextPublishSeqNo;
channel.BasicPublish(exchange, queue, properties, body);

将消息与序列号关联起来的一种简单方法是使用字典。让我们假设我们想要发送字符串，因为它们很容易转换为用于发布的字节数组。下面是一个代码示例，它使用字典将发布序列号与字符串消息体关联起来：

var outstandingConfirms = new ConcurrentDictionary<ulong, string>();
// ... code for confirm callbacks will come later
var body = "...";
outstandingConfirms.TryAdd(channel.NextPublishSeqNo, body);
channel.BasicPublish(exchange, queue, properties, Encoding.UTF8.GetBytes(body));

发布代码现在使用字典跟踪出站消息。我们需要在确认到达时清理字典，并在消息已 nack 时做一些类似于记录警告的事情：

var outstandingConfirms = new ConcurrentDictionary<ulong, string>();

void CleanOutstandingConfirms(ulong sequenceNumber, bool multiple)
{
    if (multiple)
    {
        var confirmed = outstandingConfirms.Where(k => k.Key <= sequenceNumber);
        foreach (var entry in confirmed)
        {
            outstandingConfirms.TryRemove(entry.Key, out _);
        }
    }
    else
    {
        outstandingConfirms.TryRemove(sequenceNumber, out _);
    }
}

channel.BasicAcks += (sender, ea) => CleanOutstandingConfirms(ea.DeliveryTag, ea.Multiple);
channel.BasicNacks += (sender, ea) =>
{
    outstandingConfirms.TryGetValue(ea.DeliveryTag, out string body);
    Console.WriteLine($"Message with body {body} has been nack-ed. Sequence number: {ea.DeliveryTag}, multiple: {ea.Multiple}");
    CleanOutstandingConfirms(ea.DeliveryTag, ea.Multiple);
};

// ... publishing code

先前的示例中包含一个在确认到达时清理字典的回调。注意，这个回调处理单次和多次确认。这个回调会在确认到达（Channel#BasicAcks）时被使用。用于已 nack 消息的回调将检索消息体并发出警告。然后，它重用之前的回调来清除字典中未完成的确认（无论消息是已确认还是已 nack，都必须删除字典中对应的条目）。

如何跟踪未完成的确认？

我们的示例使用一个 ConcurrentDictionary 跟踪未完成的确认。由于几种原因，这个数据结构十分方便。它允许我们能够轻易地将序列号与消息关联起来（无论消息数据是什么）并允许我们能够通过一个给出的序列 id 轻易地清理条目（以处理多次确认/nack）。最后，它支持并发访问，因为确认回调是在客户端库拥有的线程中被调用的，该线程应该与发布线程保持不同。

除了使用复杂的字典实现外，还有其他方法可以跟踪未完成的确认，比如使用简单的并发哈希表和变量来跟踪发布序列的下界，但它们通常更复杂，不属于“教程”的范畴。

总而言之，异步处理发布者确认通常需要以下步骤：

提供一个方法去关联发布序列号和消息。
在通道上注册确认侦听器，以便在发布者 acks/nacks 到达时得到通知，并执行适当的操作，例如记录或者重新发布已 nack 的消息。在此步骤中，序列号到消息的关联机制也可能需要进行一些清理。
在发布消息之前跟踪发布序列号。

重新发布已 nack 的消息？

在相应的回调中重新发布已 nack 的消息可能很诱人，但应该避免这样，因为确认回调是在（通道不应该执行操作的）I/O 线程中分配的。更好的方案是在内存队列中对消息进行排队，该队列由发布线程轮询。像 ConcurrentQueue 这样的类可以很好地在确认回调和发布线程之间传递消息。

总结

在某些应用程序中，确保已发布的消息到达代理是必要的。发布者确认（Publisher Confirms）是 RabbitMQ 的一个特性，可以帮忙满足这个需求。发布者确认本质上是异步的，但也可以同步处理它们。没有说只有一个绝对的方法来实现发布者确认，这通常取决于应用程序和整个系统中的约束。典型的技术有：

单独发布消息，同步等待确认：简单，但吞吐量非常有限。
批量发布消息，同步等待批处理的确认：简单、合理的吞吐量，但在一些东西出现问题时很难推断。
异步处理：最佳性能和资源使用，错误情况下的良好控制，但还需要参与正确实现的过程（无法直接用现成的）。

2、将所有的东西放到一起

PublisherConfirms.cs 类包含了我们所介绍的技术的代码。我们可以编译它，按原样执行它并看看每项技术的表现如何：

dotnet run

输出会看起来像下面这样：

Published 50,000 messages individually in 5,549 ms
Published 50,000 messages in batch in 2,331 ms
Published 50,000 messages and handled confirms asynchronously in 4,054 ms

运行效果：
（七）「消息队列」之 RabbitMQ 发布者确认（使用 .NET 客户端）,RabbitMQ 消息队列教程,rabbitmq,分布式,.net,c#

如果客户端和服务器位于同一台机器上，那么您的计算机的输出应当与之类似。不出所料单独发布消息表现十分糟糕；但出乎意料的是：与批量发布相比，异步处理的表现有些令人失望。

发布者确认十分依赖于网络，所以我们最好不要在远端节点上尝试，而在生产中，客户端和服务器通常不在同一台机器上却又是更现实的情况。PublisherConfirms.cs 可以很容易地更改为使用非本地节点：

private static IConnection CreateConnection()
{
    var factory = new ConnectionFactory { HostName = "remote-host", UserName = "remote-host", Password = "remote-password" };
    return factory.CreateConnection();
}

重新编译类，再次执行并等待结果：

Published 50,000 messages individually in 231,541 ms
Published 50,000 messages in batch in 7,232 ms
Published 50,000 messages and handled confirms asynchronously in 6,332 ms

我们看到单独发布现在的表现仍然非常糟糕。但是有了客户端和服务器之间的网络，批量发布和异步处理现在表现得差不多，同时异步处理在发布者确认方面还有一点小优势。

请记住，批量发布很容易实现，但是在 negative publisher acknowledgement 的情况下，不容易知道哪些消息不能发送到代理。异步处理发布者确认需要更多的参与实现，但提供了更好的粒度和对发布消息已 nack 时执行的操作的更好控制。