7.2.3 [Enterprise Library]选择后端存储
每个缓存管理器都可以配置为仅将数据保存在内存中，这意味着它使用的是空后端存储；或者配置为将数据既保存在内存中也保存到持久存储中。持久存储的类型在配置后端存储时指定 。后端存储使缓存的数据在应用程序必须重启时得以幸免。在它的初始状态下，缓存应用程序块支持二种持久后端存储，每一种都适用于特定的情况：
-
独立存储
-
数据库缓存存储
开发人员可以扩展缓存应用程序块以支持其他的后端存储类型，有关此主题的更多信息，请参见添加一个新的后端存储。
注意
一个应用程序可以使用多于一个的缓存，每个缓存将由应用程序配置中的一个缓存管理器所表示。缓存应用程序块不支持在一个应用程序中的多个缓存管理器使用同样的持久后端存储位置。然而，同一应用程序中的多个缓存管理器可以有同样的分区名称。
使用空后端存储
空后端存储是配置缓存应用块的默认选择。它不持久化缓存的条目，这意味着缓存的数据仅保存在内存中，而不存在于持久存储中。空后端存储适用于在应用程序重启时要从原始数据源刷新缓存的条目的情况。它可以用于所有支持的应用程序类型，这些类型的列表，请参见缓存应用程序块介绍。
使用独立存储的后端存储
独立存储适用于下列情况：
-
需要持久存储且用户量少
-
使用数据库的开销非常大
-
没有数据库
关于何时使用独立存储的更多信息，请参见 MSDN 上的 Scenarios for Isolated Storage 在配置使用独立存储时，后端存储由缓存实例名称、用户名、程序集和应用程序域来隔离。
独立存储适用于智能客户端和每个应用程序域有自己的缓存的服务器程序。同时也要注意，因为独立存储总是用用户来隔离，所以服务器应用程序必须模拟请求应用程序的用户。
使用数据访问应用程序块后端存储
使用数据访问应用程序块后端存储允许存储缓存的数据到一个数据库中。现在，缓存应用程序块包含一个创建需要的 SQL Server 数据库模式的脚本，并且应用程序块已经测试了对应的 SQL Server 数据库。开发人员可以使用其他类型的数据库做为后端存储，但必须修改应用程序块的源代码。每种数据库类型必须有一个用于数据访问应用程序块的数据库提供程序并包含兼容的模式。
数据访问应用程序块后端存储选项适用于智能客户端和每个应用程序域有自己的缓存的服务器应用程序，以及要访问数据库的情况。
运行在单一应用程序域中的每个 CacheManager
必须使用不同的数据库分区，一个分区定义为应用程序名称和缓存实例名称的组合。数据库可以与使用缓存的应用程序运行在同一服务器上或不同服务器上。数据库支持的使用缓存的应用程序数量仅依赖于数据库的存储限制。
服务器场景的考虑
单一的缓存管理器不能跨应用程序域共享。部署在多台计算机上的服务器应用程序在每台计算机上都有唯一的内存缓存副本，运行在同一计算机上的多个进程也是这样的，包括运行在自己的进程中并使用了缓存应用程序块的企业服务组件。每个进程有自己的内存缓存副本。
不同应用程序不能使用一样的数据访问应用程序块后端存储实例和分区。用缓存应用程序块配置使用同样的数据库实例和分区来运行不同的应用程序将导致不可预知的结果，并且不推荐这样做。
当同样的应用程序运行在多个进程中时(例如，如果应用程序部署在 Web farm 中的多台计算机中)，可以使用下列三种方法之一来配置缓存应用程序块：
-
所有的应用程序实例使用同样的数据库实例，但每个应用程序实例使用不同的数据库分区。更多信息，请参见后面的场景一。
-
所有应用程序实例使用同样的数据库实例、同样的数据库分区，并且所有的缓存管理器都可以读和写缓存。更多信息，请参见后面的场景二。
-
所有应用程序实例使用同样的数据库实例、同样的数据库分区，但仅有一个缓存管理器可以写缓存。所有缓存管理器可以从缓存中读。更多信息，请参见后面的场景三。
场景一：分区的缓存
场景一是所有应用程序实例使用同样的数据库实例，但每个应用程序实例使用不同的数据库分区的情形。在这个场景中，每个缓存管理器的操作都是独立的。尽管它们共享了同样的后端存储数据库实例，每个缓存管理器持久缓存数据到不同的分区。此时每个应用程序实例仅有一个有效的缓存。当应用程序重启时，每个缓存管理器从后端存储中的自己的分区中加载它的数据。
如果应用程序预加载缓存，每个部署的应用程序实例都从原始数据源中获取数据。预加载数据使用每个部署的应用程序实例的后端存储储存空间。这意味着在使用缓存的条件下，部署同样的应用程序到多个进程并不比部署不同的应用程序更有效率。
部署同样的应用程序到多台服务器，服务器的每个配置应用程序块都配置为相同的(例如，所有应用程序块使用同样的过期策略)，不保证在每个后端存储分区中的数据是相同的。在后端存储分区中的数据复制了配置为使用后端存储分区的缓存管理器的内存缓存数据。内存缓存中的内容随着使用缓存应用程序特定实例而变化，因为应用程序要求路由到不同的服务器，所以每台服务器中内存缓存可能是不同的，因此后端存储分区中的内容也可能是不同的。这意味着，即使所有应用程序同时关闭再重启，也不能保证在每个缓存用后端存储中的数据初始化后其内存缓存中的数据是一样的。
场景二：共享分区
场景二是所有应用程序的实例使用同样的数据库实例和同样的数据库分区，而且所有的缓存管理器都读写缓存。在此场景中，每个应用程序实例操作相互唯一的内存缓存。当应用程序创建一个缓存管理器时，缓存管理器将后端存储中的数据放入内存缓存中，这意味着，如果应用程序在它启动时创建一个缓存管理器，并且如果所有应用程序实例都同时启动的话，每个内存缓存将加载同样的数据。因为应用程序使用了相同的分区，每个应用程序实例不需要在后端存储中的附加存储。
缓存管理器创建的时间是从后端存储加载数据到内存缓存的唯一时间。在此之后，内存缓存中的内容将由使用缓存的应用程序实例所决定。应用程序实例使用缓存的方法可以互不相同，因为需要路由到不同的服务器。运行的不同应用程序实例可以有不同内容的内存缓存。
随着应用程序添加和删除条目，内存缓存的内容会改变，内存缓存的内容在缓存管理器移除或清除过期条目时也会改变。随着内存缓存的改变，缓存管理更新后端存储以反映这些改变。后端存储在它的内存发生改变时不会通知缓存管理器。因此，当一个应用程序实例改变后端存储的内容时，其他应用程序将有与后端存储数据不匹配的内存缓存。这意味着，在应用程序重启以后，内存缓存可以有与在应用程序重启前不一样的内容。
当条目过期时，应用程序可以由缓存管理器提供的提交事件来通知，应用程序可以使用这个通知来从源数据源中刷新缓存的数据。当应用程序添加刷新的缓存条目到缓存中时，缓存管理器也用这些数据更新后端存储。如果应用程序部署在多台计算机上，每个应用程序实例都会收到事件，然后为同样的条目初始化对原始数据源的请求。这多个请求可以对应用程序和原始数据源的性能形成重大的消极影响。因此，使用通知来为刷新过期缓存条目的目的而监视过期在此场景中是不推荐的。
场景三：单一写
场景三是所有应用程序使用同样的数据库实例、同样的数据库分区，而仅有一个缓存管理器可以写缓存，所有的缓存管理器可以从缓存中读。在此场景中，只有一个应用程序实例写缓存，所有其他实用程序实例只能从缓存中读取。可以写缓存的应用程序实例是主机 ，主机的内存缓存与后端存储有着同样的数据。在每个应用程序实例中的内存缓存在缓存管理器创建时用来自后端存储中的数据填充。只能从缓存中读取的应用程序实例获取一个数据快照，因为应用程序实例没有刷新它们的缓存的能力，它们的缓存将在条目过期时失效并缩水。
