问题描述
我正在使用Azure服务总线队列来满足我的要求之一。要求很简单，azure函数将充当API并在队列中创建多个作业。该功能是可扩展的，并且可以按需创建新实例。微服务创建的作业将由Windows服务处理。因此，发送方是Azure功能，而接收方是Windows服务。由于azure函数具有可伸缩性，因此将有多个函数可以并行执行。因此，被创建到队列中的作业数量将是并行的，每500MS中可能会有一个作业。 Windows服务是一个实例，它是一个队列侦听器，它侦听此队列并并行执行。因此，发送方的数量可能更多，接收方是一个实例。而且必须限制每个并行运行的作业（4，因为这需要更多时间和cpu）。现在，我将Aure Service Bus Queue与以下配置一起使用。我怀疑哪种配置可以满足此特定需求的最佳性能。
对我来说，删除队列中的Job不会成为问题。因此，我可以使用Delete代替Peek-Lock吗？
此外，现在，侦听器接收到的项目数不正确。我想维护创建它的顺序。我的要求是最大的性能。 Windows服务完成了这项工作，这是一项占用大量cpu的任务，因此，由于系统是4核，所以我限制为4。
最大传递计数：4，消息锁定持续时间：5分钟，MaxConcurrentCalls：4（在侦听器中）。我是服务公交的新手，对此我需要个建议。
另一个疑问是，让我们考虑侦听器并行获得4个作业并开始执行。一项工作完成了执行并成为完成状态。因此，侦听器将立即选择下一项或等待所有4个作业完成（MaxConcurrentCalls：4个）。
解决方法
对我来说，删除队列中的Job不会成为问题。因此，我可以使用Delete代替Peek-Lock吗？
在PeekLock接收模式下接收邮件的性能要比ReceiveAndDelete差。您将保存往返代理的往返时间以完成消息。
最大传递计数：4，消息锁定持续时间：5分钟，MaxConcurrentCalls：4（在侦听器中）。我是服务公交的新手，对此我需要个建议。
MaxDeliveryCount是消息在被消灭之前可以尝试的次数。它看起来等于内核数，但不应该如此。可能只是巧合。
MessageLockDuration仅在您使用PeekLock接收模式时才重要。对于ReceiveAndDelete没关系。
对于并发性，即使您的工作受CPU限制，但如果可以实现更高的并发性，我都会进行基准测试。
消息接收器上要调查的另一个参数是PrefetchCount。通过减少与代理的往返次数，可以提高整体性能。
另一个疑问是，让我们考虑侦听器并行获得4个作业并开始执行。一项工作完成了执行并成为完成状态。因此，侦听器将立即选择下一项或等待所有4个作业完成（MaxConcurrentCalls：4个）。
当您的并发设置为4并且一个消息处理已完成时，侦听器将立即开始处理第5条消息。
此外，现在，侦听器接收到的项目数不正确。我想维护创建它的顺序。
要按发送顺序处理消息，您将需要使用sessions发送和接收消息。
我的要求是达到最佳性能。 Windows服务完成了这项工作，这是一项占用大量CPU的任务，因此，由于系统是4核，所以我限制为4。
要考虑很多事情。 Windows服务位置的位置可能会影响延迟和消息吞吐量。向外扩展可能会有所帮助，等等。