Azure 服务总线：什么是请求和消息？
Azure Service Bus: What is a request and a message?
我们的应用程序使用 Azure 服务总线进行消息传递。我们创建了一些主题和订阅者。我们每天将发送大约 500 条消息，但在图中它显示了对 500 条消息的数十万个请求。我们的账单价格也是每月 800 美元左右。这对于 500 * 30 条消息来说太多了。我无法理解为什么价格这么多，我也想知道图中的请求是什么意思？
如果价格的原因是请求数量，那么我该如何减少请求数量？。我看到的消息是正确的。问题仅在于请求。
这只是一个示例图表，供您参考（非原创）。在原始图表中，我看到大约 100k 请求 500 条消息。
在这里，在常见问题解答下：
https://azure.microsoft.com/en-us/pricing/details/service-bus/
如何计算队列和主题的操作计量器？
对于代理实体（队列和 topics/subscriptions），操作是在任何协议上与服务总线服务的任何 API 交互。
对于大小小于或等于 64KB 的邮件，发送、接收删除被视为一次计费操作。如果消息大于64KB，计费操作数按照消息大小的64KB的倍数计算。例如，发送到服务总线的 8 KB 消息将按一次操作计费，而发送到服务总线的 96 KB 消息将按两次操作计费。读取带有锁的 8KB 消息，然后完成或显式放弃消息将被计为两次操作。更新对消息的锁定也会引发操作。
同一消息的多次传递（例如，消息扇出给多个订阅者或在放弃、延迟或死信后检索消息）将被计为独立操作。例如，在具有三个订阅的主题的情况下，发送和随后接收的单个 64KB 消息将生成四个计费操作，一个“输入”和三个“输出”，假设所有消息都传递给所有订阅并在读取期间删除.
此外，创建、读取（列出）、更新和删除队列、主题或订阅都会产生操作费用。
操作是针对队列或 topic/subscription 服务端点进行的 API 调用。这包括管理、Send/Receive 和会话状态操作。
这是我在 docs 中找到的内容，但不能完全确定这是否是您要查找的内容：
When creating a queue or subscription client, you can specify a receive mode: Peek-lock or Receive and Delete. The default receive mode is PeekLock. When operating in the default mode, the client sends a request to receive a message from Service Bus. After the client has received the message, it sends a request to complete the message.
When setting the receive mode to ReceiveAndDelete, both steps are combined in a single request. These steps reduce the overall number of operations, and can improve the overall message throughput. This performance gain comes at the risk of losing messages.
我们的应用程序使用 Azure 服务总线进行消息传递。我们创建了一些主题和订阅者。我们每天将发送大约 500 条消息，但在图中它显示了对 500 条消息的数十万个请求。我们的账单价格也是每月 800 美元左右。这对于 500 * 30 条消息来说太多了。我无法理解为什么价格这么多，我也想知道图中的请求是什么意思？
如果价格的原因是请求数量，那么我该如何减少请求数量？。我看到的消息是正确的。问题仅在于请求。
这只是一个示例图表，供您参考（非原创）。在原始图表中，我看到大约 100k 请求 500 条消息。
在这里，在常见问题解答下： https://azure.microsoft.com/en-us/pricing/details/service-bus/
如何计算队列和主题的操作计量器？
对于代理实体（队列和 topics/subscriptions），操作是在任何协议上与服务总线服务的任何 API 交互。
对于大小小于或等于 64KB 的邮件，发送、接收删除被视为一次计费操作。如果消息大于64KB，计费操作数按照消息大小的64KB的倍数计算。例如，发送到服务总线的 8 KB 消息将按一次操作计费，而发送到服务总线的 96 KB 消息将按两次操作计费。读取带有锁的 8KB 消息，然后完成或显式放弃消息将被计为两次操作。更新对消息的锁定也会引发操作。
同一消息的多次传递（例如，消息扇出给多个订阅者或在放弃、延迟或死信后检索消息）将被计为独立操作。例如，在具有三个订阅的主题的情况下，发送和随后接收的单个 64KB 消息将生成四个计费操作，一个“输入”和三个“输出”，假设所有消息都传递给所有订阅并在读取期间删除.
此外，创建、读取（列出）、更新和删除队列、主题或订阅都会产生操作费用。
操作是针对队列或 topic/subscription 服务端点进行的 API 调用。这包括管理、Send/Receive 和会话状态操作。
这是我在 docs 中找到的内容，但不能完全确定这是否是您要查找的内容：
When creating a queue or subscription client, you can specify a receive mode: Peek-lock or Receive and Delete. The default receive mode is PeekLock. When operating in the default mode, the client sends a request to receive a message from Service Bus. After the client has received the message, it sends a request to complete the message.
When setting the receive mode to ReceiveAndDelete, both steps are combined in a single request. These steps reduce the overall number of operations, and can improve the overall message throughput. This performance gain comes at the risk of losing messages.