Azure 服务总线：什么是请求和消息？

Question

我们的应用程序使用 Azure 服务总线进行消息传递。我们创建了一些主题和订阅者。我们每天会发送大约 500 条消息，但在图表中显示了对 500 条消息的数十万个请求。我们的账单价格也在每月 800 美元左右。这对于 500 * 30 条消息来说太多了。我不明白为什么价格这么高，而且我想知道图中的请求是什么意思？.

如果价格的原因是请求数量，那么我怎样才能减少请求数量？我正确看到的消息。问题仅在于请求。

这只是一个示例图供您参考（非原创）。在原始图表中，我看到大约 100k 个请求 500 条消息。

Answer 1

在这里，常见问题解答下： https://azure.microsoft.com/en-us/pricing/details/service-bus/

如何计算队列和主题的操作计量？

对于代理实体（队列和主题/订阅），一个操作 是任何协议上与服务总线服务的任何 API 交互。

发送、接收删除小于或等于的消息 64KB 大小被视为一项计费操作。如果消息 大小大于 64KB，可计费操作数为 根据消息大小以64KB的倍数计算。为了 例如，发送到服务总线的 8 KB 消息将按 1 KB 计费 操作，但发送到服务总线的 96 KB 消息将被计费 作为两个操作。带锁读取8KB消息，然后 完成或明确放弃该消息将按两次计费 运营。更新消息的锁定也会产生操作。

同一消息的多次传递（例如消息扇出 多个订阅者或放弃、推迟后的消息检索， 或死字）将被视为独立操作。为了 例如，对于具有三个订阅的主题，单个 发送并随后接收的 64KB 消息将生成四个 可计费操作，一个“输入”加三个“输出”，假设所有消息 发送到所有订阅并在读取期间删除。

另外创建、读取（列出）、更新和删除 队列、主题或订阅都会产生操作费用。

操作是针对队列或主题/订阅进行的 API 调用 服务端点。这包括管理、发送/接收和会话 状态操作。

Answer 2

这是我在docs中找到的内容，但不完全确定这是否是您正在寻找的：

创建队列或订阅客户端时，可以指定接收模式：Peek-lock 或 Receive and Delete。默认接收模式为 PeekLock。在默认模式下运行时，客户端发送请求以从服务总线接收消息。客户端收到消息后，发送请求来完成消息。

将接收模式设置为 ReceiveAndDelete 时，这两个步骤将合并在一个请求中。这些步骤减少了总体操作数量，并且可以提高总体消息吞吐量。这种性能提升伴随着丢失消息的风险。