天蓝色幂等运算的模式？

Question

任何人都知道模式设计幂等操作到天蓝色操作，特别是表存储？更常见的方法是生成id操作并将其缓存以验证新的执行，但是，如果我有十几个工作人员处理操作，这种方法将更复杂。 ： - ））

感谢的

Answer 1

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

现在：在处理该消息时可能会发生一些事情：

• 您在超时期限后完成处理。当你去删除邮件时，你会得到一个例外。
• 您意识到自己已经没时间了，所以您增加了队列消息超时（今天，您必须调用REST API来执行此操作;有一天它将包含在SDK中）。
• 出现问题，在您删除邮件之前在代码中导致异常。最终，消息再次在队列中可见（在指定的不可见性超时期限之后）。
• 您在超时前完成处理并成功删除该消息。

这涉及并发性。对于幂等性，由您决定是否可以重复没有副作用的操作。例如，您计算某人的每周工资，排队打印作业，并将每周工资存储在表格行中。出于某种原因，发生故障并且您在删除消息之前不会删除消息或代码中止。

及时快进，另一个工作者实例（或者甚至可能是同一个实例）重新读取此消息。此时，理论上您应该能够简单地重新执行所需的操作。如果在您的情况下实际上不可能，则您没有幂等操作。但是，您可以使用一些机制来帮助您解决此问题：

• 每个队列消息都有一个DequeueCount。您可以使用它来确定之前是否已处理队列消息，如果是，则采取适当的操作（例如，检查该员工的表行）。
• 也许您的处理管道的某些阶段无法重复。在这种情况下：您现在可以修改队列消息内容，而队列消息对其他人仍然是不可见的并且由您处理。因此，想象附加类似 | SalaryServiceCalled 。稍后，附加 | PrintJobQueued 等等。现在，如果你的管道出现故障，你可以在下次阅读你的消息时找出你离开的地方。

希望有所帮助。有点在这里黑暗中射击，不知道你想要达到的目标。

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

Answer 2

我相信你可以使用回复日志存储方式来解决这个问题