我一直在寻找 DynamoDB 来创建接近事务的东西。我正在观看此视频演示：https://www.youtube.com/watch?v=KmHGrONoif4，其中演讲者在 30 分钟左右展示了使 dynamodb 操作尽可能接近 ACID 的方法。他展示了最好的概念是使用 dynamodb 流，但没有展示演示或示例。我正在查看一个非常简单的场景，那就是我有一个名为 USERS 的表。每个用户都有一个朋友列表。如果两个用户不再希望成为朋友，则必须从两个用户的实体中删除他们（我无法承受从一个实体中删除一个朋友，例如由于崩溃，第二个用户实体的朋友属性是未更新导致数据不一致）。我想知道是否有人可以提供一些简单的演练哦，如何完成这样的事情，看看它是如何工作的？如果可以提供代码，看看它是如何工作的会很棒。
干杯！
【问题讨论】：
标签： amazon-web-services amazon-dynamodb fault-tolerance dynamo-local
这是他所指的事务库：https://github.com/awslabs/dynamodb-transactions 你可以通读设计：https://github.com/awslabs/dynamodb-transactions/blob/master/DESIGN.md
这是 Kinesis 客户端库： http://docs.aws.amazon.com/kinesis/latest/dev/developing-consumers-with-kcl.html
当您写入 DynamoDB 时，您可以获得一个输出流，其中包含在表上发生的所有操作。 Kinesis 客户端库可以使用和处理该流。
在您的情况下，让您的客户将其从第一个用户中删除，然后从第二个用户中删除。在 Kinesis 客户端库中，当您使用流并看到用户被删除时，请查看他的朋友并在需要时检查/删除 - 如果需要，删除可能应该通过相同的方式完成。这不是真正的事务，它依赖于 KCL 保证将处理来自流的记录这一事实。
为了增加这种混淆，KCL 使用 Dynamo 在处理时存储流中的位置并检查点处理的记录。
【讨论】：
您应该尽量减少对事务的需求，这在小范围内是一个不错的概念，但一旦您变得非常成功并且需要支持数百万和数十亿条记录，就无法真正扩展。
如果您以 NoSQL 思维模式思考，则可以考虑使用稍微不同的数据模型。一个简单的例子是在“friend-with”属性的单个表上使用Global Secondary Index。当您与一对朋友添加单个记录时，记录和索引都将在单个操作中更新。当您删除友谊记录时，表和索引都将在单个操作中更新。
如果你选择使用Updates Stream机制或者全局二级索引，你应该考虑分布式系统的“最终一致性”情况。一致性可以在几毫秒内实现，但也可能需要更长的时间。您应该分析业务影响以及可以采取的技术措施来解决它。例如，您可以在将记录呈现给用户之前验证两条记录（主表和索引，如果您在索引中找到它）是否存在。
【讨论】：