原标题：Spring认证中国教育管理中心-Apache Geode 的 Spring 数据教程七（Spring中国教育管理中心）
5.6.2.IgnoreIfExists和Override
Apache GeodeIndex配置选项的两个 Spring Data值得特别提及：ignoreIfExists和override.
这些选项分别对应于 Spring Data for Apache Geode 的 XML 命名空间中元素上的ignore-if-exists和override属性
在使用这些选项中的任何一个之前，请确保您完全了解自己在做什么。这些选项会影响应用程序在运行时消耗的性能和资源（例如内存）。因此，false默认情况下，这两个选项在 SDG 中都被禁用（设置为）。
这些选项仅在 Spring Data for Apache Geode 中可用，并且存在以解决 Apache Geode 的已知限制。Apache Geode 没有等效的选项或功能。
每个选项在行为上都存在显着差异，并且完全取决于Index抛出的 Apache Geode异常的类型。这也意味着如果没有抛出 Apache Geode Index 类型的异常，这两个选项都没有任何影响。这些选项旨在专门处理 Apache GeodeIndexExistsException和
IndexNameConflictException 实例，这可能出于各种原因，有时是模糊的原因。出现异常的原因如下：
一个IndexExistsException 当存在另一个被抛出Index具有相同的定义，但试图创建一个时，不同的名称Index。
一个IndexNameConflictException 当存在另一个被抛出Index试图创建一个在用相同的名字，但有可能不同的定义Index。
Spring Data for Apache Geode 的默认行为总是快速失败。因此，默认情况下不会“处理”这两个Index 异常。这些Index异常被包装在一个 SDG 中GemfireIndexException并被重新抛出。如果您希望 Spring Data for Apache Geode 为您处理它们，您可以将这些Indexbean 定义选项中的任何一个设置为true.
IgnoreIfExists总是优先于Override，主要是因为它使用较少的资源，仅仅因为它Index在两种例外情况下都返回“现有” 。
IgnoreIfExists行为
当 anIndexExistsException被抛出并被ignoreIfExists设置为true(or
返回现有的 没有什么影响Index，因为indexbean 定义是相同的，由 Apache Geode 本身决定，而不是 SDG。
但是，这也意味着从 Apache Geode 的角度来看Index，您的indexbean 定义或声明中指定的“名称”实际上不存在（即 with QueryService.getIndexes()）。因此，在编写使用查询提示的 OQL 查询语句时应该小心，尤其是引用Index被忽略的应用程序的查询提示。这些查询提示需要更改。
当
anIndexNameConflictException被抛出并被ignoreIfExists设置为true(or
但是，返回现有的Index并忽略应用程序对抛出Index an 时的定义存在更大的风险
IndexNameConflictException。对于 a IndexNameConflictException，虽然冲突索引的名称相同，但定义可能不同。这种情况可能会对特定于应用程序的 OQL 查询产生影响，在这种情况下，您会假设索引是专门根据应用程序数据访问模式和查询定义的。但是，如果同名索引的定义不同，则情况可能并非如此。因此，您应该验证您的Index姓名。
当Index被忽略的定义与现有定义明显不同时，SDG 会尽最大努力通知用户Index。然而，为了让 SDG 实现这一点，它必须能够找到现有的Index，这是通过使用 Apache Geode API（唯一可用的方法）查找的。
Override行为
当 anIndexExistsException被抛出并被override设置为true(或
Spring Data for Apache Geode 只能通过使用 Apache Geode 的 API 来实现这一点，首先删除现有的Index ，然后Index使用新名称重新创建。remove 或后续的 create 调用可能会失败。如果任何一个操作失败，都无法原子地执行这两个操作并回滚此联合操作。
但是，如果它成功，那么您将遇到与以前相同的ignoreIfExists选项问题。任何使用Index按名称引用旧的查询提示的现有 OQL 查询语句都必须更改。
当
anIndexNameConflictException被抛出并被override设置为true(or
如果是这样，SDG 是智能的，并按Index原样返回现有，即使在override. 这种行为没有害处，因为名称和定义完全相同。当然，SDG 只能在 SDG 能够找到现有 的情况下才能完成Index，这依赖于 Apache Geode 的 API。如果找不到，则什么也不会发生，并且GemfireIndexException会抛出一个 SDG包装
IndexNameConflictException.
但是，当存在的定义Index不同时，SDG 尝试Index 使用bean 定义中Index指定的定义重新创建index。确保这是您想要的，并确保indexbean 定义符合您的期望和应用程序要求。
IndexNameConflictExceptions实际情况如何？
IndexExistsExceptions抛出这种情况可能并不罕见，尤其是当使用多个配置源来配置 Apache Geode（用于 Apache Geode 的 Spring Data、Apache Geode Cluster Config、Apache Geode native cache.xml、API 等）时。您绝对应该更喜欢一种配置方法并坚持使用它。
但是，什么时候
IndexNameConflictException会抛出一个get 呢？
一种特殊情况是Index在PARTITION区域 (PR)上定义。当Index在PARTITION区域（例如X）上Index定义 时，Apache Geode 会将定义（和名称）分发给集群中也托管相同PARTITION区域（即“X”）的其他对等成员。对等成员分发此Index定义并随后创建此定义Index是在需要知道的基础上（即由托管同一 PR 的对等成员）异步执行的。
在这段时间里，IndexesApache Geode 可能无法识别这些待处理的PR——例如调用QueryService.getIndexes() with QueryService.getIndexes(:Region)，甚至调用QueryService.getIndex(:Region, indexName:String)。
因此，SDG 或其他 Apache Geode 缓存客户端应用程序（不涉及 Spring）确定知道的唯一方法是尝试创建Index. 如果它因
anIndexNameConflictException或什至 an失败IndexExistsException，则应用程序知道存在问题。这是因为QueryService Index创建会等待挂起的Index定义，而其他 Apache Geode API 调用则不会。
在任何情况下，SDG 都会尽最大努力并尝试通知您已经发生或正在发生的事情，并告诉您纠正措施。鉴于所有 Apache
GeodeQueryService.createIndex(..)方法都是同步的、阻塞的操作，因此在抛出这些索引类型异常中的任何一个后，Apache Geode 的状态应该是一致且可访问的。因此，SDG 可以检查系统状态并根据您的配置采取相应措施。
在所有其他情况下，SDG 采用快速失败策略。
5.7.配置磁盘存储
Spring Data for Apache Geode 支持DiskStore通过disk-store元素进行配置和创建，如下例所示：
queue-size="50" time-interval="9999">
DiskStore实例被区域用于文件系统持久备份和被驱逐条目的溢出以及 WAN 网关的持久备份。多个 Apache Geode 组件可能共享相同的DiskStore. 此外，可以为单个 定义多个文件系统目录DiskStore，如前面的示例所示。
有关实例的持久性和溢出 以及配置选项的完整说明，请参阅 Apache Geode 的文档 DiskStore。
5.8.配置快照服务
Spring Data for Apache Geode 通过使用Apache Geode 的 Snapshot Service支持缓存和区域快照 。开箱即用的快照服务支持提供了几个方便的功能来简化 Apache Geode 的 缓存 和区域 快照服务 API 的使用。
正如Apache Geode 文档所解释的那样，快照允许您保存并随后重新加载缓存的数据，这对于在环境之间移动数据非常有用，例如从生产环境到暂存或测试环境，以便在受控环境中重现与数据相关的问题。语境。您可以将 Spring Data for Apache Geode 的 Snapshot Service 支持与Spring 的 bean 定义配置文件相结合 ，以根据需要加载特定于环境的快照数据。
Spring Data for Apache Geode 对 Apache Geode 的快照服务的支持始于XML 命名空间中的
例如，您可以使用几个快照导入和数据导出定义来定义要加载和保存的缓存范围快照，如下所示：
location="/absolute/or/relative/filesystem/path/to/export/directory"/>
您可以根据需要定义任意数量的导入和导出。您可以仅定义导入或仅定义导出。文件位置和目录路径可以是绝对的，也可以是相对于 Spring Data for Apache Geode 应用程序的，它是 JVM 进程的工作目录。
前面的示例非常简单，在这种情况下定义的快照服务指的是默认名称为gemfireCache（如配置缓存中所述）的 Apache Geode 缓存实例。如果您将缓存 bean 定义命名为默认值以外的其他名称，则可以使用该cache-ref属性按名称引用缓存 bean，如下所示：
...
...
您还可以通过指定region-ref属性为特定区域定义快照服务，如下所示：
...
当region-ref属性指定的，春季数据为Apache的Geode的
SnapshotServiceFactoryBean解析region-ref 属性值在Spring容器中定义的地区豆和创建 RegionSnapshotService。快照导入和导出定义的功能相同。但是，location必须引用导出中的文件。
Spring认证中国教育管理中心-Apache Geode 的 Spring 数据教程七
Apache Geode 严格要求在引用之前实际存在的导入快照文件。对于导出，Apache Geode 创建快照文件。如果导出的快照文件已存在，则数据将被覆盖。
Spring Data for Apache
Geodesuppress-import-on-init在