azure - azure 幂等操作的模式？

Question

有人知道设计幂等操作到 azure 操作的模式，特别是表存储吗？更常见的方法是生成 id 操作并将其缓存以验证新的执行，但是，如果我有数十个工作人员处理操作，则这种方法会更加复杂。 :-))

谢谢

Answer 1

好的，所以您还没有按照 knightpfhor 的要求提供示例和 codingoutloud 。也就是说，这是处理幂等操作的一种非常常见的方法:将所需的操作推送到 Windows Azure 队列。然后，无论您拥有多少辅助角色实例，一次只能有一个实例处理特定队列项。当从队列中读取队列消息时，它会在您指定的时间内变得不可见。

现在:在处理该消息期间可能会发生一些事情:

• 您在超时期限后完成处理。当您要删除消息时，您会遇到异常。
• 您意识到时间不够了，因此增加了队列消息超时(今天，您必须调用 REST API 来执行此操作；有一天它将包含在 SDK 中)。
• 出现问题，在您删除消息之前导致代码出现异常。最终，消息在队列中再次可见(在指定的不可见超时时间之后)。
• 您在超时之前完成处理并成功删除该消息。

这涉及并发性。对于幂等性，您需要确保可以重复操作而不会产生副作用。例如，您计算某人的每周工资，排队打印作业，并将每周工资存储在表行中。由于某种原因，发生故障，您要么永远不会删除该消息，要么您的代码在有机会删除该消息之前中止。

时间快进，另一个工作实例(甚至可能是同一个实例)重新读取此消息。此时，理论上您应该能够简单地重新执行所需的操作。如果这在您的情况下确实不可能，那么您就没有幂等操作。但是，您可以使用一些机制来帮助您解决此问题:

• 每个队列消息都有一个 DequeueCount。您可以使用它来确定队列消息之前是否已处理过，如果是，则采取适当的操作(例如，检查该员工的表行)。
• 也许您的处理流程中存在无法重复的阶段。在这种情况下:您现在可以修改队列消息内容，而队列消息对其他人仍然不可见并由您处理。因此，想象一下附加类似 |SalaryServiceCalled 的内容强> .然后稍后，附加 |PrintJobQueued 等等。现在，如果您的管道出现故障，您可以在下次阅读消息时找出上次中断的位置。

希望有帮助。有点像在黑暗中拍摄，不知道更多关于你想要实现的目标。

编辑:我想我应该提到我没有看到幂等性和表存储之间的联系。我认为这更多的是一个并发问题，因为无论是使用表存储、SQL Azure 还是任何其他存储容器，都需要处理幂等性。