Windows Azure革新——Caching（预览）
无论是在云计算平台或在非云端环境中构建一个高性能和高扩展性的系统时Caching都是一个热门的话题。2011年3月份推出了Windows Azure AppFabric Caching。它在云上提供了一个in-memory和分布式的caching服务。在2012年6月的更新版本中，cache团队宣布了WindowsAzure上一个新的caching解决方案，被称作Windows Azure Caching（预览）。并且原先的Windows Azure AppFabric Caching被重新命名为Windows Azure Shared Caching。
什么是Caching（预览）
如果你一直在使用Shared Caching你应该知道它由很多cache服务器构成。在使用之前你首先需要从开发者门户创建一个cache帐户并且指定你想要使用的大小，即用来存储需要缓存的数据能够使用的内存量。然后你可以通过cache URL通过代码添加、获取和移除这些数据。
Shared Caching是一个多租户系统，在所有的用户中托管了所有缓存的元素。因此你不知道你的数据存储在哪个服务器里。
这一caching模式可以很好地工作并且能够能够处理大部分的情况。但是它有一些问题。第一个问题是性能问题。因为Shared Caching是一个多租户系统，意味着所有的cache操作需要经过Shared Caching网关然后路由到存储你所需要数据的服务器。即使在Shared Caching系统中有一些caches，但从云服务到cache服务还是需要一定时间的。
第二个问题是，对开发人员来说Shared Caching服务是作为一个黑盒来工作的。我们只知道cache端点。这对有些人足够了，因为他们不关心任何相关的东西。但是如果你想在Shared Caching里获取更多信息和更多的控制，那是不可能的。
最后一个问题是价格和成本效益问题。你需要根据每个月你所请求的cache来付费。但当我们托管一个web role或worker role时，很少用掉虚拟机（服务实例）里的所有内存和CPU。如果使用Shared Caching我们需要为cache服务付费但同时浪费了一些本地的内存和CPU。
由于上述问题，微软为我们提供了一个新的caching模式，即Caching (预览)。Caching (预览)将我们的云计算服务（web role和worker role）的内存和CPU作为cache簇充分利用,而不再是拥有分开的cache服务。因为Caching (预览)是在虚拟机上运行，托管我们的云计算应用程序或在其附近。不需要任何网关和路由，因为它位于同一数据中心和同一机架，比Shared
Caching提供了更高的性能。
Caching (预览)与我们的应用程序并排工作，初始化并作为一个Windows Service运行在虚拟机里，由我们的role里的启动任务调用，我们能够获取更多的信息并控制它们。
因为Caching (预览)利用我们现有云计算服务的内存和CPU，所以它是免费的。我们只需要为计算付费。每个机器上的资源可以被更加有效的利用。
启用Caching(预览)
在云计算服务里启用Caching(预览)是非常简单的。让我们先从Visual Studio创建一个新的windows azure cloud project然后添加一个ASP.NET Web Role。然后打开role setting界面并选择Caching page。在这里我们可以在一个role上启用和配置Caching(预览)。
为了启用Caching(预览)，打开“Enable Caching (Preview Release)”复选框。然后我们需要指定想要使用的caching 簇模式。
有两种类型的caching模式，co-located 和dedicate。co-located模式意味着我们使用运行云计算服务（web role 或worker role）实例的内存。通过使用这一模式我们必须要指定多少比例的内存将被作为cache。默认值是30%。所以确保它不会影响role业务执行。
Dedicate模式将把虚拟机里的所有内存用作cache。实际上它将为操作系统、azure托管等等储存一些。但是它将试图使用尽可能多的内存用作cache。
正如你所看到的，Caching(预览)是基于role定义的，意味着这个role的所有实例将应用同一设置并作为整个缓冲池（cache pool），你可以通过指定role的名字来使用它，稍后我将做一个演示。在一个windows azure project里我们可以拥有不止一个role启用Caching (预览)。然后我们将拥有更多的cache。例如，拥有一个web role 和worker role的情况。web role指定30%的co-located caching，worker role指定dedicated caching.。如果web role 有三个实例、worker role有两个实例，我将拥有两个cache。
如上图所示，cache 1由三个web role角色构成，cache 2由2个worker role实例构成。然后我们可以向cache 1中添加元素，从web role代码和worker role代码中获取它。但是存储在cache 1中的元素不能从cache 2中获取到，因为它们是独立的。
在Visual Studio里我们指定30% 的co-located cache并使用本地存储模拟器储存cache簇运行时状态。然后在底部我们可以指定命名的cache。本例中我们使用默认的一个。
现在我们在web role设置里启用了Caching (预览)。接下来，让我们看看如何使用cache。
使用Caching(预览)
Caching (预览)只能被同一云计算服务的role所使用。如前面所提到的，如果它们都在同一个云计算服务中，能够从一个worker role里连接web role的一个cache。但是你不能从其它云计算服务使用一个Caching(预览)。这就是与Shared Caching的不同之处。如果它拥有连接URL和认证令牌Shared Caching对所有的服务都是开放的。
为了使用Caching(预览)我们需要向项目中添加一些引用并且在Web.config中添加一些配置。NuGet让一切变得简单起来。右击我们的web role项目并选择“Manage NuGet packages”，然后搜索名为“WindowsAzure.Caching”的包。在包列表中选择安装“Windows Azure Caching Preview”。
它将从NuGet库中下载所有必要的引用同时更新我们的Web.config。打开web role中的Web.config并且找到“dataCacheClients”节点。在这个节点下我们可以指定我们将使用的cache客户端。每个cache客户端将使用role名称标识并找到cache。因为之前我们只启用了该web role的Caching (预览)所以我将当前的role名复制到配置中了。
然后，在默认页面我将添加一些代码来演示怎样使用cache。我放了一个textbox到这个页面中，供用户用来输入他/她的姓名，然后点击一个按钮来为他/她生成email地址。在后台代码中，我将核实该姓名是否被加到cache中。如果加进去了将立即返回email。否则，将设置tread睡眠2秒来模拟延迟，然后将它添加到cache中并返回到页面。
protected void btnGenerate_Click(object sender, EventArgs e)
{
// check if name is specified
var name = txtName.Text;
if (string.IsNullOrWhiteSpace(name))
{
lblResult.Text = "Error. Please specify name.";
return;
}
bool cached;
var sw = new Stopwatch();
sw.Start();
// create the cache factory and cache
var factory = new DataCacheFactory();
var cache = factory.GetDefaultCache();
// check if the name specified is in cache
var email = cache.Get(name) as string;
if (email != null)
{
cached = true;
sw.Stop();
}
else
{
cached = false;
// simulate the letancy
Thread.Sleep(2000);
email = string.Format("{0}@igt.com", name);
// add to cache
cache.Add(name, email);
}
sw.Stop();
lblResult.Text = string.Format(
"Cached = {0}. Duration: {1}s. {2} => {3}",
cached, sw.Elapsed.TotalSeconds.ToString("0.00"), name, email);
}
}
Caching (预览)可以被使用在当地模拟器上，所以我们按F5就行了。当我们第一次输入名字时它将使用大概2秒钟时间来返回email，因为它那时候还不在cache里。
但当我们再次输入同一个名字时，它将从cache中立即返回。
因为Caching
(预览)分布在role的所有实例上，所以我们可以通过扩大我们的web role来扩大它。只需要使用2个实例并调整一些代码来在页面上显示当前实例ID，再试一次。然后我们发现即使它被添加到另一个实例中我们也可以获取这一内存。
跨Role使用Caching(预览)
正如上面所提到的，Caching(预览)能够被同一云计算服务里的所有其它role所使用。例如，让我们在cloud solution里再添加一个web role然后在其默认页面添加同一代码。在Web.config里我们添加cache客户端到最后添加的启用了Caching(预览)的role当中，通过在这里指定它的role名称。
当我们在本地开始该解决方案时我们在web role 1里指定名称并让它为我们生成email。因为该名字没有对应的cache所以将花费2秒钟时间并将email添加到cache中。
在web role 2里我们也指定相同的名字。然后你将发现它可以获取到web role 1保存的email并迅速返回。
最后我们可以将我们的应用程序上传到Windows Azure并再次测试。确保你已经更改了cache簇状态storage account到真实的azure account。
更多非常好的特性
作为一个in-memory分布式caching解决方案，Caching(预览)有一些极好的特性。第一个是支持高可用性。这是我第一次听说一个分布式的cache支持高可用性。在分布式cache世界里如果一个cache簇出现故障，它所存储的数据将被丢失。这一行为由Memcached引进并且被几乎所有的分布式cache产品所引用。但是Caching(预览)提供高可用性，这意味着你可以指定命名的cache是否自动备份。如果yes这一命名的cache的数据将在该role的其他role实例中被复制。如果一个实例故障，可以从它的备份实例中获取数据。
为了启用备份，在Visual Studio中打开Caching page。在命名的cache中启用备份，将Backup Copies的值从0改成1。
Backup Copies只能是0或1。“0”意味着没有备份也没有高可用性，“1”意味着启用高可用性备份数据到另一个实例中。
但是使用高可用性特征有一些东西需要确认。第一，高可用性并不意味着cache里的数据遇到任何故障都永不丢失。例如，如果一个启用了cache的role有10个实例，9个出现故障，大部分缓存的数据将会丢失，因为主实例和备份实例都出现了故障。但是一般说来这种情况不会发生，因为MS担保为了备份cache它将在不同的故障域里使用实例。
另一个是，启用备份意味着你为同一数据储存了两份。例如如果100MB内存够了，但如果想启用备份，至少需要200MB内存。
除了高可用性，Caching(预览)比Windows Azure Shared Caching支持Windows Server AppFabric Caching引进的更多特性。它支持带有通知的本地cache。它还支持绝对值过期以及slide窗口过期类型。
并且Caching(预览)还支持Memcached协议。这意味着如果你有一个基于Memcached的应用程序，你可以不用改变任何代码即可使用Caching(预览)。你需要做的是改变怎样连接到cache的配置。
与Windows Azure Shared Caching类似，MS也在Caching (预览)之上提供现成的ASP.NET session provider和output cache provider。
总结
当我们构建一个基于云的应用程序时caching是一个非常重要的组件。在2012年6月的更新版本中，MS提供给我们一个新的cache解决方案叫做Caching (预览)。与现有的Windows Azure Shared
Caching不同，Caching(Preview)在我们部署到云的role实例内部运行cache簇。它提供了更多的控制、更好的性能和更好的成本效益。
在Windows Azure上现在有两个caching解决方案，Shared Caching 和Caching (预览)。如果你需要一个能够被很多云服务和网站使用的中央cache服务，你需要使用Shared Caching。但是如果你想要一个快速、就近分布的cache, Caching (预览)是更好的选择。
希望有所帮助，
Shaun