使用 Speech-to-Text 进行生产就绪实时音频转录的架构

本指南介绍了使用 Google Cloud 技术(包括 Speech-to-TextGoogle Kubernetes Engine (GKE)Memorystore)提供高可用性、弹性实时音频转录的架构。本指南面向开发者和架构师,并假定您掌握了 Kubernetes 和 GKE 的基础知识。如果您需要快速了解,请参阅 GKE 概览

如需使用此架构的实现,请参阅相关教程

简介

有多种使用场景需要将实时音频流转录为文本。在直播时,媒体组织可以即时转录音频以生成字幕。可以实时转录电话或会议,以帮助有听力障碍的参与者。在会议和活动中,组织者可以安排转录实时演讲内容,以便向出席者显示文本。

目前使用的大部分实时转录解决方案都依赖熟练的人类操作员和专业软件。由于该过程依赖于人类操作员,因此扩缩转录工作可能比较困难。也就是说,通常只能针对少量直播或现场活动进行转录。

Speech-to-Text 支持实时转录。您可以向 Speech-to-Text 提供音频流,然后 Speech-to-Text 实时返回文本转录流。借助 Speech-to-Text,媒体组织可以自动执行并扩充其现有的转录过程,从而减少对人类操作员的依赖,并扩大转录活动的范围。

对于依赖于转录的用户来说,传送的质量、延迟时间和一致性是关键因素。在直播或现场活动涉及转录时尤其如此。频繁出现延迟或丢包会导致用户体验非常糟糕,用户因而心生不满和抱怨。因此,任何转录解决方案都需要提供高质量的文本转录。同时还需要具备高可用性和弹性,从而将故障和中断对转录传送造成的干扰降至最低。本指南介绍了一种符合解决方案关键要求(即提供高可用性、可靠的实时音频转录)的应用架构。

架构

Google Cloud 上适用于生产就绪转录应用的基础架构

该架构包含以下功能:

  • 三个应用微服务:
    • Ingestor。此服务使用源音频流。
    • Transcriber。此服务调用 Speech-to-Text 并发出转录结果。
    • Reviewer。此服务在 Web 应用中显示转录以供审核。
  • GKE,用于托管跨多个区域的地区级 GKE 集群内的应用微服务。应用微服务是跨区域部署的。
  • Memorystore for Redis,用作快速的中间存储。它部署在高可用性配置中。
  • 向互联网公开应用功能以便执行以下操作的负载平衡器:
    • 提供源音频流可以定向到的 IP 地址。
    • 提供审核器 Web 应用。

要求和建议概览

本部分列出了示例来介绍提供实时转录功能的应用要求以及满足要求的建议。除非另有说明,否则这些建议将在后面的部分进行更深入的探讨。

要求 建议
架构应该为灵活、松散耦合的架构。 将应用设计为一组独立的容器化微服务。使用 GKE 管理和编排微服务。
架构在单个地区内必须具备高可用性。 使用地区级 GKE 集群以冗余方式跨区域部署应用微服务。
应用必须提供稳定的 IP 地址供提取操作使用。 Ingestor 服务部署为 LoadBalancer 类型的 Kubernetes 服务
应用必须为人类操作员提供转录审核机制。 提供一个实时显示转录的 Web 应用。(本文档未详细介绍此要求。)
必须实时转录音频。 使用 Speech-to-Text 流式传输识别请求。
应用应该保持一个活跃的 Speech-to-Text 连接。 使用领导者选举模式来选择单个 Transcriber Pod 作为主实例。
端到端转录必须以较短的延迟时间执行。 使用 Memorystore for Redis 实现快速的内存过渡存储。
应在理解语音上下文(例如已知领域词汇)的情况下进行转录。 使用语音自适应为 Speech-to-Text 提供字词和短语提示。
应用应该能够处理多个并发输入音频流(频道)。 为每个频道部署单独的 Transcriber 实例。考虑跨频道共享其他应用资源。
应用应该在发生故障时恢复运行,同时将对转录造成的干扰降至最低。 使用领导者选举模式、冗余部署和负载平衡器,帮助提供弹性。通过引入故障来测试应用的弹性。

将应用设计为一组容器化微服务

将应用设计为一组松散耦合的独立组件或服务是一种架构最佳做法。通过采用松散耦合的设计,您可以单独管理每项服务的生命周期。服务可由不同的团队构建和管理。每个团队都可以选择最合适的技术,而不受其他团队选择的约束。这些优势是微服务架构模式的核心。

微服务架构通常会将服务打包为容器。基于服务的应用最适合使用容器,因为您可以对每个容器进行运行状况检查,限制每项服务只能使用特定的资源,以及独立启动和停止每项服务,不会相互干扰。将应用构建为一组容器也有助于提高效率、提供可移植性和一致性等。

有时,确定如何将应用拆分成各个微服务以及在何处拆分是一个复杂的决定过程。但是,对于此转录应用而言,下表列出了一些明确的责任划分。

微服务 说明
Ingestor 使用源音频流并写入过渡存储空间。

音频可能会通过第三方软件和网域专用协议进行传送,并且可能还会进行加密。因此,独立于转录组件设计和部署提取组件很合理。
Transcriber 使用提取的音频、调用 Speech-to-Text,以及将转录结果写入过渡存储空间。

Transcriber 服务是应用的核心。它负责管理和保持与 Speech-to-Text 的连接以及处理转录结果。
Reviewer 使用转录并在 Web 应用中显示转录以供审核。

通常,媒体组织会要求人类操作员检查生成的转录。为满足此要求,Reviewer Web 应用可让您先修改转录,然后再将其发送到下游用于广播。

使用 GKE 托管应用微服务

GKE 非常适合用于托管容器化应用。首先,GKE 集群由 Kubernetes 提供支持,后者具有以下优势:

  • Kubernetes 提供了一个云原生平台,用于管理和编排松散耦合的容器化应用。
  • Kubernetes 可让您对集群进行声明式管理,以便对您的设置进行版本控制,使其易于复制。
  • Kubernetes 是开源的,能够提供可移植性。

其次,GKE 是一项全代管式服务,可提供高级集群管理功能,其中包括以下功能:

  • 自动扩缩集群的节点实例数量。
  • 自动升级集群的节点软件。
  • 与其他 Google Cloud 服务(包括负载平衡器、VPC 网络、数据库以及日志记录和监控)紧密集成。
  • 地区级集群,可在一个地区中的多个区域间提供冗余从而提高可用性。

如需详细了解如何在生产环境中使用 GKE,请参阅针对生产用途准备 GKE 环境指南。

以冗余方式部署应用微服务以提高可用性

传送转录时出现丢包和间歇性问题可能会让依赖转录的用户感到沮丧。为了实现可靠的转录传送,应用必须能够应对中断或错误。

可用性用于衡量系统的正常运行时间。在 Google Cloud 中,通常通过将应用服务冗余部署到多个区域来实现高可用性。如果某服务存在于多个区域中,则它可以更好地应对特定区域中的服务中断。

与部署到单个地区相比,将应用部署到多个地区可提高可用性。但是,多地区应用会施加其他限制(例如要求复制数据),因此可能需要进行仔细设计和管理。对于此转录应用而言,将应用部署到单个地区内的多个区域便能提供足够的可用性。

使用地区级 GKE 集群配置

GKE 提供选项供您选择如何将集群分布在一个地区内的多个区域中。您可以使用以下选项:

  • 单区域集群。所有集群节点都位于一个区域中。在该区域中有一个运行的控制层面(Kubernetes 主服务器)。单区域集群不适合用于转录应用,因为您希望应用可以跨区域使用。
  • 多区域集群。集群节点分布在一个地区内的两个或更多区域中。主要区域中有一个运行的 Kubernetes 控制层面。
  • 地区级集群。集群节点分布在一个地区内的两个或更多区域中。地区级集群有多个控制层面副本,这些副本在地区内的多个区域中运行。

Transcriber 服务使用 Kubernetes 领导者选举模式(稍后介绍)来帮助管理与 Speech-to-Text 的通信。使用领导者选举模式时,需要与 Kubernetes 控制层面交互。为了最大限度地提高领导者选举过程的有效性,请务必在多个区域中提供控制层面。因此,地区级集群是转录应用的合理选择。

跨区域部署应用微服务

地区级 GKE 集群包含计算节点以及在特定地区的多个区域中运行的控制层面副本。借助 Kubernetes Deployment 对象,您可以采用冗余方式部署多个微服务副本,Kubernetes 默认情况下将尝试在每个区域的各个节点之间均匀分布副本。

Deployment 表示一组多个相同的 Pod。Deployment 由 Kubernetes Deployment 控制器管理。如果副本发生故障或无响应,则控制器会自动替换副本。通过这种方式,Deployment 可帮助确保应用微服务的一个或多个实例可用于处理请求。

您可以创建 Deployment,使其至少分别包含以下每个微服务的两个副本:IngestorTranscriberReviewer。这样一来,每个微服务将在多个区域中以冗余方式提供。

提供稳定的 IP 地址以便使用负载平衡的 Service 提取音频

源音频流可能来自包含专用软硬件的本地基础架构。转录应用应该提供稳定的目标 IP 地址来接收音频,以便源基础架构不需要频繁重新配置。但是,Deployment 中的 Pod 可以随时加入和退出,而且它们的 IP 地址也不是固定的。如需为 Deployment 分配稳定的 IP 地址,您需要创建 Kubernetes Service

Kubernetes Service 对象提供了一种将一组 Pod 公开为单个资源的方法。Service 会获得单个稳定的 IP 地址,客户端可以使用该 IP 地址访问 Pod。Service 类型控制 Service 向内部和外部流量公开的方式。例如,当您创建 LoadBalancer 类型的 Service 时,GKE 会在您的项目中自动创建关联的 Google Cloud 负载平衡器。如需了解如何将不同类型的负载平衡与 Service 搭配使用,请参阅 GKE 网络概览

应用部署在单个地区中,可能需要支持使用非 HTTP 协议传送的音频流。因此,外部地区级 TCP/UDP 网络负载平衡器似乎是 Ingestor 服务的良好起点。此负载平衡器具有可从互联网访问的稳定外部 IP 地址,并且可以在可用的 Ingestor Pod 之间分发流量。

使用流式传输识别实时转录音频

Speech-to-Text 使用流式传输识别请求支持实时转录。流式传输识别使用 Speech-to-Text 建立双向 gRPC 流;您可以在请求流中发送音频,然后在响应流中以异步方式接收转录结果。

以下指南可帮助您从 Speech-to-Text 获得最佳结果:

  • 使用客户端库,用于简化与 Speech-to-Text 的交互。例如,客户端库将 gRPC 通信抽象化,从而让您专注于业务逻辑。
  • 如需详细了解如何对源音频进行采样和编码,请遵循最佳做法建议和优化指南
  • 设置临时结果标志。此标志指示 Speech-to-Text 在生成不确定的转录时就返回转录,而不是等待最终结果。如果您有连续的音频流,则此标志非常有用。
  • 对其他可能与您的使用场景相关的配置选项进行实验。例如,自动加注标点符号字词级置信度讲话人区分等功能可能会提供其他有用的结果。(上述所有功能并非都适用于所有语言。如需了解某项功能是否适用于您的语言,请参阅支持的功能页面。)

使用领导者选举模式以便与 Speech-to-Text 进行有状态的交互以及实现高效的故障转移

使用 Speech-to-Text 建立的双向流式传输连接是有状态的,因为在接收后续的音频数据块时,Speech-to-Text 返回的临时转录结果可能会不断改进。因此,音频数据应该通过单个长期有效的连接发送。

但是,为了提高可用性,Transcriber 服务的 Pod 将以冗余方式部署在地区的多个区域中。因此,您需要一种强大的机制以将其中一个 Pod 指定为主要 Pod。只有主要 Pod 会使用队列中的音频数据并将其发送到 Speech-to-Text;其他 Pod 充当热备用 Pod 以用于故障转移。这称为领导者选举模式。

Kubernetes Go 客户端提供领导者选举实现及其用法示例。候选流程通过竞争获取由 Kubernetes 控制层面管理的锁。一个流程会获取该锁,并在规定的时间段内被选为主要流程。主要流程会不断发送检测信号以将其身份保持为主要流程,而其他候选流程会定期进行新的尝试以争取成为主要流程。如果主要流程未在规定的时间范围内保持其身份,则系统会选择其他候选流程之一作为主要流程并向其授予该锁。

在此应用中使用领导者选举模式有助于在发生故障或中断时最大限度地降低转录传送的延迟时间。使用领导者选举模式时,如果当前的主要 Pod 出现故障,则其他 Pod 将等待恢复转录,因此您无需等待 Kubernetes 部署新的 Pod。

领导者选举配置使用的集群资源比单个 Pod 配置多,因为非主要 Pod 通常处于空闲状态。但是,对于延迟时间敏感型转录应用,增加的费用是合理的。

领导者选举逻辑可以作为 Sidecar 容器部署在每个 Transcriber Pod 中。这有助于分隔领导者选举逻辑和核心转录逻辑。

如需详细了解 Kubernetes 领导者选举模式,请参阅 Kubernetes 博客上简单的 Kubernetes 和 Docker 领导者选举模式

使用 Memorystore 提供快速过渡存储空间

将应用部署为一组松散耦合的微服务,可以提高架构的灵活性。但是,这也意味着您需要一种传递机制以将数据从一个层传递到另一个层。

对于实时转录使用场景,延迟时间和处理顺序都是关键要求。由于转录是实时进行的,因此通过应用快速移动数据并尽可能减少任何可能增加转录延迟时间的操作非常关键。此外,音频数据块采用正确的顺序进行处理同样非常关键,否则转录可能会不完整或不准确。

Memorystore for Redis 提供一个快速内存存储,以用于需要实时处理数据的使用场景。Memorystore 非常适合转录应用,原因如下:

  • 快速:数据存储在内存而不是磁盘上。与内存交互的效率远比与磁盘交互高。
  • 灵活:Redis 提供有用的数据结构和命令,用于存储和处理数据。另外还有许多 Redis 客户端库
  • 开放:Memorystore for Redis 与开源的 Redis 完全兼容。
  • 全代管式:Memorystore 是一项全代管式服务,可让您专注于应用而无需管理基础架构。
  • 可用性高标准层级中的 Memorystore for Redis 实例可跨区域自动复制,并且其运行状况受到监控。它们还能够进行快速自动故障转移。如需了解详情,请参阅高可用性文档。

将 Memorystore for Redis 用作可靠的队列

Redis 列表经常用作有序队列。对于此转录应用,假设您按顺序接收源音频数据。因此,Ingestor 服务可以将音频数据写入命名队列,而 Transcriber 服务可以使用该队列中的资源。Redis 提供功能类似如下的命令:允许 Transcriber 服务有效地进行屏蔽,直到队列中有数据为止。

由于 Speech-to-Text 以异步方式返回流式传输结果,因此在发生故障时,您必须谨慎操作以便最大限度地降低转录损失。例如,您可以再使用一个 Redis 队列临时复制发送到 Speech-to-Text 的音频的最后 N 秒。如果发生故障,并且新的 Transcriber Pod 被选为主要 Pod,则新的主要 Pod 可以读取第二个队列并将之前收到的音频发送到 Speech-to-Text,然后 Speech-to-Text 从主要队列开始处理该音频。Redis BRPOPLPUSH 命令提供了一种原子化方式,用于从一个列表读取数据并将数据添加到另一个列表,其通常用于类似于本场景的可靠的排队使用场景。请注意,此方法可能会导致出现重复的转录片段。转录的下游使用者必须管理任何潜在的重复项。(本文档未介绍潜在重复项的管理任务。)

将 Pub/Sub 评估为 Memorystore 的替代方案

Pub/Sub 是一个可扩缩、可用性高且持久的事件提取和传送系统。Pub/Sub 提供延迟时间较短的异步消息传递功能,可将发送者和接收者分隔开来。Pub/Sub 通常用于将事件和数据从应用的一个部分传递到另一个部分。

对于转录应用,您可以使用 Pub/Sub 作为 Memorystore 的替代方案。例如,您可以使用 Pub/Sub 将提取的音频发布到 Transcriber 服务使用的订阅,而不是将音频数据存储在 Redis 中以供 Transcriber 服务读取。

Pub/Sub 提供以下功能:

  • 覆盖全球
  • 扩缩能力极强
  • 通过搜索功能轻松重放消息,此功能可用于恢复应用
  • 无服务器部署,这意味着您只需按使用量付费

但是,Pub/Sub 也具有以下限制:

  • 消息传送的顺序不一定正确。
  • Pub/Sub 至少传送一次功能可能会多次传送消息,这意味着可能会发生重复现象。
  • Pub/Sub 将消息写入存储空间,这可能会增加延迟时间。

根据您的使用场景,您可以忽略或设法应对上述列表中的限制,并且 Pub/Sub 可以提高效率。您应评估这两种技术,以确定哪种技术最适合您的情况。

使用语音自适应为 Speech-to-Text 提供转录提示

遵循本文档中列出的指南有助于 Speech-to-Text 提供准确的结果。如需进一步提高转录准确率,您可以使用语音自适应为 Speech-to-Text 提供额外的上下文信息。

借助语音自适应功能,当您向 Speech-to-Text 发送转录请求时,可以添加一系列字词和短语以用作提示。这些提示有助于 Speech-to-Text 从您的音频数据中识别指定的短语。例如,如果您的实时音频流中有人谈论天气,那么添加与天气相关的常用字词可能会提高转录的准确率。

对于生产使用场景,您可能希望创建可按需检索的提示字典。例如,如果应用正在为电视天气预报实时生成字幕,则可以检索您之前创建的天气术语字典。但是,如果更改为播放高尔夫球,则应用可以检索高尔夫球术语以及球员姓名的字典。

对于高级使用场景,该字典可以实时更新。经过训练的人工审核者可监控输出转录并即时对字典进行修改。Transcriber 服务可以监听字典更改的事件通知,提取更新后的字典并在后续连接 Speech-to-Text 时使用。

为每个源音频流创建一个单独的转录器 Deployment

广播电台/电视台通常运营多个频道,它们可能想要同时为多个频道生成转录。每个频道表示不同的源音频流。您的应用必须为要转录的每个频道保持一个单独的 Speech-to-Text 连接。具体方法有多种。

一种方法是直接在 Transcriber 逻辑中管理频道集。这种方法可简化 GKE 集群,因为集群中只有一个 Transcriber Deployment。但是,这种方法会增加转录逻辑的复杂性,因为它必须维护和管理一组活跃频道和连接。此外,通过此方法,您对每个频道使用不同的配置(例如,不同的提示字典或不同的优先级)变得更具挑战性,因为所有频道都在单个 Deployment 中运行。

一种更好的方法可能是为每个频道创建一个不同的 Transcriber Deployment。这样做可简化应用逻辑,因为每个 Transcriber 实例管理一个 Speech-to-Text 流式传输连接。此方法具有其他优势,例如:

  • 灵活性:您可以创建包含每个频道的不同配置的 Deployment。例如,与标准频道相比,高级频道可能需要提供更多集群资源。
  • 隔离:您可以将每个转录频道视为一个单独的实体。
  • 资源效率:与管理单个大型 Deployment 相比,Kubernetes 可以采用更佳方式在集群资源上分发多个较小的 Transcriber Deployment。

使用标签或命名空间按频道对资源进行分组

Kubernetes 提供了一些功能对相关资源进行分组。您可以使用这些功能为每个频道分隔集群资源,如下所示:

  • 标签是附加到 Kubernetes 集群中的对象(例如 Pod)的键值对。您可以使用标签来组织和选择对象子集。
  • 命名空间是一种划分集群资源的方法。您可以将命名空间视为 Kubernetes 集群内的虚拟集群。单个 Kubernetes 集群可以有多个命名空间,各命名空间在逻辑上彼此隔离。

使用标签和命名空间,您可以部署为特定频道单独配置的 Transcriber 实例。标签提供了一种快速、简便的资源分组方法。命名空间提供了更正式的分隔方法。如果您想控制每个频道使用的集群资源,或者这些频道由不同的团队管理,则标签和命名空间是不错的选择。

跨源音频流共享资源

如上一部分所述,为每个源音频频道创建一个不同的 Transcriber 实例有诸多好处。根据转录应用的要求,您还可以为每个频道创建不同的 IngestorReviewer Deployment。如果以下任何限制条件适用,则此方法可能会比较合理:

  • 整个应用的每个频道都需要高度隔离。例如,每个频道都由一个单独的团队管理。
  • Ingestor 服务使用的第三方软件无法轻松处理多个数据流。
  • Reviewer 应用的每个频道都具有自定义行为。

但是,选择松散耦合架构的一个好处是能够为每个服务选择不同的扩缩和部署策略。如果上述列表中的限制条件不适用,则在多个频道之间共享 IngestorReviewer 服务可能会有效率。例如,在单个 Deployment 中处理多个频道具有以下优势:

  • Kubernetes Service 可以公开多个端口,每个频道都可以定位不同的端口。然后,IngestorReviewer 服务可以分别提供一个负载平衡器,从而提供一个跨频道使用的外部 IP 地址。这有助于降低费用和管理开销。
  • 同样,最好是尽量减少应用公开的外部 IP 地址数量。
  • 您可以使用自动扩缩功能,根据频道的在线和离线来扩缩 Deployment。

共享 Memorystore for Redis

资源共享注意事项也同样适用于 Memorystore for Redis。为每个频道创建一个单独的 Memorystore 实例可以分隔频道,但是会增加费用和管理开销。

Redis 是专为高吞吐量设计的,因此,为每个频道创建一个专用的 Memorystore 实例可能造成资源使用效率不佳。如果您需要明确分隔频道,则可以在 GKE 集群中运行 Redis 作为 Memorystore 的替代方案。在此方法中,您可以为集群中的每个频道创建一个 Redis Deployment。但是,您需要自行负责管理 Redis,并且在高可用性配置中运行 Redis 颇具挑战性。如需详细了解如何在 Kubernetes 中运行 Redis,请参阅“示例:使用 Redis 部署 PHP Guestbook 应用”

如前所述,Memorystore for Redis 设计为提高性能,并且一个实例应该能够同时为多个并发频道提供服务。另请注意,Memorystore for Redis 可以扩缩,以根据需要添加或移除容量。通过这种方式,您可以跨频道共享单个 Memorystore 实例,并根据需要扩大或缩小实例。如果您要跨频道共享 Memorystore 实例,则可以使用频道标识符作为 Redis 密钥的前缀。

通过引入故障来测试应用的弹性

弹性是正式版转录应用的关键要求。如果发生故障或中断,应用应快速恢复执行转录操作,同时尽量减少转录损失。

本文档中介绍的架构包含多个有助于提高弹性的功能:

  • 如果当前的主要 Pod 发生故障,则 Transcriber 服务会使用领导者选举模式高效地通过故障转移机制来启用热备用 Pod。
  • 应用使用 Redis 可靠的排队功能,以便在发生故障时最大限度减少数据丢失。
  • 该架构包括具有关联负载平衡器的 Kubernetes Service。Google Cloud 负载平衡器包含运行状况检查,用来验证底层计算节点的运行状况是否良好。
  • 应用服务跨区域以冗余方式进行部署,这有助于防范发生区域性故障。
  • 每个应用服务都是一个 Kubernetes Deployment,用于指定所需的 Pod 副本数量。如果 Pod 崩溃或被删除,则 Kubernetes 会自动重新创建该 Pod,使配置的副本数量得到满足。
  • 标准层级中的 Memorystore for Redis 实例可跨区域自动复制,并且其运行状况受到监控。它们还能够进行快速自动故障转移。

无法测试可能出现的每个错误或中断,但您仍可通过引入故障并检查结果来详细了解您的应用。定义目标和预期对测试弹性和恢复而言至关重要。在某些使用场景中,也许可以接受一定程度的转录损失。其他使用场景可能严格要求最大程度地减少任何转录损失。提前定义恢复目标有助于衡量实现这些目标的进度。

对故障模式的完整讨论不在本文的讨论范围内。以下各部分介绍了您可以执行以帮助评估应用弹性的一些基准测试。

删除 Kubernetes Pod

在应用中引入故障的一种方法是从 GKE 集群中删除 Kubernetes Pod,这是混沌工程的一种形式。一种简单方法是编写自定义脚本,用于以某个时间间隔随机删除 Pod。此外,有许多第三方工具可以在 Kubernetes 集群上执行混沌测试。删除 Pod 后,您应该系统性地测试每个应用服务的行为。

针对 Memorystore 执行手动故障转移

Memorystore for Redis 标准层级实例通过复制和自动故障转移提供高可用性。为了应对区域故障,主实例和副本要位于同一地区的不同区域中。当 Redis 主实例发生故障时进行故障转移。

Memorystore 故障转移会影响应用的以下几个方面:

  • 系统在主实例发生故障而启用副本时,Memorystore for Redis 的现有连接会断开。但是,一旦重新连接,您的应用即会使用相同的连接字符串或 IP 地址自动重定向到新的主实例。
  • 虽然 Memorystore for Redis 服务会将副本提升为主实例,但您的 Memorystore for Redis 实例暂时不可用。

要测试应用在这些条件下的行为方式,您可以启动手动故障转移。故障转移通常会导致一定程度的数据丢失。您应该衡量丢失程度,并根据您的使用场景确定相应的最佳处理方式。

后续步骤