这套 AppFabric Caching 比我用过的 memcached 复杂多了，MSDN有一篇文章进行介绍Introduction to Caching with Windows Server A...
这套 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 ) 应用系统的开发。
1: //Define Array for 1 Cache Host
2: List<DataCacheServerEndpoint> servers = new
3:
4: //Specify Cache Host Details
5: // Parameter 1 = host name
6: // Parameter 2 = cache port number
7: servers.Add(new DataCacheServerEndpoint("localhost", 22233));8:
9: //Create cache configuration
10: DataCacheFactoryConfiguration configuration = new
11:
12: //Set the cache host(s)
13:
14:
15: //Set default properties for local cache (local cache disabled)
16: configuration.LocalCacheProperties = new
17:
18: //Disable exception messages since this sample works on a cache aside
19:
20:
21: //Pass configuration settings to cacheFactory constructor
22: myCacheFactory = new
23:
24: //Get reference to named cache called "default"
25: 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的功能，很有必要了解通常缓存的数据类型。 这些数据类型可分类为引用数据、 活动数据和资源数据，因为不同的缓存数据类型适用的场景是不同的。
- 引用数据类型（Reference Data）这种数据类型负责存储“较重要的数据”，而且这类数据都是不会经常变动的数据，而且每次变更数据都会建立一个新的版本，所以这类数据非常适合用来共享给多用户、多应用程序的情况，用来加速所有应用程序的访问速度，降低各应用程序对数据库系统造成的负荷。对于“读取”需求远大于“写入”需求的数据都很适合用这种数据类型进行数据缓存，例如：产品类别。
针对大型应用程序或者大流量的网站，引用数据类型也可以设定成自动复制到缓存群集的多台服务器，以增加应用系统的扩展性。 - 活动数据（Activity Data）所谓活动数据类型指的是生命周期很短的程序数据，这类数据通常不会被各应用程序或不同用户共享，例如购物车信息，就属于这类活动数据。这类数据在大型应用中甚至可以跨服务器的缓存空间，可以很轻易的达到高扩展性的需求。
- 资源数据（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) ，
- 每个缓存实例 (Cache Host)可以包含多个命名缓存空间 (Named Cache) ，命名缓存可以设置成跨越多个 Cache Hosts 或 Machines
- 每个命名缓存空间 (Named Cache)可以包含多个区域 (Regions)
- 每个缓存区域 (Regions)可以包含多个缓存项目 (Cache Items)
- 每个缓存项目 (Cache Items)包含可序列化的 CLR对象 (Objects)
缓存概念（Cache Concepts）
- 主节点 ( Primary Node )
区域 (Regions)
- 次节点 ( 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)
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)
性能测试 ( Performance Testing )
如下图示，只要新增缓存服务器几乎呈现“线性成长”的吞吐量，可有效提升应用程序的扩展性。
结论 ( Conclusion )
通过 AppFabric Caching 可以轻易的让你将多台服务器的内存融合成一个超大内存缓存，通过单一 API 即可读写这些内存缓存，当内存不够时只要增加服务器即可轻易扩充完成，不仅有效降低管理成本，还可轻易的达到 3H ( High Scalability, High Availability, High Performance ) 系统架构。