AuthenticationFailed Azure 表存储

Question

我们在访问数据时从表存储中得到一个随机错误：

System.Data.Services.Client.DataServiceClientException: <?xml version="1.0" encoding="utf-8" standalone="yes"?>
<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
 <code>AuthenticationFailed</code>
 <message xml:lang="en-US">Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.
RequestId:67cd9503-7a10-48a9-8c97-fee3906ac8cb
Time:2012-06-19T08:20:42.0670051Z</message>
</error>
  at System.Data.Services.Client.QueryResult.Execute()
  at System.Data.Services.Client.DataServiceRequest.Execute[TElement](DataServiceContext context, QueryComponents queryComponents)

以下是有关错误和我们的 Web 应用程序的一些事实：

• 我们有 5 个中型网络服务器托管我们的网站
• 在任何给定时间，我们的网站上都有 200-500 名访客。他们是 不断地点击。
• 每次点击都会从表格存储中加载数据，也可以保存。
• 错误一天只会发生 20-50 次。

让我感到困惑的是，与大量页面加载和 AJAX 回调相比，此错误很少发生。

这个错误的原因是什么？我们已经了解到，如果服务器时间关闭，可能会出现时间戳问题，但为什么我们的实时服务器上的时间会出错，为什么错误不会经常发生？

Answer 1

好的，我终于找到了导致我的问题的原因。我的 DataSource 类中的静态和非静态内部变量组合不好：

private static CloudStorageAccount storageAccount;
private CharacterContext _context;

由于 storageAccount 变量是静态的，因此在实例化 DataSource 对象时并发请求将竞争将其更改为不同的存储帐户：

public CharacterDataSource()
{
      storageAccount = CloudStorageAccount.FromConfigurationSetting(ServiceConfigurationHelper.GetTableStorageConnectionStringConfigKey(GameInstanceName));
      _context = new CharacterContext(storageAccount.TableEndpoint.AbsoluteUri, storageAccount.Credentials);
}

由于这个小问题，_context 对象的实例化实际上可能在访问 storageAccount.TableEndpoint.AbsoluteUri 时使用一个存储帐户，而在访问 storageAccount.Credentials 时使用另一个存储帐户。这导致了 AuthenticationFailed 错误。

storageAccount 变量绝对没有理由是静态的，因此解决方案是简单地删除此修饰符，从那时起我们就再也没有错误了。

我从 Microsoft 得到的提示是我们使用了错误的存储帐户凭据，我们无法在我们获得的堆栈跟踪中看到这一点。不知道微软的人在哪里找到了这些信息，但我很高兴我联系了他们。

Answer 2

服务器时间关闭是此类问题的常见原因，但由于您的应用程序在 Azure 中运行并且不会发生太多，因此我将排除此问题。

就像您在问题中所说的那样，您的网站在任何给定时间都有 200 到 500 名用户。这意味着您将拥有数千个正常工作的事务，并且只有极少数的错误。我有 2 条建议：

1. Call Microsoft 并向他们提供您的 RequestId 和时间，以便他们调查真正的原因。
2. 实施重试策略。您可能知道，Table Storage 已经附带了retry policy。但在您的情况下，这还不够，因为此重试策略 doesn't retry 对 403（和所有其他 400）错误代码。这就是为什么你可以考虑建立一个custom retry policy。人们可能不同意，但我认为这类问题是暂时性故障，因为它可能随机发生在您所有交易的