写入任何区域模式(非主模式) - AWS 规范性指导

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

写入任何区域模式(非主模式)

下图所示,写入任何 Re gion 的写入模式都是完全主动-主动的,并且对可能发生写入操作的位置没有限制。任何地区都可以随时接受写入请求。这是最简单的模式;但是,它只能用于某些类型的应用程序。此模式适用于所有 MRSC 表。当所有写入操作均为等性时,它也适用于 MREC 表。Edempoten t 意味着它们可以安全地重复,因此跨区域的并发或重复写入操作不会发生冲突,例如,当用户更新其联系人数据时。它也适用于仅限追加的数据集,在该数据集中,所有写入操作都是在确定性主键下的唯一插入,这是等性的一种特殊情况。最后,此模式适用于可以接受写入操作冲突风险的 MREC。

DynamoDB 全局表中没有主写入模式。

写入任何区域模式是实现起来最简单的架构。路由更容易,因为任何区域都可以随时成为写入目标。故障转移更容易,因为使用 MRSC 表时,项目始终保持同步,而使用 MREC 表,任何最近的写入操作都可以任意次数重播到任何辅助区域。在可能的情况下,您应该针对这种写入模式进行设计。

例如,一些视频流媒体服务使用全局表来跟踪书签、评论、观看状态标志等。这些部署之所以使用 MREC 表,是因为它们需要分散在世界各地的副本,每个副本都提供低延迟的读取和写入操作。这些部署可以使用写入任何区域模式,前提是它们确保每个写入操作都是均等的。如果每次更新(例如,设置新的最新时间码、分配新的评论或设置新的观看状态)都会直接分配用户的新状态,而项目的下一个正确值不取决于其当前值,则会出现这种情况。如果偶然将用户的写入请求路由到不同的区域,则最后一次写入操作将持续下去,全局状态将根据上次分配确定。此模式下的读取操作最终将保持一致,并延迟最新ReplicationLatency值。

在另一个例子中,一家金融服务公司使用全局表作为系统的一部分,以持续统计每位客户的借记卡购买情况,从而计算该客户的现金返还奖励。他们想为每位顾客保留一RunningBalance件物品。这种写入模式自然不是等效的,因为当交易流入时,它们会使用ADD表达式来修改余额,其中新的正确值取决于当前值。通过使用 MRSC 表,他们仍然可以写入任何区域,因为每次ADD调用总是针对项目的最新值进行操作。

第三个例子涉及一家提供在线广告投放服务的公司。该公司认为,为了简化写入任何区域模式的设计,低数据丢失风险是可以接受的。当他们投放广告时,他们只有几毫秒的时间来检索足够的元数据来确定要展示哪个广告,然后记录广告展示次数,这样他们就不会很快重复同样的广告。他们使用全局表为世界各地的最终用户提供低延迟读取操作和低延迟写入操作。它们会在单个项目中记录用户的所有广告展示次数,该项目以不断增长的列表表示。他们使用一个项目而不是追加到项目集合,因此他们可以在每次写作操作中删除较旧的广告展示次数,而无需为删除操作付费。这种写入操作不是等效的;如果同一个最终用户大约同时看到在多个区域投放的广告,则一个广告展示的写入操作有可能覆盖另一个广告展示的写入操作。风险在于,用户可能会偶尔看到重复的广告。他们认为这是可以接受的。