azure - Windows Azure 暂存 <--> 生产导致表存储发生冲突和错误

Question

昨天，当我们尝试更换我们的舞台<-->制作角色时，遇到了可怕的问题/经历。

这是我们的设置:

我们有一个工作角色从队列中获取消息。这些消息在角色上进行处理。 (表存储插入、数据库选择等)。每个队列消息可能需要 1-3 秒，具体取决于他需要发出多少表存储帖子。当一切完成后，他会删除该消息。

交换时出现问题:

当我们的暂存项目上线时，我们的生产 worker 角色开始出错。

当角色想要处理队列消息时，它会给出持续的“EntityAlreadyExists”错误流。由于这些错误，队列消息未被删除。这导致队列消息被放回到队列中并返回到处理等等......

当查看这些队列消息并分析它们会发生什么时，我们看到它们实际上已被处理但没有被删除。

删除这些错误消息后问题并没有结束。新的队列消息也没有处理，而这些消息还没有处理，也没有添加表存储记录，这听起来很奇怪。

当删除暂存和生产并再次发布到生产时，一切都开始正常工作。

可能的问题？

我们几乎不知道到底发生了什么。

• 也许两个角色都收到了相同的消息，其中一个发布了帖子，而另一个角色出错了？
• ...???

可能的解决方案？

我们对如何解决这个“问题”有一些想法。

• 制作有害消息故障转移系统？当出队计数超过 X 时，我们应该删除该队列消息或将其放入单独的“poisonqueue”中。
• 捕获 EntityAlreadyExists 错误，然后删除该队列消息或将其放入单独的队列中。
• ...?????

多重角色

我想我们在设置多个角色时也会遇到同样的问题吗？

非常感谢。

编辑 2012 年 2 月 24 日 - 额外信息

• 我们实际上使用了GetMessage()
• 队列中的每个项目都是唯一的，并将在表存储中生成唯一的消息。有关该过程的更多信息:用户发布了某些内容，并且必须将其分发给某些其他用户。该用户生成的消息将具有唯一的 ID (guid)。该消息将被发布到队列中并由辅助角色拾取。该消息分布在其他几个表中(partitionkey -> UserId、rowkey -> 一些时间戳记和唯一的消息 ID。因此，在正常情况下几乎不可能发布相同的消息。
• 隐形超时可能是一个合乎逻辑的解释，因为某些消息可能会分发到 10-20 个表。这意味着 10-20 次插入而不使用批量选项。您可以设置或延长此隐身时间吗？
• 由于异常而未删除队列消息也可以作为一种解释，因为我们尚未实现任何有害消息故障转移；)。

Answer 1

无论登台与生产问题如何，拥有处理有害消息的机制都至关重要。我们在 Azure 队列上实现了一个抽象层，一旦尝试处理消息达到可配置的次数，该抽象层就会自动将消息移至有害队列。