本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
在线迁移期间写入新数据
在线迁移计划的第一步是，确保应用程序写入的任何新数据都存储在两个数据库中，即现有的 Cassandra 集群和 Amazon Keyspaces 中。目标是在两个数据存储中提供一致的视图。您可以通过将所有新的写入内容应用于两个数据库来实现此目的。要实现双写入，请考虑以下三个选项之一。
用于亚马逊密钥空间迁移的 ZDM 双写代理 — 使用 Gith ub 上提供的适用于亚马逊密钥空间的 ZDM 代理
，您可以在不停机应用程序的情况下将 Apache Cassandra 工作负载迁移到亚马逊密钥空间。此增强型解决方案实施了 Amazon 最佳实践并扩展了官方 ZDM 代理功能。 -
在 Apache Cassandra 和亚马逊 Keyspaces 之间执行在线迁移。
-
无需重构应用程序即可同时向源表和目标表写入数据。
-
通过双读操作验证查询。
该解决方案提供了以下增强功能，可 Amazon 与亚马逊密钥空间配合使用。
-
容器部署 — 使用来自亚马逊弹性容器注册表 (Amazon ECR) 的预配置 Docker 镜像进行 VPC-accessible 部署。
-
基础架构即代码 — 使用 Amazon CloudFormation 模板进行部署，实现自动设置 Amazon Fargate。
-
亚马逊密钥空间兼容性 — 访问包含亚马逊密钥空间自定义改编版的系统表。
该解决方案在带有 Fargate 的 Amazon ECS 上运行，可根据您的工作负载需求提供无服务器可扩展性。网络负载均衡器将传入的应用程序流量分配到多个 Amazon ECS 任务中，以实现高可用性。
-
应用程序双重写入 - 您可以使用现有的 Cassandra 客户端库和驱动程序实现双重写入，将对应用程序代码的更改降至最少。您可以在现有应用程序中实现双重写入，也可以在架构中创建新层来处理双重写入。有关更多信息以及展示如何在现有应用程序中实现双重写入的客户案例研究，请参阅 Cassandra 迁移案例研究
。 在实现双重写入时，可以将一个数据库指定领导设备，将另一个数据库指定为跟随设备。如此，您就可以继续写入原始源数据库或领导数据库，而不会让跟随数据库或目标数据库的写入失败中断应用程序的关键路径。
您可以使用 Amazon Simple Queue Service 在死信队列（DLQ）中记录失败的写入操作，而不必重试跟随设备的写入失败操作。DLQ 让您可以分析跟随设备的写入失败操作，并确定目标数据库中处理未成功的原因。
对于更复杂的双写入实现，您可以遵循 Amazon 最佳实践，使用 s aga 模式设计本地事务序列。saga 模式可确保，如果事务失败，则 saga 将运行补偿事务，以恢复先前事务所做的数据库更改。
使用双重写入进行在线迁移时，可以按照 saga 模式配置双重写入，让每次写入都是本地事务，从而确保跨异构数据库使用原子操作。有关使用推荐的设计模式设计分布式应用程序的更多信息 Amazon Web Services 云，请参阅云设计模式、架构和实现。
消息收发层双重写入 - 您可以使用现有的消息收发层对 Cassandra 和 Amazon Keyspaces 执行双重写入操作，而不是在应用程序层实现双重写入。
为此，您可以为消息收发平台配置一个额外的使用者，以便向这两个数据存储都发送写入内容。这种方法提供了一种简单的低代码策略，使用消息收发层在两个数据库中创建两个最终会一致的视图。