当多个 DynamoDB 客户端删除特定项目时，每个客户端（如何）确定其 DeleteItem 调用是否有意义？

Question

当 DynamoDB 客户端对某个项目调用 DeleteItem 时，它可以使用ReturnItems 请求参数在响应中获知该项目的预删除内容：https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_DeleteItem.html#DDB-DeleteItem-request-ReturnValues

当 2 个或多个客户端同时删除同一个项目时，他们是否可以使用此参数来确定他们中的哪个真正删除了该项目，从而哪些客户端拨打了不是 严格必要？换句话说，使用此参数，只有一个客户端会在 DeleteItem 响应中看到项目的内容，而所有其他客户端将看到不包含项目内容的响应——允许他们正确推断出他们没有实质性删除项目？

我相信众所周知，在正常操作中，写入 DynamoDB 需要来自分区中 3 个存储节点中的 2 个的确认。我找不到任何正式或其他形式的文档，其中提到了删除的等效保证；虽然我当然可以明白为什么会是一样的。

鉴于提到更新被视为先删除然后是放置（https://en.wikipedia.org/wiki/Amazon_DynamoDB#Query_execution：“当日志传播器接收到更新操作时，它会向所有索引发出删除操作和放置操作”），我会很高兴地相信删除字面上被视为与写入相同的基本保证。

如果删除确实需要来自 3 个存储节点中的 2 个的确认，那么在重大系统故障情况之外，我认为我可以安全地使用 ReturnItems 请求参数来确定实际是哪个客户端设法删除了一个项目。在正常操作或过载且缓慢但未失败的存储节点操作中，是否有任何东西使该假设无效？为了争论，我明确没有考虑“DynamoDB 在 $REGION 模式下关闭”...

[我的用例是作为一种协调机制，客户端应该处理刚刚删除的特定项目；因此我不认为在删除后不一致读取等方面存在任何问题。]

Answer 1

我对底层机制的理解与您的相似，它应该可以工作。 如果您对它在后台的工作原理感兴趣，我建议您观看 Rick Houlihan 的 great re:invent talk。在这方面，他是一个更权威的声音。

虽然它应该以这种方式工作，但我仍然会走一条路线，让读者/开发人员更清楚地了解正在发生的事情。我过去用过这样的东西。我正在对该项目进行有条件的删除，条件是该项目存在。我会得到该项目不存在但可以处理的异常。

import boto3
import botocore.exceptions

from boto3.dynamodb.conditions import Key

# Create table resource etc.

try:
    response = table_resource.delete_item(
        Key={
            "key": item["key"]
        },
        ConditionExpression=Key("key").eq(item["key"])
    )
except botocore.exceptions.ClientError as e:
    if e.response['Error']['Code'] == 'ConditionalCheckFailedException':
        # This is fine, it just means the object doesn't didn't exist.
        # It means either another writer was faster or there was no such item in the first place.
        pass
    else:
        LOGGER.error(e)
        raise e

提出了另一种解决方案（针对java）here。