本文详解如何在 dynamodb 中通过原子化条件更新，结合错误重试机制，安全、高效地实现“同月递增、跨月重置”的请求计数逻辑。
本文详解如何在 dynamodb 中通过原子化条件更新，结合错误重试机制，安全、高效地实现“同月递增、跨月重置”的请求计数逻辑。
在 DynamoDB 中，UpdateItem 操作本身不支持条件分支表达式（如 IF month == currentMonth THEN ... ELSE ...），UpdateExpression 仅支持函数（如 if_not_exists, list_append）和简单算术，无法嵌入逻辑判断。因此，试图用单条语句同时完成“同月+1、跨月归零”是不可行的——这正是原始代码中仅靠 SET 和 if_not_exists 无法满足业务需求的根本原因。
✅ 正确解法：采用 “乐观条件更新 + 失败捕获重试”双阶段策略
第一阶段：尝试原子化“同月递增”
使用 ConditionExpression 强制校验当前记录中的 activeMonth 是否等于本月，仅当匹配时才执行递增：
import { UpdateItemCommand, ConditionalCheckFailedException } from '@aws-sdk/client-dynamodb';
const currentMonth = new Date().getMonth() + 1; // 注意：getMonth() 返回 0–11，建议转为 1–12 更符合直觉
// 阶段一：假设仍在同一月份，仅递增
const tryIncrementCommand = new UpdateItemCommand({
TableName: TABLE_NAME,
Key: { accessKey: { S: metadataAccessKey } },
UpdateExpression: 'SET requestCount = if_not_exists(requestCount, :zero) + :one',
ConditionExpression: 'activeMonth = :currentMonth', // 关键：严格校验月份一致
ExpressionAttributeValues: {
':zero': { N: '0' },
':one': { N: '1' },
':currentMonth': { N: currentMonth.toString() },
},
ReturnValues: 'ALL_NEW',
});❌ 若 activeMonth 不匹配（即已跨月），DynamoDB 将抛出 ConditionalCheckFailedException —— 这不是错误，而是预期的业务信号，表明需进入第二阶段。
第二阶段：执行“跨月重置”
捕获异常后，发起第二次 UpdateItem，将 requestCount 置为 1、activeMonth 更新为当前月份：
try {
const result = await dynamoClient.send(tryIncrementCommand);
console.log('✅ 同月递增成功:', result.Attributes);
return result.Attributes;
} catch (error) {
if (error instanceof ConditionalCheckFailedException) {
// 阶段二：跨月重置
const resetCommand = new UpdateItemCommand({
TableName: TABLE_NAME,
Key: { accessKey: { S: metadataAccessKey } },
UpdateExpression: 'SET requestCount = :one, activeMonth = :currentMonth',
ExpressionAttributeValues: {
':one': { N: '1' },
':currentMonth': { N: currentMonth.toString() },
},
ReturnValues: 'ALL_NEW',
});
const result = await dynamoClient.send(resetCommand);
console.log('? 跨月重置成功:', result.Attributes);
return result.Attributes;
}
throw error; // 其他异常正常抛出
}⚠️ 关键注意事项：
- 月份标准化：推荐使用 new Date().getMonth() + 1 或更健壮的 format(new Date(), 'yyyy-MM')（配合 date-fns）生成可读、可比较的月份标识（如 "2024-05"），避免仅存数字引发的歧义（如 5 vs 05）；
- 幂等性保障：两次操作均为 UpdateItem，天然幂等；若网络超时导致不确定结果，客户端应基于 ReturnValues: 'ALL_NEW' 的响应做状态判断，避免重复重置；
- 性能与成本：绝大多数请求走第一阶段（O(1)），仅跨月瞬间产生一次额外请求，对吞吐影响极小，且避免了读-改-写（Read-Modify-Write）带来的并发风险与额外 RCUs；
- Schema 建议：确保 activeMonth 属性存在默认值或通过 if_not_exists(activeMonth, :defaultMonth) 初始化，防止首次写入时条件检查失败。
总结：DynamoDB 的强一致性条件更新机制，配合明确的异常分类处理，是实现“状态敏感计数器”的最佳实践。放弃在单语句中塞入逻辑分支的思路，转而利用条件失败作为业务跃迁信号，既保持原子性，又清晰表达了领域语义。
