选择您的 Cookie 首选项

我们使用必要 Cookie 和类似工具提供我们的网站和服务。我们使用性能 Cookie 收集匿名统计数据,以便我们可以了解客户如何使用我们的网站并进行改进。必要 Cookie 无法停用,但您可以单击“自定义”或“拒绝”来拒绝性能 Cookie。

如果您同意,AWS 和经批准的第三方还将使用 Cookie 提供有用的网站功能、记住您的首选项并显示相关内容,包括相关广告。要接受或拒绝所有非必要 Cookie,请单击“接受”或“拒绝”。要做出更详细的选择,请单击“自定义”。

在线迁移期间写入新数据

聚焦模式
在线迁移期间写入新数据 - Amazon Keyspaces(Apache Cassandra 兼容)

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

在线迁移计划的第一步是,确保应用程序写入的任何新数据都存储在两个数据库中,即现有的 Cassandra 集群和 Amazon Keyspaces 中。目标是在两个数据存储中提供一致的视图。您可以通过将所有新的写入内容应用于两个数据库来实现此目的。要实现双重写入,请考虑使用以下两个选项之一。

  • 应用程序双重写入 - 您可以使用现有的 Cassandra 客户端库和驱动程序实现双重写入,将对应用程序代码的更改降至最少。您可以在现有应用程序中实现双重写入,也可以在架构中创建新层来处理双重写入。有关更多信息以及展示如何在现有应用程序中实现双重写入的客户案例研究,请参阅 Cassandra 迁移案例研究

    在实现双重写入时,可以将一个数据库指定领导设备,将另一个数据库指定为跟随设备。如此,您就可以继续写入原始源数据库或领导数据库,而不会让跟随数据库或目标数据库的写入失败中断应用程序的关键路径。

    您可以使用 Amazon Simple Queue Service 在死信队列(DLQ)中记录失败的写入操作,而不必重试跟随设备的写入失败操作。DLQ 让您可以分析跟随设备的写入失败操作,并确定目标数据库中处理未成功的原因。

    对于更复杂的双重写入实现,您可以遵循 AWS 关于使用 saga 模式设计一系列本地事务的最佳实践。saga 模式可确保,如果事务失败,则 saga 将运行补偿事务,以恢复先前事务所做的数据库更改。

    使用双重写入进行在线迁移时,可以按照 saga 模式配置双重写入,让每次写入都是本地事务,从而确保跨异构数据库使用原子操作。有关使用 AWS Cloud推荐的设计模式设计分布式应用程序的更多信息,请参阅云设计模式、架构和实施

    从 Apache Cassandra 迁移到 Amazon Keyspaces 时,在应用程序层实现双重写入。
  • 消息收发层双重写入 - 您可以使用现有的消息收发层对 Cassandra 和 Amazon Keyspaces 执行双重写入操作,而不是在应用程序层实现双重写入。

    为此,您可以为消息收发平台配置一个额外的使用者,以便向这两个数据存储都发送写入内容。这种方法提供了一种简单的低代码策略,使用消息收发层在两个数据库中创建两个最终会一致的视图。

隐私网站条款Cookie 首选项
© 2025, Amazon Web Services, Inc. 或其附属公司。保留所有权利。