Windows Server AppFabric Caching

这套 AppFabric Caching 比我用过的 memcached 复杂多了，MSDN有一篇文章进行介绍Introduction to Caching with Windows Server AppFabric (Beta 1)，这里头的概念很多，到现在为止还是模模糊糊的，本文主要是一些概念的理解，可能有不对的地方，欢迎大家指出来。

Windows Server AppFabric Caching 的体系结构

从上图可看出 AppFabric Caching的大致架构，他给Clients提供一个统一的缓存界面(Unified Cache View)， Client 可以不用在意到底实际的缓存层(Cache Layer)有多复杂，通过统一的的 API 接口就可以使用 AppFabric Caching 进行 3H( High Scalability, High Availability, High Performance ) 应用系统的开发。

//Define Array for 1 Cache Host
List<DataCacheServerEndpoint> servers = new List<DataCacheServerEndpoint>(1);

//Specify Cache Host Details
//  Parameter 1 = host name
//  Parameter 2 = cache port number
servers.Add(new DataCacheServerEndpoint("localhost", 22233));

//Create cache configuration
DataCacheFactoryConfiguration configuration = new DataCacheFactoryConfiguration();

//Set the cache host(s)
configuration.Servers = servers;

//Set default properties for local cache (local cache disabled)
configuration.LocalCacheProperties = new DataCacheLocalCacheProperties();

//Disable exception messages since this sample works on a cache aside
DataCacheClientLogManager.ChangeLogLevel(System.Diagnostics.TraceLevel.Off);

//Pass configuration settings to cacheFactory constructor
myCacheFactory = new DataCacheFactory(configuration);

//Get reference to named cache called "default"
myDefaultCache = myCacheFactory.GetCache("default");

Windows Server AppFabric Caching 主要特点有：

• 任何可以被序列化的 CLR 对象都可以通过简单的 Cache API 将数据缓存
• 支持企业规模：可支持上百台主机的服务器架构
• 可弹性的调整配置，并通过网络缓存服务
• 支持动态调整规模，可随时新增节点
• 支持高可用性架构
• 自动负载平衡
• 可与 Event Tracing for Windows (ETW), System Center 等机制整合管理与监控
• 提供与 ASP.NET 的无缝整合，将 Session 数据储存至缓存，也可在 Web farm 架构下将应用程序数据缓存 ，减少数据库大量读取的负担
• 第一版遵循 cache-aside architecture ( 明确快取, Explicit Caching )，意即你必须在你的应用程序中明确指明你要新增(Put)或移除(Remove)快取的项目，所有快取数据并不会自动与任何源数据库进行同步。

数据分类

你的应用程序中如果要充分利用AppFabric Caching的功能，很有必要了解通常缓存的数据类型。 这些数据类型可分类为引用数据、 活动数据和资源数据，因为不同的缓存数据类型适用的场景是不同的。

1. 引用数据类型（Reference Data）

   这种数据类型负责存储“较重要的数据”，而且这类数据都是不会经常变动的数据，而且每次变更数据都会建立一个新的版本，所以这类数据非常适合用来共享给多用户、多应用程序的情况，用来加速所有应用程序的访问速度，降低各应用程序对数据库系统造成的负荷。对于“读取”需求远大于“写入”需求的数据都很适合用这种数据类型进行数据缓存，例如：产品类别。

   针对大型应用程序或者大流量的网站，引用数据类型也可以设定成自动复制到缓存群集的多台服务器，以增加应用系统的扩展性。

2. 活动数据（Activity Data）

   所谓活动数据类型指的是生命周期很短的程序数据，这类数据通常不会被各应用程序或不同用户共享，例如购物车信息，就属于这类活动数据。这类数据在大型应用中甚至可以跨服务器的缓存空间，可以很轻易的达到高扩展性的需求。

3. 资源数据（Resource Data）

   不管是 Reference Data (共享读取) 或者 Activity Data (独占写入) 已经很适合做数据缓存，但并非所有应用程序类型都支持这种方式快取，这里的“资源数据”指的是“共享的”且“同时需要被读写”的数据，而且读写量都非常大的情况。 例如“库存信息”的库存量就经常变动，而且必须提供各应用程序实时的信息，而且可能随时变更库存数量，这类数据就称之为资源数据。

   这类型的缓存数据通常遇到最大的问题在于很难提供高有效性(High Availability)的支持，由于维护高有效性的数据必须精确的维持数据的一致性，所以必须实做事务处理(transactions)、变更通知(data change notifications)、设定缓存失效(invalidations)等特性，通过 AppFabric Caching可让你设定这类数据自动复写到不同快取主机，轻易达到 高有效性 的需求。

使用的场景

• 社交类SNS网站

    

      由于用户名称、好友列表都是不会经常变动的数据，所以这种情境很适合采用 参考数据类型 (Reference Data) 来进行快取。

• 企业应用系统( Enterprise LOB ) -- 例如: ERP, CRM, …
• 

      对于供货商数据、价格信息可以通过 参考数据类型 (Reference Data) 来进行快取，而其他像是订单信息、发票信息、付款信息 都可以用 活动数据类型 (Activity Data) 来快取。

AppFabric Caching 基本概念

上面讲的是关于“分布式缓存架构”的基本观念，这里讲的是“开发模型”的基本概念，了解这些概念才能让你在实际利用 AppFabric Caching (Code Name: Velocity) 开发程序时有比较清晰的概念。

逻辑层架构

逻辑架构依次描述如下：

• 每台 服务器 (Machine) 可以执行好几个 缓存实例(Cache Instance 或 Cache Host) ， 就好像一台机器可以运行好几个 SQL Server 实例一样的意思。
• 每个 缓存实例 (Cache Host) 可以包含多个 命名缓存空间 (Named Cache) ，命名缓存可以设置成跨越多个 Cache Hosts 或 Machines
• 每个 命名缓存空间 (Named Cache) 可以包含多个 区域 (Regions)
• 每个 缓存区域 (Regions) 可以包含多个 缓存项目 (Cache Items)
• 每个 缓存项目 (Cache Items) 包含 可序列化的 CLR对象 (Objects)

缓存概念（Cache Concepts）

• 主节点 ( Primary Node )

    所有 区域 (Regions) 的数据都会置于主要节点上，任何通过 Cache Client 过来获取缓存数据时都会自动被路由(Routed)到主要节点读写数据。

• 次节点 ( Secondary Nodes )

   如果 命名缓存空间 (Named Cache) 为了高可用性(high availability) 而配置“备份”，就会用“次要节点”用来储存这些“备份用的 区域 (Regions) ”备注: 区域包含多个缓存项目)。如果“主节点”损坏，缓存群集所收到的请求就会自动路由到“次节点”来取得读取资料。

缓存类型 ( Cache Types )

AppFabric 支持两种常见的缓存类型：分区缓存、本地缓存

• 分区缓存 ( Partitioned Cache )

讲“分区缓存”很容易误解其意思，这概念并不像“磁盘分区”那样一个实体硬盘分区成好几个扇区，而是将“所有缓存服务器”全部整合成一个内存缓存存储区 (缓存群集)，你可以在这个“缓存群集”分区出你想要的任何大小。 因此，通过 Partitioned Cache 很适合用在需要海量存储器缓存的应用程序，这可大幅提升应用程序的扩展性(Scalability)，当内存不够用时就只要增加服务器即可。 当新缓存服务器加入整个缓存群集后，AppFabric Caching 会自动进行负载均衡，并将部分缓存项目自动移至新主机，当缓存项目平均分散在各台主机后也会增加整体缓存群集的吞吐量(Throughtput)。 由于是将多台服务器整合成一个大内存，所以缓存数据并不会重复存储，如下图例：K2,V2 指的是 “Key/Value Pair 2” 的意思，由于通过 Put 指令写入缓存项目时势将数据写入到 Cache 2 这个 缓存实体(Cache Host) 中，所以当另一台主机从 Cache 3 取得(Get) K2,V2 数据时，就会通过 AppFabric Caching 内部的 Routing 机制从 Cache2 取得数据，而这些复杂的 Routing 作业全都由 AppFabric Caching 帮你完成。

Partitioned Cache 还能配置“次缓存节点”，让“主缓存数据”能自动将缓存项目复制到另一台主机，达到高有效性(High Availability)的目标，如下是 HA 模式的示意图：

• 本地快取 ( Local Cache )

  AppFabric  Caching也支持“本地缓存”，通过本地缓存可以有效省去“序列化/反序列化”的 CPU 成本，可提升读写缓存数据时的性能。 如下图示很容易能看出运用本地缓存的情景：

过期与回收 ( Expiration and Eviction )

• 缓存过期 ( Expiration )

在新增缓存项目到 Regions 时可以指定该对象的存活时间(TTL; Time To Live)

• 缓存回收 ( Eviction )

缓存项目可以设定优先等级，当高速缓存不够用时就会依据 LRU (least-recently-used) 算法将不常用的缓存项目删除，让优先权较高的缓存项目进入缓存服务器。

一致性模型 ( Consistency Models )

• 乐观版本更新机制 ( optimistic version-based updates )

通过这个机制可享受较高的执行效能，因为就算不同的 Client 端在同时执行 取得缓存(Get) 或 写入缓存(Put) 动作可以同时执行，Velocity 会在内部维护一份缓存项目的版本信息，而且会在每次取得(Get)数据时一并传回客户端，所以不用维护锁定(locking)的问题，但版本信息在 Client 端需自行判断新旧。

• 悲观锁定机制 ( pessimistic locking )

通过 API 提供的 GetandLock 取得数据时，若有其他程序也要通过 GetandLock 取得数据时就会发生失败，但若 Client 使用单纯的 Get 取得资料还是可以的。这时通过 PutAndLock 方法可以将数据回写至 Velocity，这时锁定状态就会被解除，但如果直接使用 Put 方法则会直接取消锁定状态并直接复写该对象的值，所以必须小心使用。通过 UnLock 方法也可以直接设定解除锁定。

变更通知 ( Notifications )

在分布式的架构下，由于多个客户端同时读写同一份资源，变更通知变的非常实用，当另一个客户端变更了某个 区域 (Regions) 或 缓存项目 (Cache Items) 时可以通过事件通知应用程序。

部署拓朴 ( Deployment Topology )

Velocity 是通过 Windows Service 提供服务，可以通过 TCP/IP 从本机或远程计算机联机，并通过 .NET Client API 直接操作使用。

如下图是两种常见的 Velocity 部署模式：

• Embedded

将 缓存宿主(Cache Host) 跟 IIS 主机安装在一起，并联合多台宿主组成缓存群集

• Cache Service

使用 专属主机 提供 缓存宿主(Cache Host)，提供一个宿主的 缓存层(Caching Tier)

ASP.NET集成 ( ASP.NET Integration )

AppFabric 提供一组 SessionStoreProvider 可让你很容易的将 Session 移至 AppFabric Caching 平台，并储存到一个 分区缓存 (Partitioned Cache) 中，通过设置也可以达到 HA (High Availability) 与 HS (High Scalability) 的规划。

性能测试 ( Performance Testing )

如下图示，只要新增缓存服务器几乎呈现“线性成长”的吞吐量，可有效提升应用程序的扩展性。

结论 ( Conclusion )

通过 AppFabric Caching 可以轻易的让你将多台服务器的内存融合成一个超大内存缓存，通过单一 API 即可读写这些内存缓存，当内存不够时只要增加服务器即可轻易扩充完成，不仅有效降低管理成本，还可轻易的达到 3H ( High Scalability, High Availability, High Performance ) 系统架构。