本页面介绍 Rapid Cache 功能，它可为 Cloud Storage 存储分区提供由固态硬盘 (SSD) 支持的可用区级读取缓存，让您能够以更高的吞吐量和更低的延迟访问存储的数据。Rapid Cache 提供可根据您的需求自动扩缩的存储容量和带宽。
Rapid Cache 的优势使其有助于提升性能并降低涉及大量读取的工作负载相关的网络费用。
如需了解如何在 Rapid Cache 中创建和管理缓存，请参阅创建和管理缓存。
工作原理
Rapid Cache 可让您在与工作负载相同的可用区中创建缓存。在某个可用区中创建缓存时，源自该可用区的读取数据请求将由缓存（而非存储桶）进行处理。每个缓存都为其可用区内的客户端提供服务。只有当数据由缓存所在可用区中的虚拟机读取时，才会从存储桶注入到缓存中。此外，如果您配置了写入时注入，则可以在数据写入存储桶时注入数据。元数据不会缓存，针对对象元数据的请求由存储桶（而非缓存）处理。
Rapid Cache 是一项全代管式服务，始终返回一致的数据。
优势
使用 Rapid Cache 缓存数据可获得以下好处：
获得更快的数据访问速度：Rapid Cache 将您的数据与计算资源放置在同一可用区中，并完全由 SSD 提供支持。这可让您的工作负载获得高达 2.5 TB/秒的吞吐量，并缩短延迟时间，从而加快读取速度。
降低多区域数据传输费用：与直接从多区域存储桶读取的数据相比，从缓存读取的数据会产生较低的数据传输费用。
减少检索费用：对于 Nearline Storage、Coldline Storage 和 Archive Storage 中的存储桶，从缓存读取数据不会产生检索费用。
读取操作产生的费用更低：通过快速缓存处理的读取操作的价格低于通过 Standard Storage 中的存储桶处理的 B 类操作的价格。
自动扩缩缓存大小：Rapid Cache 的动态 SSD 缓存会根据使用情况自动扩缩，而无需您指定缓存大小。
高效使用缓存：您可以在现有存储分区上启用 Rapid Cache，而无需更改现有应用或 API。存储在 Rapid Cache 中的数据具有强一致性。
如需详细了解价格，请参阅 Rapid Cache 价格。如需了解配额，请参阅Rapid Cache 配额。
何时应使用 Rapid Cache？
对于不经常更改但经常读取的数据，请使用 Rapid Cache 来加快数据读取速度，以用于分析工作负载和 AI/机器学习模型训练及加载。
假设您要跨多个 Google Kubernetes Engine 节点训练 AI 模型，这些节点都反复读取存储在 Cloud Storage 存储桶中的数据，并且它们在相同的可用区中运行。当您在工作负载运行的可用区内创建缓存时，该缓存可提供额外的带宽，并帮助您减少在多区域存储桶中读取数据而产生的数据传输费用，从而更高效地运行更大规模的扩缩工作负载。
缓存大小和带宽限制自动扩缩
Rapid Cache 提供临时存储空间容量和带宽，可根据缓存中存储的数据量自动扩缩。
缓存带宽上限的初始值为 100 Gbps，每增减 1 TiB 存储数据便扩缩 20 Gbps。您可以通过增加缓存中存储的数据量、在可用区中创建更多缓存，或者联系您的技术支持客户经理或 Google 代表，来提高起始带宽或总带宽上限。
如需详细了解 Rapid Cache 的大小和带宽限制，请参阅 Cloud Storage 配额和限制。
在可用区中缓存数据
为存储桶创建缓存时，必须在存储桶所在位置内的某个可用区中创建缓存。例如，如果您的存储桶位于 us-east1 区域，您可以在 us-east1-b 中创建缓存，但不能在 us-central1-c 中创建缓存。如果您的存储桶位于 ASIA 双区域中，您可以在 asia-east1 和 asia-southeast1 区域内的任何可用区中创建缓存。
对于每个存储桶，您最多可以在每个可用区创建一个缓存。例如，如果某个存储桶位于 us-east1 区域，您可以在 us-east1-b 中创建一个缓存，并在 us-east1-c 中创建另一个缓存。如果存储桶位于包含 us-central1 和 us-east1 的多区域中，您可以在 us-central1-a 中创建一个缓存，并在 us-east1-b 中创建另一个缓存。
只要可用区有可用容量，您就可以在该可用区中创建缓存。 如果没有可用于创建缓存的容量，Rapid Cache 会继续尝试创建缓存，直到容量可用或用户取消创建过程为止。容量可能会长时间处于不可用状态。
您可以在以下可用区中使用 Rapid Cache。您可以根据存储桶的位置类型使用这些可用区。
亚洲
下表显示了亚洲地理区域中可用于 Rapid Cache 的可用区和位置类型。
| 区域名称 | 区域 | 双区域 | 多区域 | 自定义双区域 |
|---|---|---|---|---|
asia-east1-a |
||||
asia-east1-b |
||||
asia-east1-c |
||||
asia-northeast1-a |
||||
asia-northeast1-b |
||||
asia-northeast1-c |
||||
asia-south1-a |
||||
asia-south1-b |
||||
asia-south1-c |
||||
asia-southeast1-a |
||||
asia-southeast1-b |
||||
asia-southeast1-c |
欧洲
下表显示了欧洲地理区域中可用于 Rapid Cache 的可用地区和位置类型。
| 区域名称 | 区域 | 双区域 | 多区域 | 自定义双区域 |
|---|---|---|---|---|
europe-north1-a |
||||
europe-north1-b |
||||
europe-north1-c |
||||
europe-west1-b |
||||
europe-west1-c |
||||
europe-west1-d |
||||
europe-west4-a |
||||
europe-west4-b |
||||
europe-west4-c |
||||
europe-west4-ai1a
（AI 可用区）
|
||||
europe-west6-a |
||||
europe-west6-b |
美国
下表显示了美国地理区域中可用于 Rapid Cache 的可用区和位置类型。
| 区域名称 | 区域 | 双区域 | 多区域 | 自定义双区域 |
|---|---|---|---|---|
us-central1-a |
||||
us-central1-b |
||||
us-central1-c |
||||
us-central1-f |
||||
us-central1-ai1a
（AI 可用区）
|
||||
us-east1-b |
||||
us-east1-c |
||||
us-east1-d |
||||
us-east4-a |
||||
us-east4-b |
||||
us-east4-c |
||||
us-east5-a |
||||
us-east5-b |
||||
us-east5-c |
||||
us-south1-a |
||||
us-south1-b |
||||
us-south1-c |
||||
us-south1-ai1b
（AI 可用区）
|
||||
us-west1-a |
||||
us-west1-b |
||||
us-west1-c |
||||
us-west2-a |
||||
us-west3-a |
||||
us-west3-b |
||||
us-west3-c |
||||
us-west4-a |
||||
us-west4-b |
||||
us-west4-c |
数据注入
默认情况下，数据只有在首次被请求后才会注入到缓存中。由于缓存在此初始请求期间为空，因此首次读取会导致缓存未命中，系统会改为从存储桶中提取数据。在将数据传送给用户的同时，系统也会将数据注入到缓存中。因此，所有后续读取都会直接从缓存中以缓存命中的方式提供，从而大幅提高性能。
为完全避免初始请求缓慢，您可以将缓存配置为在写入时注入数据，这意味着它会在数据写入存储桶的那一刻加载数据。在写入时将数据提取到缓存中非常适合需要从首次读取开始就实现极快速度的工作流，例如恢复系统检查点或为模型训练准备数据流水线。
将数据注入到 Rapid Cache 中时，Rapid Cache 会将对象分解为较小的固定大小的块。将对象分成多个块可以实现更精细的缓存，尤其适用于仅访问特定部分的大型文件。
块是指 2 MB 的数据块。当请求某个对象时，Rapid Cache 会确定哪些 2 MB 块涵盖了所请求的字节范围，并单独管理这些块。
数据注入行为因注入到缓存中的对象大小而异：
对于针对大于 2 MB 的对象的读取请求，系统只会提取包含所请求字节范围的数据块。例如，读取 100 MB 文件的前 1 MB 内容时，系统只会提取前 2 MB 的数据块。
对于读取小于 2 MB 的对象（例如 500 KB 的图片）的读取请求，整个对象都会被提取到缓存中。
缓存配置
存留时间 (TTL)
TTL 是指数据块从上次读取起将在缓存中保留的最长时间。例如，如果 TTL 设置为 24 小时，某一个数据块的上次读取时间是周一上午 11 点，如果在这之后没有发生读取，该数据块将在周二上午 11 点从缓存中逐出。您可以将 TTL 设置为 24 小时到 7 天之间的值。如果未指定，TTL 默认设置为 24 小时。
写入时注入
在对象写入时将数据注入缓存，可加速写入后读取工作负载，例如检查点和训练作业的数据准备输出。如果您将缓存配置为在写入时注入数据，则数据在上传到存储桶时会写入缓存。这种主动式方法可消除初始缓存未命中，并使您的工作负载在首次读取时立即受益于缓存命中。
缓存操作
本部分介绍您可以在 Rapid Cache 缓存上执行的操作。有些操作是异步的，会返回一个长时间运行的操作；其他操作是同步的，操作会立即完成并返回 AnywhereCache 资源。
创建缓存
当您创建缓存时，在创建过程中，缓存为 CREATING 状态，在运行过程中，缓存为 RUNNING 状态。缓存创建操作最多可能需要 48 小时才能完成，之后操作会超时。
AnywhereCaches Create API 是异步的。创建操作会返回长时间运行的操作。长时间运行的操作会提供创建操作的状态，并且您可以在操作完成之前取消操作。
更新缓存
您可以更新处于 RUNNING 状态的缓存的 TTL 或注入行为。当缓存正在更新时，pending_update 字段的值为 true。当 pending_update 字段的值为 true 时，缓存无法再次更新。当缓存的 TTL 完成更新后，新的 TTL 会立即应用于缓存中的现有数据和新数据。
处于 CREATING 或 DISABLED 状态的缓存无法更新。
AnywhereCaches Update API 是异步的，并返回长时间运行的操作。
获取缓存
当您获取缓存时，Rapid Cache 会返回缓存实例的状态和配置。AnywhereCaches Get API 是同步的，并返回 AnywhereCache 资源。
列出缓存
您可以返回给定存储桶的关联缓存列表。AnywhereCaches List API 是同步的，并支持分页。
停用缓存
您可以停用缓存，以便从存储桶的配置中永久移除该缓存。停用缓存后，它会变为 DISABLED 状态。在此状态下，您仍然可以从缓存中读取现有数据，但无法将新数据注入到缓存中。
被停用的缓存有 1 小时的宽限期，在此期间，您可以通过恢复缓存来取消停用。在 1 小时的宽限期结束后，缓存会被删除。当缓存被删除时，该缓存中的所有数据都会被逐出，并且缓存会从存储桶中移除。
在缓存被删除前的 1 小时内，您可以通过恢复缓存来还原 DISABLED 状态，此时缓存会恢复为 RUNNING 状态。
AnywhereCaches Disable API 是同步的，并返回 AnywhereCache 资源。
恢复缓存
您可以恢复处于 DISABLED 状态的缓存，前提是停用的缓存在 1 小时的宽限期内。在 1 小时的宽限期过后，系统会尽力执行恢复操作，因为缓存可能会在宽限期后的任何时间点被删除。缓存恢复后，会进入 RUNNING 状态。
AnywhereCaches Resume API 是同步的，并返回 AnywhereCache 资源。
Rapid Cache Recommender
Rapid Cache Recommender 会分析流量使用和存储空间，并提供有关在存储桶/可用区对中创建缓存的建议和分析洞见。如需了解有关使用 Rapid Cache Recommender 的概览信息和说明，请参阅 Rapid Cache Recommender。
使用 Rapid Cache 来加速 BigQuery 读取操作
Rapid Cache 可用于处理 BigQuery 发出的对象读取请求的数据。使用 Rapid Cache，您可以加快应用的数据读取速度，同时优化成本效益。
虽然 BigQuery 是一项区域级服务，但其底层计算资源有时可能会在可用区之间转移，以实现负载均衡。最佳实践是，在某个区域的所有可用区中为 BigQuery 工作负载启用 Rapid Cache，以确保在底层计算资源更改可用区时，有可用的缓存可供使用。如果某个可用区中的缓存未使用，则不会产生额外费用，因为 Rapid Cache 采用的是按用量付费模式。请注意，如果工作负载的资源更改了可用区，新可用区中的缓存将需要重新注入数据，这可能会导致数据注入费用一次性增加。
缓存数据加密
数据以原始服务器端加密格式存储在缓存中，从而与 Cloud Storage 支持的加密选项兼容。
局限和限制
如需删除存储桶，您必须先删除其所有关联的缓存。唯一的例外情况是使用 Google Cloud 控制台删除存储桶时，系统会同时删除所有关联的缓存。
在执行缓存创建、停用、恢复或更新操作时，将操作速率限制为每秒不超过一项操作。每秒执行多项操作可能会导致失败。
Rapid Cache 不是持久性存储，缓存中的数据可能会因各种原因被删除。一种情况是，缓存自动调整大小，以确保有足够的资源可供工作负载使用。在这种情况下，某些数据可能会根据“最近最少使用”(LRU) 算法被逐出，直到 Rapid Cache 服务增加缓存大小。
在任何情况下，您的数据都会安全地存储在源存储桶中。如果数据因 TTL 到期以外的原因而从缓存中移除，Rapid Cache 服务会尝试以透明的方式将数据重新注入到缓存中，而您无需为此付费。如果数据无法透明地重新注入，或者因 TTL 过期而被移除，Rapid Cache 服务将在第一次读取时重新注入数据。
无法使用 BigQuery 读取通过 Rapid Cache Recommender 生成的建议和数据分析。
性能考虑因素
块缺失：如果请求涵盖多个块，并且某些块位于缓存中，而其他块不在缓存中，则 Rapid Cache 会从源存储桶中透明地检索缺失的块。
TTL 和逐出：存留时间 (TTL) 和最近最少使用 (LRU) 逐出政策也适用于数据块。大文件中经常使用的部分可能会保留在缓存中，而很少使用的部分会被逐出。
价格
如需了解使用 Rapid Cache 的价格，请参阅 Rapid Cache 价格。
费用控制
展开即可下提示，了解如何尽可能降低运行缓存的费用：
存储分区选择
您应仅为包含要缓存的数据的存储分区创建缓存。
区域选择
您应仅在工作负载将受益于缓存的可用区中创建缓存。
TTL 设置
您应指定在缓存中存储数据所需的最小 TTL。TTL 可以在不中断操作的情况下更改。默认值为 1 天。
停用缓存
您可以停用缓存，以便将其从服务中永久移除，并停止产生所有相关的缓存费用。
排查暂时性资源短缺问题
以下部分介绍了在发生暂时性资源短缺时如何进行问题排查，暂时性资源短缺是指指定可用区中没有足够的 SSD 容量或服务容量来创建缓存、增加缓存大小或增加缓存带宽限制。
无法创建新缓存
由于缺少 SSD 容量或吞吐量服务资源，Rapid Cache 可能无法在特定可用区中创建新缓存，从而导致暂时性的资源短缺。在此时间段内，Rapid Cache 会尝试创建新缓存，尝试最长持续 48 小时。如果在 48 小时内有资源可用，Rapid Cache 会成功完成缓存创建请求。如果在 48 小时内没有资源可用，缓存创建请求会失败。
问题排查：为避免缓存中断，您可以手动取消缓存创建操作，并在可能具有可用容量的其他可用区中创建新缓存。如需监控或取消缓存创建操作，请参阅使用长时间运行的操作。
无法增加缓存大小
如果缓存的可用区中没有所需的 SSD 容量，Rapid Cache 可能会无法增加缓存的大小。
虽然 Rapid Cache 可按需自动增加缓存大小，但能否增加缓存大小取决于 SSD 容量的可用性。如果在发出自动增加缓存大小的请求时没有可用的 SSD 容量，Rapid Cache 会继续提交请求，直到暂时性资源短缺结束或不再需要增加缓存大小为止。
在暂时性资源短缺期间，系统会注入新数据，并根据最近最少使用算法逐出缓存中的现有数据。如果缓存足够大，可以存储大部分热数据，则对缓存指标几乎没有影响。与不受资源短缺影响的缓存相比，容量小于热数据量的缓存需要更频繁地逐出数据并重新注入相同数据。如果缓存的实际大小远小于所需容量，可能会出现以下与资源短缺相关的行为：
- 缓存带宽限制降低，缓存吞吐量降低，数据传输带宽配额消耗增加，并且可能会对其他指标产生影响
- 结算可能有以下影响：
- 缓存注入费用使成本增加
- 缓存存储费用使成本降低
- 缓存数据传出费用使成本降低
- 缓存数据传出操作费用使成本降低
- 多区域数据传输费用使成本增加
- 使用 B 类操作使成本增加
如需了解这些费用，请参阅 Rapid Cache 价格。
问题排查方法：为了在暂时性资源短缺期间获得最佳效果，我们建议您监控缓存，并根据需要停用不必要的缓存或工作负载。
无法提高缓存的带宽限制
在缓存大小增加期间，如果特定可用区中的吞吐量服务资源不足以将现有缓存的缓存带宽限制以 20 Gbps/TiB 为单位提高，则可能会暂时出现缓存带宽限制短缺的情况。在可用缓存带宽短缺期间，Rapid Cache 不允许缓存带宽限制以每 TiB 数据 20 Gbps 为单位提高，但缓存会继续响应读取请求。您可以与您的技术支持客户经理或 Google 代表联系，申请增加缓存带宽。在可用缓存带宽短缺期间，您可能会看到存储桶的数据出站流量带宽消耗量有所增加。
问题排查方法：为了在暂时性资源短缺期间获得最佳效果，我们建议您监控缓存，并根据需要停用不必要的缓存或工作负载。