DynamoDB事务更新多项：关注关系与粉丝数递增方案咨询

两次独立调用 vs TransactWrite：哪个更合理？ #

直接给结论：必须用TransactWrite，两次独立调用存在严重的数据一致性风险。

两次独立调用的问题很明确：如果第一次创建关注关系的Put操作成功，但第二次更新粉丝数的Update操作失败（比如网络波动、服务临时异常），就会出现「USER1已经关注了USER2，但USER2的粉丝数没涨」的不一致情况，这种问题排查和修复都很麻烦。

而TransactWrite的核心特性就是原子性——它会保证数组里的所有操作要么全部执行成功，要么全部回滚，完全避免了上述数据不一致的问题，完美匹配「关注关系创建和粉丝数递增必须同时生效」的业务逻辑。

用TransactWrite实现计数器递增的代码修正 #

你给出的代码框架已经没问题，只需要补全Update操作里的递增逻辑即可，以下是完整的可运行代码：

"TransactItems": [
    {
        "Put": {
            "TableName": "Table",
            "Item": {
                "hashKey": {"S": "USER1"}, 
                "rangeKey": {"S": "USER2"}
            },
            // 可选：添加这个条件，防止用户重复关注导致粉丝数重复递增
            "ConditionExpression": "attribute_not_exists(hashKey) AND attribute_not_exists(rangeKey)"
        }
    },
    {
        "Update": {
            "TableName": "TABLE",
            "Key": {
                "hashKey": {"S": "USER2"}, 
                "rangeKey": {"S": "USER2"}
            },
            // 核心：用SET语句实现计数器递增
            "UpdateExpression": "SET #counter = #counter + :incr",
            "ExpressionAttributeNames": {"#counter": "counter"},
            "ExpressionAttributeValues": {":incr": {"N": "1"}},
            // 可选：如果需要确保目标用户的计数器已存在才递增，保留这个条件；如果允许新用户第一次被关注时初始化计数器，可修改或移除
            "ConditionExpression": "attribute_exists(#counter)"
        }
    }
]

关键细节说明 #

1. 计数器递增逻辑：通过UpdateExpression里的SET #counter = #counter + :incr实现，:incr的值设为{"N": "1"}（DynamoDB数值类型用N标识）。
2. 处理计数器不存在的场景：如果目标用户是新用户，还没有counter字段，可以把UpdateExpression改成：

   "UpdateExpression": "SET #counter = if_not_exists(#counter, :init) + :incr",
   "ExpressionAttributeValues": {":incr": {"N": "1"}, ":init": {"N": "0"}}
   

   这样会先把counter初始化为0，再加1，最终得到1，不用提前创建计数器项。
3. 重复关注防护：Put操作里的ConditionExpression可以防止同一用户重复关注，避免粉丝数被多次错误递增。

内容的提问来源于stack exchange，提问作者sjaymj62