我们在两个不同的实例上运行云服务。该云服务在服务总线队列上启动接收器。该接收器配置为: 1. 窥视和锁定模式 2. 自动完成 = true 3. RenewLockTimeout = 10 分钟 4. 最大并发消息数 = 1 5. PrefetchCount = 默认(应为0)
据我所知，这意味着最多同时处理两条消息(每个实例一条)，并且一旦消息处理程序完成，消息就会自动从队列中删除。
几天前，Azure 决定更新我们的实例。我从日志中看到，在 18.18 第一个实例被请求停止。 18.24 实例停止，18.27 恢复上线。 18.28，第二个实例被请求停止，并于 18.35 恢复在线。
7 条消息已于 18.23 排队。其中之一在数据库上生成了预期的记录(即处理程序已成功执行)。其他 6 个，NO。死信队列已启用，但为空。
理论上，一旦角色进入 OnStop 方法，我的代码就应该停止接收消息。取消 token 被取消，消息处理程序被“暂停”，导致延迟 10 分钟(因此，据我所知，消息不应该完成，然后应该再次处理)。所以我不能说第一条消息是否已被第一台或第二台机器处理。但已经处理过了。我确信其他 6 个在队列中。
如果消息处理程序中存在异常，我会将其发送到 Application Insights 并重新抛出(以使处理程序失败并再次处理消息)。但我没有证据证明这一点。
我想我已经检查了所有内容，但我不知道为什么这些消息消失了。根据您的经验，那应该是什么？
Azure 关闭后等待 5 分钟正常吗？或者这是我不遵守取消 token 的信号？
谢谢
最佳答案
众所周知，接收方可以通过两种不同的方式从服务总线队列读取消息:ReceiveAndDelete and Peek-lock 。 ReceiveAndDelete模式，如果接收者在处理完消息之前崩溃，消息将会丢失。 Peek-lock模式，如果接收方在处理完消息之前崩溃并且没有完成消息，消息不会丢失/消失。
正如其他人所说，没有看到你的代码，很难找到问题。如果可能，请修改您的代码以设置 OnMessageOptions.AutoComplete property为 false，并显式调用 Complete()接收者处理完消息并在数据库上创建记录后，检查是否可以解决问题。
关于azure - 服务总线队列的噩梦。消息消失了，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/44396272/