多Lambda操作同DynamoDB表同记录，如何避免竞态保证一致性？

针对你提到的8-10个Lambda高频读写同一张DynamoDB表、且常操作同一条记录的场景，以下是几种实用的竞态条件规避方案：

1. 乐观锁：利用条件表达式实现 #

这是DynamoDB原生支持的最常用方案，核心思路是给每条记录加一个版本标识（比如version字段），每次更新时带上条件：只有当前版本和预期一致，才执行更新操作。如果其他Lambda已经修改过这条记录，版本号会变化，本次更新会触发ConditionalCheckFailedException，此时可以重试更新逻辑。

示例代码（Python + boto3）：

import boto3
from botocore.exceptions import ClientError

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('your-target-table')

def safe_update_item(item_id, new_data, expected_version):
    try:
        response = table.update_item(
            Key={'id': item_id},
            UpdateExpression='SET data = :new_data, version = :new_version',
            ExpressionAttributeValues={
                ':new_data': new_data,
                ':new_version': expected_version + 1,
                ':expected_version': expected_version
            },
            ConditionExpression='version = :expected_version',
            ReturnValues='ALL_NEW'
        )
        return response['Attributes']
    except ClientError as e:
        if e.response['Error']['Code'] == 'ConditionalCheckFailedException':
            # 版本不匹配，说明有其他进程更新过，可重试或返回冲突
            return None
        raise

这种方案无需额外服务，性能损耗低，适合百万级业务规模的大部分场景。

2. 原子事务：确保更新的一致性 #

如果你的更新涉及多条关联记录，或者需要严格保证操作的原子性，可以使用DynamoDB的TransactWriteItems API。事务会确保所有写入操作要么全部成功，要么全部回滚，避免部分更新导致的数据不一致。

注意：单个事务最多支持25个操作，且会占用额外的吞吐量，适合复杂但操作量级不大的场景。

3. 分布式锁：基于DynamoDB实现独占访问 #

如果乐观锁的重试机制不适合你的业务（比如重试成本极高），可以自建分布式锁。专门创建一张锁表，结构可以是：

• 主键：item_id（对应目标表的记录ID）
• 附加字段：lock_owner（锁持有者标识）、expire_time（锁过期时间）

Lambda要更新记录时，先抢占锁：用条件表达式确保只有当前没有有效锁时才能获取锁，同时设置过期时间避免死锁。拿到锁后执行更新，完成后释放锁。

4. 批量聚合：减少并发冲突概率 #

如果业务对实时性要求不高，可以通过消息队列（比如SQS）聚合同一条记录的更新请求，再用单个Lambda定期批量处理这些请求。这样同一时间只有一个进程在更新该记录，从根源上减少冲突。

比如给同一条记录的更新请求设置相同的MessageGroupId，SQS会保证同一分组内的消息被依次处理，避免并发更新。

5. 限制并发：控制单记录的更新线程 #

通过SQS的消息分组特性，或者自定义并发控制逻辑，限制处理同一条记录的Lambda并发数。比如将同一记录的所有更新请求路由到同一个Lambda实例，确保同一时间只有一个线程在处理该记录的更新。

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