预测:多云

Windows Azure 任务内缓存

Joseph Fultz

 

Joseph Fultz运气眷顾有准备的旧概念是为了传达的理念不管你是多么幸运,你需要做好准备,以便利用幸运的发生。我常常想到此语句描述相当准确地缓存。如果你足够幸运,宇宙要对齐驱动器高使用您的站点和服务的方式,您将更好地准备快速服务内容。

早在一月我介绍了一些概念与相关的缓存,而是战术上侧重于一些编码方法 (msdn.microsoft.com/magazine/hh708748)。加上 Windows Azure 缓存 (预览),我要到这里只是缓存预览作为参考,在缓存中的专用和合用同一地点作用的感觉是有益的考虑如何使用这些角色作为整体解决方案体系结构的一部分。这不会覆盖所有的缓存功能 ; 相反,它已打算将设计器的视图与大块做什么。

由任何其他名称缓存......

...是不一样。肯定的是,是差不多的后端执行,并像其前身 Windows Azure 共享缓存缓存预览将移动到本地缓存客户端读取的数据。更重要的是,缓存预览介绍从共享缓存,所以切换到基于角色的不缓存丢失某些功能只扩展了可用的功能集,它还使您的部署体系结构更好地控制。若要开始,让我们澄清的专用和合用同一地点的角色之间的主要区别:配置。

当配置缓存节点,您有整个角色献给缓存或预留的作用只是一个百分比的选项。只是作为一种快速考虑为设在同一地点高速缓存保留 RAM 的影响,看看图 1,其中显示了后缓存中保留的剩余可用 RAM。(请注意合用同一地点的选项不是 X 小实例中可用)。

图 1 剩余的 RAM

虚拟机大小 总 RAM 10%/ 90%保留/可用 20%/ 80%保留/可用 40%/ 60%保留/可用
X-小 768MB N/A
小型 1.75GB 50 英里/80 公里 50 英里/80 公里 50 英里/80 公里
中等 3.5GB 50 英里/80 公里 50 英里/80 公里 50 英里/80 公里
7GB 50 英里/80 公里 50 英里/80 公里 50 英里/80 公里
X 大 14GB 50 英里/80 公里 50 英里/80 公里 50 英里/80 公里

往往首先想到就是选择一些中型或小型的大小并分配一些的内存量。只要分配量足以为其用途和可用 RAM 的边界内,这是内存的很好的方法。但是,如果对象的数目很高,且合理的期望每台计算机上的缓存客户端可能会举行其最大对象数,结果可能会意外的内存压力。此外,太小的高速缓存内存可能导致不需要的缓存迁离,减少缓存的总体效率。

图 2 显示内存使用基于虚拟机 (VM) 大小的百分比。图表基于在一个 msdn.microsoft.com/­库/hh914152,其中显示的用于缓存在专用模式下可用的 RAM 量。

图 2 高速缓存使用的专用角色

虚拟机大小 可用内存缓存 基于虚拟机大小的 RAM 用 %
小型 大约 1 GB 57%
中等 大约 2.5GB 57%
大约 5.5GB 79%
X 大 大约 11GB 79%

我设在同一地点的网格中 (图 1),因为我假定应用程序将需 RAM 的多数,并没有超越 40%分配的同一位置的类型。在比较中,专用的版本通常提供了更多的 RAM,但似乎撞在 VM 很大的内存分配的最大效率。在这个意义上,两个中型虚拟机是一个大型的那么有用。当然,一个大型的实例不能帮助选项,例如高可用性 (HA) 复制您的数据,您可能希望您缓存的基础结构中。尽管如此,它值得称重需要的空间,对需要冗余并选择一种配置,不仅符合技术的需要,而且还优化了成本。

当缓存有意这样做,RAM 干旱通常不是一个问题。然而,在备份会话对象和/或输出缓存,则使用共享的缓存的情况下,情况是有点更具挑战性因为一切和难以预测准确负载使用会话的趋势。例如,如果您在运行已深模型的模型-视图-控制器应用程序要将放置在会话中和缓存客户端增加对象的最大数目,您可能会遇到意想不到的结果,在中等或更大的负载下。这将作为从你不敢期望 ; 内存压力造成的从共享缓存逐出的站点性能变慢的表面 别忘了,缓存客户端可能持有更多的 RAM,比预期增加的最大对象计数和深图形的结合。框架可帮助您有点通过压缩的序列化的对象,但作为 RAM 珍贵和有限的资源,会计勤奋是最佳做法,特别是当试图共享应用程序、 输出缓存、 会话对象、 数据缓存和缓存客户端之间的 RAM。为了帮助您设置您的缓存的大小,Microsoft 已经发布了容量规划指南电子表格,您可以在找到 msdn.microsoft.com/library/hh914129

地区

区域添加一些不错的功能,但成本。成本是该区域固定到单个服务器强制该区域中的对象的所有请求,以通过该缓存主机瓶颈,当它不存储在缓存客户端中。好处是使用区域提供了标记的能力。我最喜欢使用的地区将举行 pre-fetched 的参考数据。这可能因为瓶颈的问题,似乎在第一、 愚蠢,但是让我们看看。

考虑缓存使用,让我们假定有与每种产品,最多八个变种的 10,000 产品目录意味着潜在 80,000 项目的目录中。如果每个对象,该对象表示项目平均 1 K,即约 82 MB,可以对每个请求,周围无序播放,以及占用空间中缓存客户端。此外,会有一定数量的虚拟目录的完整副本或子集,原来,因此可能与爆炸的参考数据,以将拖着脚步,到头来都有利的单个区域主机 (见图 3)。

Cache Layout with a Single Region
图 3 缓存布局与单个区域

然而,与一些工作我可以创建多个地区举行的数据的小节。例如,我可能会到部门或段中断我的目录。消费产品,另一个用于专业的产品,从而导致的东西像什么所示,例如,创建一个区域图 4

Cache Layout with Two Regions
图 4 缓存布局与两个区域

这将提供多一点粒度在缓存中的,启用使用较小的角色,以容纳所有我缓存对象的缓缓存更新,并减少交通通过减少向每个角色的查询和筛选通过标记查询使用。

内容标记的能力是驾驶的地区使用的主要功能。因此,我可以在我的目录 ; 标记内容 对于计算机,例如,我可能有标记如:"笔记本电脑、""4 GB,""8 GB"、"15 英寸,""高清音频"、"桌面"等等。以这种方式可以通过使用 GetObjectsByTag 方法之一调用启用这种导航的多面产品搜索的 UI 元素。它还意味着再造数据访问层,并在某些方面,治疗更多作为主要数据源的查询 (标签) 方面的数据都得到满足的缓存。

一种有趣的方式来利用此功能是作为后端数据存储中,使用 Windows Azure 存储表,而是预取数据、 标签,并将其放入缓存。这提供了一些过滤缺少从存储表的当前化身,同时保持在最低限度的费用。

使用区域提供了很大的灵活性中检索缓存的数据,但请注意它放在部署基础结构的应变的特定类型。仍然,区域是方便作为预取和访问引用数据的手段。

高可用性

还有一个有意思的东西,考虑与房委会缓存 — — 使用医管局缓存,小心点,但您需要使用医管局时要小心。至少,您需要将适当地深刻地知道什么真的需要高度可用。

为重复启用的每个角色双打的实际对象所需的空间量,因为您运行要快得多的 RAM 不足。因此,作为设计的问题,最好只对这些功能,实际上需要它或这会极大改善,不能任意推高成本或人工触发由于内存饥饿造成的过度消费的重复缓存缓存驱逐 UX 使用医管局。

我见过一些建议把会话对象到房委会缓存以便您可以查询跨用户在基于某些标记值的活动会话的指导。在大多数情况下,这不会有用的方法,公平分配负载时从缓存中 ; 检索会话对象 该负载模式应更严格地遵守网站的负载平衡。此外,因为你可能也有很多空匿名配置文件除了根据确定的注册用户,为用户配置文件等实体基于标记的搜索是实际上更限制比很有帮助。

我建议把会话,输出缓存和到他们自己命名的缓存,类似的用户对象,但不使它们重叠。在案件中,编辑数据绑定到一个会话,您可以考虑备份与房委会缓存,取决于你在哪里应用程序的生命周期中的会话。如果 app 仍正在设计和创建,它是更好地分离这些原位状态对象并将它们放置在医管局以外会话缓存中。这允许您管理有关的超出范围的会话的用户的编辑数据,并以更均匀地在更保持会话蔓延缓存。但是,如果您的应用程序是进一步沿,并且您不想失去法律、 金融或会话对象与捆绑的只是轻松的使用原因的数据,是可以接受的只是对房委会缓存线会话 — — 只是一定要特别强调的是,在负载测试中,知道实施的限制。是由于其内容或其点过程中的重要的数据以外­— — 如备份编辑的数据接口 — — 类型的数据,是医管局的直接目标是大参考集、 pre-fetched 的数据和预先计算的数据。

所有这些之间的共性就是成本再次预取数据。在 pre-fetched 或预先计算的参考数据,启动总理缓存的成本会相当大,会在运行时期间丢失的数据可能对网站执行产生严重和灾难性的后果的影响。图 5描述了如何可能会与医管局已打开分配缓存对象。因为重复项必须在不同的故障的域中,您可以看到如何重复项减少可用于缓存的总体 RAM。这并不是说它总是坏,而是它是说它是必要的。我只建议医管局的潜在影响的意识。

High Availability and Fault Domains
图 5 的高可用性和故障域

乐高房子

开发人员经常想发展作为建筑用乐高积木块 ; 您创建的基本块和扣合在一起成为一个有用的应用程序。这一想法保持为 true,即使在我们从对函数的应用程序堆栈对象的进一步上移到基础结构组件。为此,我想给你们留下了一些设计指导。

首先,使用所有的工具为您的优势。别定居只有医管局或上没有医管局,因为一种方式更容易。不要使用仅基于区域的缓存,因为您可以搜索他们 ; 或放弃他们,因为他们得到固定到实例。相反,构造您缓存的基础架构,以满足您的需要。

图 6 显示专用的角色使用房子我重复的缓存和对更丰富可检索缓存使用的区域。作为一般规则,我赞成专用的缓存角色的房屋的地区,因为我不想要加载下正在服与所有高速缓存读取给定区域有关的通信用户流量的作用。在底部行图 6 描述了使用缓存的同一地点的风格举行会议、 输出和其他可能缓存,在我的应用程序的执行过程的各种数据。这并不是说我就只能坚持专用或合用同一地点的角色描述,因为这主要取决于 RAM 要求我打算到角色中的缓存中的项目。事实上,对于许多实现,底部的行仅将做诀窍无需医管局、 地区或大量的 RAM 提供的专用角色。

Cache Deployment Possibilities
图 6 缓存部署可能性

最后, 图 7 是标识我开始一个网格点为不同类型的数据时我正在考虑如何构建我国缓存中部署。

图 7 配置首选项

数据的类型 使用医管局 使用区域 专用 设在同一地点
会话       X
Output       X
通用数据     X X
预读 X   X  
Pre calc X   X  
重要数据 X      
可过滤   X X  

这绝不意味着要听写用法或建议的作用或仅对于已经确定了的插槽功能很有用。它是只是我的起点。如果我有一大组希望能够通过标签搜索的 pre-fetched 数据,我将结合已标记,结束与专用的缓存角色使用区域和医管局的项目。为例,当我可能偏离我的出发点,如果我有一个已部署的应用程序,使用会话缓存它的模型,而用户编辑数据时,我很可能会折腾我放在同一位置的缓存中的会话和不只把它放在一个专用的角色,但也使房委会的倾向。

所以,如果你足够幸运,有一个繁忙的站点,请确保你的运气将继续通过正确编写您缓存的基础结构。

Joseph Fultz 是 Hewlett-Packard Co. 的软件架构师,参与 HP.com 全球 IT 小组的工作。以前他是微软,处理其顶级企业和 ISV 客户定义的体系结构和设计解决方案的软件架构师。

衷心感谢以下技术专家对本文的审阅:罗希特夏尔马和 Hanz 张