本页面介绍 Rapid Cache 功能，它可为 Cloud Storage 存储桶提供由固态硬盘 (SSD) 支持的可用区级读取缓存，从而提高存储数据的吞吐量并缩短延迟时间。Rapid Cache 提供可根据您的需求自动扩缩的存储空间容量和带宽。Rapid Cache 是一项全代管式服务，可返回一致的数据。
Rapid Cache 有助于提高读取密集型工作负载的性能并降低网络费用。如需了解详情，请参阅福利。
如需了解如何使用 Rapid Cache 创建和管理缓存，请参阅创建和管理缓存。
Rapid Cache 的工作原理是什么？
Rapid Cache 可让您在与工作负载相同的可用区中创建缓存。在某个可用区中创建缓存时，源自该可用区的读取数据请求将由缓存（而非存储桶）进行处理。每个缓存都为其可用区内的客户端提供服务。
当缓存所在可用区中的虚拟机读取存储桶中的数据时，数据会注入到缓存中。如果您配置了写入时注入行为，那么在数据写入存储桶时，系统也会将其注入缓存。
元数据不会缓存。针对对象元数据的请求始终由存储桶（而非缓存）处理。
如需详细了解数据如何注入到缓存中，请参阅数据注入。您可以在创建或更新缓存时配置缓存的存留时间 (TTL) 和 ingest-on-write 行为。
优势
使用 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 存储桶中的数据，并且它们在相同的可用区中运行。当您在工作负载运行的可用区内创建缓存时，该缓存可提供额外的带宽，并帮助您减少在多区域存储桶中读取数据而产生的数据传输费用，从而更高效地运行更大规模的扩缩工作负载。
缓存大小和带宽限制自动扩缩
快速缓存可提供临时存储空间容量和带宽，这些资源会根据缓存中存储的数据量自动扩缩。
缓存带宽上限的初始值为 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-west3-a |
||||
europe-west3-b |
||||
europe-west3-c |
||||
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 |
缓存的数据注入
默认情况下，数据在首次被请求后会注入到缓存中。
由于此初始请求到达时缓存为空，因此暂时无法在缓存中找到相应数据。这会导致初始缓存未命中，系统会改为从后备 Cloud Storage 存储桶中检索数据。当系统将检索到的数据传送给用户时，会同时将数据注入到缓存中。
完成此首次请求后，数据会驻留在缓存中，从而使所有后续读取都能直接从缓存中以高速缓存命中的方式返回。此行为可显著缩短读取延迟时间并加快数据检索速度。注入的数据会保留在缓存中，直到其 TTL 到期，之后数据会被从缓存中逐出。
为完全避免初始请求缓慢，您可以配置缓存以在写入时注入数据，而不仅仅是在首次读取后注入数据。
以块的形式注入数据
将数据注入缓存时，Rapid Cache 会将对象分解为较小的固定大小的块。将对象分成多个块可以实现更精细的缓存，尤其适用于仅访问特定部分的大型文件。
块是指 2 MB 的数据块。当请求某个对象时，Rapid Cache 会确定哪些 2 MB 块涵盖了所请求的字节范围，并单独管理这些块。
数据注入行为因注入到缓存中的对象大小而异：
对于针对大于 2 MB 的对象的读取请求，系统只会提取包含所请求字节范围的块。例如，读取 100 MB 文件的前 1 MB 内容只会提取前 2 MB 的块。
对于读取小于 2 MB 的对象（例如 500 KB 的图片）的读取请求，整个对象都会被提取到缓存中。
在写入时注入数据
当您启用在写入时将数据注入缓存的功能后，数据会在写入存储桶的那一刻注入缓存。除了在初始读取后提取数据的默认缓存行为之外，还可以选择性地启用此行为。
写入时注入功能可消除初始缓存未命中，并让您的工作负载在首次读取数据时立即受益于缓存命中。在写入时提取数据可加快写入后读取工作负载的速度，例如恢复系统检查点或准备用于模型训练的数据流水线。
您可以在创建或更新缓存时启用缓存以在写入时注入数据。您可以配置缓存，以注入写入存储桶的所有对象（也称为“存储桶级写入时注入”），也可以选择性地注入写入指定托管文件夹下存储桶的对象（也称为“前缀级写入时注入”）。
例如，假设您启用缓存，以对存储桶 my-bucket 中名称带有前缀 red/ 的对象执行前缀级写入时注入操作。然后，您将三个对象上传到 my-bucket：对象 red/my-dog.png、blue/my-cat.png 和 red/my-goldfish.png。因此，在上传到 my-bucket 后，只有对象 red/my-dog.png 和 red/my-goldfish.png 会被提取到缓存中。
使用某些工具（例如Google Cloud 控制台）配置前缀级写入时注入时，如果您指定的前缀不是现有托管文件夹的名称，系统会自动为您创建一个新的托管文件夹。不过，在使用 JSON API 时，您必须手动创建受管理的文件夹，并为每个缓存区应用 ingestOnWrite 设置。您可以在使用 Rapid Cache中找到有关如何使用每种工具启用或停用写入时注入的说明。
如需了解在使用 JSON API 时如何在存储桶或前缀级层启用或停用写入时注入功能，请展开了解如何启用写入时注入功能部分。本部分中的信息主要仅适用于 JSON API；其他工具（例如Google Cloud 控制台）会模糊处理部分设置，以便更轻松地启用和管理写入时注入。
了解如何启用写入时注入
本部分将帮助您了解应使用哪些 JSON API 设置来为写入存储桶的所有对象启用写入时注入功能，或者仅为写入存储桶中托管文件夹前缀下的所选对象启用写入时注入功能。
有两项设置可控制缓存是否在写入时提取数据，以用于存储桶中的所有对象或仅用于具有特定前缀的选择性对象：
-
通过使用缓存资源的
ingestOnWrite字段，可以在存储桶级启用写入时注入。该字段如下所示：{ "zone": "us-east1-a", "ttl": "24h", "ingestOnWrite": true }- 如果设置为
true，则写入时注入功能会针对写入存储桶的所有对象启用。这会覆盖任何托管式文件夹级设置，这些设置会按前缀为所选对象启用写入时注入。 - 如果设置为
false，则写入时注入功能会在存储桶范围内的对象上停用。此设置允许通过受管理的文件夹设置，按前缀为所选对象启用写入时注入。
- 如果设置为
-
通过使用托管式文件夹可以实现前缀级写入时注入。托管式文件夹表示以尾部斜杠结尾的前缀路径（例如
my-prefix/）。启用前缀级写入时注入后，缓存仅在对象名称中包含相应前缀时才会在写入时选择性地注入对象。前缀级写入时注入通过受管文件夹资源中
rapidCacheConfig.policies映射的ingestOnWrite字段进行控制。 必须存在缓存实例，才能在rapidCacheConfig.policies映射中指定该实例。受管文件夹的
rapidCacheConfig.policies映射如下所示："rapidCacheConfig": { "policies": { "us-east1-a": { "rapidCacheId": "us-east1-a", "ingestOnWrite": "unspecified" } "us-east1-b": { ..., ... } } }policies映射中指定的缓存实例必须已存在，前缀级写入时注入才能正常运行。例如，如需在policies映射中指定rapidCacheId: "us-east1-a"，您必须先拥有可用区us-east1-a的缓存。- 您可以在单次 API 调用中更新
policies映射中指定的多个缓存实例。 - 如果
ingestOnWrite设置为enabled，则对于写入此托管文件夹前缀下的存储桶的所有对象，系统都会启用写入时注入功能。只有当缓存资源的ingestOnWrite字段为false时，才能启用前缀级写入时注入。 - 如果设置为
unspecified（默认值），则写入时注入启用状态会从直系父资源（可以是父级托管文件夹，也可以是包含托管文件夹本身的存储桶）继承。 - 政策映射中未指定的任何缓存都将被视为其
ingestOnWrite设置已设置为unspecified。
以下是有关如何配置缓存和受管理的文件夹资源以在存储桶级或前缀级启用或停用写入时注入功能的摘要：
-
启用存储桶级写入时注入功能（但未启用前缀级写入时注入功能）
-
配置：将缓存资源的
ingestOnWrite字段设置为true。 -
行为：为写入存储桶的所有对象启用写入时提取。此存储桶级设置会替换任何受管文件夹级配置（这意味着系统会绕过选择性前缀级配置）。
-
-
启用前缀级写入时注入（但不启用存储桶级写入时注入）
-
配置：
- 将缓存资源的
ingestOnWrite字段设置为false。 - 在受管理的文件夹资源中配置有效的
policies映射（非 null）。 - 将受管理的文件夹的
ingestOnWrite字段设置为enabled（如果它是从已启用的父级受管理的文件夹继承enabled的子文件夹，则将其设置为unspecified）。
- 将缓存资源的
-
行为：仅当写入的对象位于匹配的托管式文件夹前缀下时，才会发生写入时提取。
-
-
在父级托管式文件夹与子级托管式文件夹上启用前缀级写入时注入功能
无法在不启用父级托管式文件夹的写入时注入功能的情况下，为子级托管式文件夹启用该功能。
-
停用存储桶和前缀写入时注入功能
-
配置：
- 将缓存资源的
ingestOnWrite字段设置为false。 -
将所有受管理的文件夹的
ingestOnWrite字段设置为unspecified，确保没有父受管理的文件夹的ingestOnWrite字段为enabled。或者，不配置任何政策，即保留
policies映射null或完全省略rapidCacheConfig配置。
- 将缓存资源的
-
行为：系统会针对相应存储桶和所有前缀全局停用写入时提取。
-
在父级托管式文件夹上启用前缀级写入时注入后，系统会为嵌套在该父级托管式文件夹下的所有子级托管式文件夹启用写入时注入。如需详细了解资源如何继承写入时注入功能的启用和停用状态，请展开写入时注入继承机制的工作原理部分。
写入时注入继承功能的工作原理
如果托管文件夹未明确启用写入时注入（即托管文件夹的 ingestOnWrite 字段设置为 unspecified），则缓存的写入时注入行为会从托管文件夹的父资源（无论是存储桶还是父托管文件夹）继承。
在前缀级使用写入时注入时，您在父级托管式文件夹中配置的写入时注入设置会由所有子级托管式文件夹继承。
例如，设想以下场景：
- 您有一个父级资源为存储桶
my-bucket的代管式文件夹a/。 - 您有一个受管理的文件夹
a/b/，其父资源是my-bucket中的受管理的文件夹a/。
写入名为 a/b/info.txt 的对象时，Rapid Cache 会从上到下评估配置层次结构：
- 检查直接托管文件夹：如果
a/b/设置为enabled，则为写入到a/b/下的对象启用前缀级写入时注入。如果a/b/设置为unspecified，Rapid Cache 会检查直接父资源，即受管理的文件夹a/。 - 检查父级托管文件夹：如果
a/设置为enabled，则为a/和a/b/启用前缀级写入时注入。如果a/设置为unspecified，则 Rapid Cache 会检查父存储桶。 - 检查存储桶的缓存级
ingestOnWrite设置：如果缓存的ingestOnWrite字段设置为true，则表示已启用存储桶级写入时注入，并且该设置会替换任何已配置前缀级写入时注入的受管理文件夹。如果缓存的ingestOnWrite字段为false，并且父托管文件夹和子托管文件夹的ingestOnWrite字段均为unspecified，则对于存储桶中位于父托管文件夹和子托管文件夹下的对象，写入时注入功能处于停用状态。在这种情况下，如果存储桶中没有其他配置了写入时注入的托管文件夹，则系统会为存储桶中的所有对象停用写入时注入。
存留时间 (TTL)
缓存的 TTL 决定了数据在被逐出之前在缓存中保留的时间。TTL 是指数据从上次读取起在缓存中保留的时间。例如，如果 TTL 设置为 24 小时，某一个数据块的上次读取时间是周一上午 11 点，如果在这之后没有发生读取，该数据块将在周二上午 11 点从缓存中逐出。
您可以在创建或更新缓存时设置缓存的 TTL。 您可以将缓存的 TTL 设置为介于 24 小时和 7 天之间（含边界值）的值。如果未指定，TTL 默认为 24 小时。
缓存操作
本部分介绍您可以在 Rapid Cache 缓存上执行的操作。有些操作是异步的，会返回一个长时间运行的操作；其他操作是同步的，操作会立即完成并返回 AnywhereCache 资源。
创建缓存
您可以在创建缓存时设置缓存的位置、TTL 和数据注入行为。在创建过程中，缓存为 CREATING 状态，在运行过程中，缓存为 RUNNING 状态。缓存创建操作最多可能需要 48 小时才能完成，之后操作会超时。
AnywhereCaches Create API 是异步的。创建操作会返回长时间运行的操作。长时间运行的操作会提供创建操作的状态，并且您可以在操作完成之前取消操作。
更新缓存
您可以在更新缓存时设置缓存的 TTL 或数据注入行为。您只能更新处于 RUNNING 状态的缓存。处于 CREATING 或 DISABLED 状态的缓存无法更新。
当缓存正在更新时，pending_update 字段的值为 true。当 pending_update 字段的值为 true 时，缓存无法再次更新。当缓存的 TTL 完成更新后，新的 TTL 会立即应用于缓存中的现有数据和新数据。
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 代表联系，申请增加缓存带宽。在可用缓存带宽短缺期间，您可能会看到存储桶的数据出站流量带宽消耗量有所增加。
问题排查方法：为了在暂时性资源短缺期间获得最佳效果，我们建议您监控缓存，并根据需要停用不必要的缓存或工作负载。