理解 Windows Azure 缓存

引言

缓存：没有任何 Web 应用程序会不需要它，但实现它的方式有很多种，而且似乎每个人都对什么有效、什么无效有自己的看法。继续阅读以了解 Windows Azure 缓存的概述，并确定如何将其用于您的平台或应用程序。

缓存术语

在深入研究之前，我们先来定义一些术语。缓存选项之间的差异可能归结为细节，但定义上的微小差异可能意味着行为上的巨大差异。

缓存：就本文而言，缓存是数据的临时存储，它是易失的，但访问速度很快。例如，从数据库读取数据表并将其存储在缓存中，可以使应用程序运行得更快，因为读取缓存比读取数据库更快。但不能保证缓存中的数据一定存在。

进程内 vs. 进程外：进程内意味着缓存中存储的数据与应用程序本身在同一内存空间中。进程外意味着存储的数据与应用程序在不同的进程中。该进程可能在同一台服务器上，也可能在完全不同的服务器上。进程内与进程外是缓存项是增加还是减少应用程序进程使用的内存量之间的分界线。

内存缓存 vs. 内存外缓存：在内存缓存中，缓存的数据保存在服务器的运行内存中（无论是进程内还是进程外）。内存缓存始终更快，因为直接从内存检索数据始终是最快的，但内存也是存储数据的最昂贵方式。在内存外缓存中，数据被持久化到某种其他类型的存储中：通常是磁盘存储，形式为文件或存储表。

应用程序缓存 vs. 页面输出缓存：随着 Web 应用程序的运行并向访问者提供网页，缓存通常会被大量使用。有两种缓存应用程序片段的方式：缓存运行应用程序所需的数据（例如一组应用程序设置），以及缓存 Web 页面的输出，其中一部分或整个页面的 HTML 输出将被保存。对于页面缓存，应用程序逻辑通常会从缓存中读取 HTML 并将其发送回浏览器。对于存储在应用程序缓存中的数据，在将数据转换为 HTML 以供浏览器加载之前，需要进行更多的处理。

序列化/反序列化：指将应用程序内存中的数据表示形式转换为适合存储在缓存中的格式。序列化可以由编程语言/平台完成，也可以由开发人员自定义编写。当你写下待办事项清单上的笔记时，你就将你的“待办事项”数据序列化到了笔记本上。当你以后读回它时，你就将这些待办事项数据反序列化回你的记忆中。这与 Web 应用程序的概念相同：有许多不同的序列化格式。

分布式 vs. 单一区域：分布式缓存是指缓存访问可以从运行在不同服务器上的不同进程访问。分布式缓存的替代方案是只有一台服务器上的单个进程才能访问缓存。分布式缓存对于构建可伸缩、灵活的云应用程序非常重要。

其他类型的缓存产品可通过在 IaaS 中的 Windows Azure VM 上安装缓存产品来获得。这些确实存在，但超出了本文的范围。

概述：Azure 缓存模型

Azure 缓存服务

Azure 缓存服务是一种分布式、内存缓存，可以轻松扩展并为在 Azure 中运行的应用程序提供快速的数据访问。缓存服务独立于特定的 Azure 平台实现创建，并且可以被 Azure 内的不同应用程序平台读取和写入。

缓存服务具有可供 Azure 环境内所有不同计算平台使用的优势，因此非常适合数据共享，例如应用程序利用了一系列 Azure 技术。例如，您可能会设计一个应用程序，其中工作器角色处理队列中的项目，而 Azure 网站则读取数据库中的结果以供访问者显示。

在这种情况下，存储在 Azure 缓存服务中的数据将可供 Azure 网站和工作器角色使用。Azure 缓存服务是通过 Azure 管理控制台或通过 Azure API 专门创建的，并且它将独立于应用程序/服务器的重建和重新启动而存在。

Azure 角色内缓存

在 Azure 云服务环境中，有两种类型的应用程序平台——Web 角色和工作器角色。Web 角色通常用于提供网站，而工作器角色用于提供后台处理。角色内缓存是在此环境中提供的缓存，它位于 Web 角色或工作器角色的内存空间中（共存角色缓存），或者通过创建一个专门用于存储缓存项的工作器角色（专用角色缓存）。

角色内缓存会自动分布式，因为缓存项在同一部署中的多个角色之间可用。这意味着当应用程序扩展时，缓存会自动扩展以供新角色使用。

在 Azure 中使用 ASP.NET/IIS 缓存

如果您正在运行 IIS/ASP.NET，您可以访问 ASP.NET 原生的进程内缓存。但是，如果您使用 Cloud Services Web/Worker Roles 或 IaaS VMs 来托管您的应用程序，您必须有两个实例才能获得正常运行时间 SLA。这意味着基于这些平台构建的任何应用程序自然都是分布式应用程序，因此您必须实现某种类型的缓存（或应用程序）同步，以便两个或多个实例彼此通信数据更改。

这是因为 Windows Azure 的原生负载均衡没有服务器亲和性——不能保证访问者后续的每个页面请求都由同一台服务器处理和返回。

内存外自定义缓存

Azure 提供了多种持久化存储类型，可用于缓存。Azure 表存储是一种简单的键/值存储，可以存储海量数据并提供极快的访问速度。此外，还可以使用 Azure SQL Database，但性能和大小限制比表存储更严格，并且在高使用期间的请求过多时，被限制的可能性更大。

最后，还有将缓存文件写入 Windows Azure 存储或 Windows Azure VM 中可用临时位置的选项。使用 Azure 存储具有地理分布式的高级功能，但这仅适用于更改不频繁且缓存新鲜度不是问题的缓存数据。在所有这些情况下，都必须为每个自定义项目手动编码缓存解决方案。

缓存方法	Characteristics	优点	缺点	注释
缓存服务	进程外、内存、分布式	所有类型的 Azure 技术均可访问。可伸缩。	服务额外收费	用于构建高性能、可伸缩的云系统。
Azure 角色内缓存	进程外、内存、分布式	可以运行在现有角色的内存空间中	仅在云服务中适用于 Web/工作器角色。	适用于迁移到 Azure 的现有应用程序。
ASP.NET/IIS 缓存	进程内、内存、单一区域	运行在现有应用程序的内存空间中。	需要缓存同步才能与可伸缩的 Azure 应用程序一起使用。	与 Azure 负载均衡一起使用时，需要进行调整才能使用分布式缓存。
Azure SQL 数据库	进程外、内存外、分布式	数据持久存储在数据库表中。	需要自定义代码来序列化数据以及管理（如过期）。	比内存应用程序慢，可能在请求高峰期被限制。
Azure 表存储	进程外、内存外、分布式	数据持久存储在 Azure 表存储中。	对大型数据集具有高吞吐量，经济高效。需要自定义代码。	比 SQL 慢，但比内存快。可能在请求高峰期被限制。
Azure Blob 存储	进程外、内存外、分布式	数据持久存储在 Azure Blob 存储中。	可利用地理冗余持久存储。需要自定义代码。	比内存慢，但易于实现高度分布式。

不同 Azure 缓存模型的实际实现

在 DNN，我们的云服务环境运行在 Windows Azure 上，并利用多种不同类型的缓存来提供一系列产品和内部服务。

Azure 缓存服务

我们将其作为提供 Evoq 试用版过程的一部分。Evoq Social 和 Evoq Content 是 DNN 提供的两款商业解决方案，均提供免费试用。免费试用版是使用 Windows Azure Pack 构建的，并与云服务环境中的工作器角色进行接口以进行预配。

预配服务收集注册页面上的客户详细信息（姓名、电子邮件、产品类型），然后分配一个预先配置好的 Windows Azure 网站，其中已安装并准备好 Evoq Social 或 Evoq Content。Azure 缓存服务被利用来在不同的 Azure 环境之间提供高性能的预配。这使我们能够在 30 秒内为客户交付一个新的、个性化的试用版。

您可以亲自尝试此过程，注册 Evoq Social 试用版或 Evoq Content 试用版——您将一起运行各种 Azure 技术，在 30 秒或更短时间内从“开始”到新网站。

Azure 角色内缓存

Evoq in the Cloud 产品运行在 Azure 云服务平台之上，并提供高性能的内容和/或社交网站，具有专用 Web 角色。这些是可伸缩、高可用、可定制的网站，基于 DNN Platform 构建。

DNN Platform 配备了标准的缓存提供程序，该提供程序利用基于文件的存储，但它不是分布式的。对于 Windows Azure 实现，通过构建一个集成到 DNN 模块化体系结构中的缓存提供程序，已利用了角色内缓存。这为运行 DNN 的可伸缩 Web 角色之间提供了高性能、进程外、分布式缓存。

IIS/ASP.NET 缓存 

前面提到的 Evoq 试用版使用 Azure 网站技术运行。这意味着它们使用单实例部署模型——试用版预计会很快，但不需要可伸缩。因此，它们可以使用 DNN Platform 标准提供的标准进程内缓存提供程序。进程内缓存适用于这种类型的 Windows Azure 网站，因为没有涉及伸缩。在可伸缩版本的 Windows Azure 网站上部署 DNN 需要使用缓存服务或其他自定义解决方案。

摘要

本文介绍了 Windows Azure 平台上的不同应用程序缓存类型。在云平台（如 Windows Azure）上构建应用程序时，充分利用底层技术的伸缩性和灵活性非常重要。从云中获得最佳结果涉及构建分布式、可伸缩的应用程序。构建这些类型的应用程序总是需要一个仔细的缓存策略。本文中的信息将有助于在规划或审查基于 Windows Azure 的应用程序时做出决策。