C# 使用Azure SQL作为配置存储的AppFabric缓存

AppFabric缓存服务能否使用Azure SQL数据库作为缓存群集配置的存储

正如这里所说的，它肯定支持SQL Server，但对Azure SQL的支持只字不提。Azure SQL it是HA技术，所以看起来像是“有机地”存储配置的方式，该配置应该是高可用的，以保持缓存群集正常运行

更新。AppFabric配置UI不提供使用SQL凭据进行访问的可能性-此处仅提供“集成安全性”选项，Azure SQL服务不提供该选项，但可以通过DistributedCacheService.exe.config手动编辑连接字符串

<?xml version="1.0" encoding="utf-8"?>
<configuration>
...
  <dataCacheConfig cacheHostName="AppFabricCachingService">
    ...
    <clusterConfig provider="System.Data.SqlClient" connectionString="Server=tcp:azuredbnamehere.database.windows.net,1433;Database=AppFabricConfigHolderTest;User ID=user@azuredbnamehere;Password=password;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;" />
  </dataCacheConfig>
...
</configuration>

我们到了

PS>获取帮助设置CacheConnectionString

名字 设置CacheConnectionString

概要 保留连接字符串以供临时使用。然后可以使用Get-CacheConnectionString检索该字符串。 请注意，此命令不会更改缓存群集配置存储使用的连接字符串

<?xml version="1.0" encoding="utf-8"?>
<configuration>
...
  <dataCacheConfig cacheHostName="AppFabricCachingService">
    ...
    <clusterConfig provider="System.Data.SqlClient" connectionString="Server=tcp:azuredbnamehere.database.windows.net,1433;Database=AppFabricConfigHolderTest;User ID=user@azuredbnamehere;Password=password;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;" />
  </dataCacheConfig>
...
</configuration>

事实证明，集群配置存储信息实际上是重复的。在存储它的地方，我实现了执行

设置缓存连接字符串

的alter反编译PowerShell模块

using (RegistryKey registryKey = Registry.CurrentUser.CreateSubKey("SOFTWARE\\Microsoft\\AppFabric\\V1.0\\Temp"))

更新4。AppFabric缓存管理PowerShell管理单元使用的最有趣的东西是不同的注册表路径（反编译显示）：

HKLM\SOFTWARE\Microsoft\AppFabric\V1.0\Configuration

。在修改了ConnectionString属性值之后，我终于得到了

useCacheCluster

命令

群集也启动了，现在看起来可以运行了。

我们可以使用更新中描述的方法“作弊”并设置AppFabric缓存群集，但遗憾的是，事实证明，确保我们使用集成安全性的代码被缝合到了PowerShell管理管理单元中：

// Microsoft.ApplicationServer.Caching.Configuration.ConfigurationBase
...
if (provider.Equals("System.Data.SqlClient"))
{
    ConfigurationBase.ValidateSqlConnectionString(connectionString);
}
...
internal static void ValidateSqlConnectionString(string connectionString)
{
    SqlConnectionStringBuilder sqlConnectionStringBuilder = new SqlConnectionStringBuilder(connectionString);
    if (!sqlConnectionStringBuilder.IntegratedSecurity || !string.IsNullOrEmpty(sqlConnectionStringBuilder.UserID) || !string.IsNullOrEmpty(sqlConnectionStringBuilder.Password))
    {
        int errorCode = 17032;
        string sqlAuthenticationNotSupported = Resources.SqlAuthenticationNotSupported;
        throw new DataCacheException("DistributedCache.ConfigurationCommands", errorCode, sqlAuthenticationNotSupported);
    }
}

如果您尝试注册CacheHost（添加主机和其他一些命令），您将面临以下错误：

Register-CacheHost : ErrorCode:SubStatus:Only Windows authentication is supportedwith SQL Server provider. Specify a valid connection string for Windows authentication without any User ID or Password. At line:1 char:1 + Register-CacheHost -Provider "System.Data.SqlClient" -ConnectionString "Server=t ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Register-CacheHost], DataCacheException + FullyQualifiedErrorId : SqlAuthenticationNotSupported,Microsoft.ApplicationServer.Caching.Configuration.Commands.RegisterCacheHostCommand 注册缓存主机：错误代码：子状态：SQL Server提供程序仅支持Windows身份验证。为Windows身份验证指定一个有效的连接字符串，无需任何用户ID或密码。 第1行字符：1 +注册CacheHost-Provider“System.Data.SqlClient”-ConnectionString“Server=t…”。。。 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +CategoryInfo:NotSpecified:（：）[Register CacheHost]，DataCacheException +FullyQualifiedErrorId:SqlAuthenticationNotSupported，Microsoft.ApplicationServer.Caching.Configuration.Commands.RegisterCacheHostCommand 因此，使用Azure SQL作为缓存群集配置持有者的唯一现实选项是从头开始编写自定义配置提供程序：或者尝试使用不同名称下实现的SqlServer提供程序（Microsoft.ApplicationServer.Caching.SqlServerCustomProvider）来愚弄PowerShell模块（未测试）

---

更新。我已经用愚弄AppFabric和使用不同名称的内置SQL Server提供程序测试了这种方法。它像一个符咒一样工作。

确认：a）这是否意味着您更改了缓存服务帐户？B）这样做，访问缓存的代码是否存在任何访问问题？非常抱歉，我错过了这暗示了“自定义配置提供程序”的用法“内置SQL Server提供程序支持。从集群管理的角度来看，我们对这种设置没有任何问题。Eugene，你能发布一个后续信息吗？您是否使用此安装程序投入生产？@LarrySilverman，我可以肯定地确认，使用不同名称的内置SQL Server提供程序（作为“自定义提供程序”）的安装程序能够使用SQL Server身份验证为我们工作了大约6个月，我们没有遇到任何问题。它增加了注册“自定义提供程序”到缓存主机的附加步骤，但在这之后，所有工作都正常进行。尽管我们在AppFabric方面有着积极的经验，但我们最终还是迁移到了Azure Redis，从此不再回头。Redis是一种更易于维护的现代/充分的解决方案，AppFabric现已退役。