多客户端向DynamoDB插入递增ID数据的最优AWS架构咨询

3个客户端场景：基于DynamoDB原子计数器的轻量方案 #

你的需求核心是生成严格递增的全局唯一ID，同时避免多客户端并发操作导致的ID重复问题。针对3个低并发客户端，最优方案是利用DynamoDB的**原子计数器（Atomic Counter）**特性，配合一张专门的元数据表来实现：

1. 创建ID生成元数据表
   新建一张名为IdGenerator的DynamoDB表，主键设为entity_type（字符串类型），仅用于存储各业务实体的当前最大ID。比如针对你的主数据表，插入一条初始记录：entity_type: main_record，current_id: 0。

2. 客户端操作流程
   每个客户端发起数据插入请求时，分两步执行：

   • 第一步：调用DynamoDB的UpdateItem接口，原子性递增current_id并返回最新值：

     aws dynamodb update-item \
       --table-name IdGenerator \
       --key '{"entity_type": {"S": "main_record"}}' \
       --update-expression "ADD current_id :incr" \
       --expression-attribute-values '{":incr": {"N": "1"}}' \
       --return-values ALL_NEW
     

   • 第二步：从返回结果中提取current_id作为新记录的ID，将请求数据插入主数据表。

这个方案完全依赖DynamoDB原生能力，无需额外服务组件，成本低、延迟小，完全适配3个客户端的低并发场景。

100个客户端场景：引入ID段缓存或中间层优化并发 #

当客户端数量提升至100，并发请求量显著增加，直接使用原子计数器会导致IdGenerator表的请求频率过高，可能触发DynamoDB的吞吐量限制。此时需要对方案进行以下调整：

优化方案1：客户端本地缓存ID段 #

在原有原子计数器基础上，让客户端预取一段连续ID（比如一次性申请50或100个ID），本地用完后再去申请下一段：

• 客户端发起请求时，调用UpdateItem将current_id一次性增加N（比如100），拿到更新后的current_id后，本地可用ID范围为current_id-N+1到current_id。
• 客户端在本地逐个使用这些ID，直到用完后再重复上述步骤申请新的ID段。

这种方式能大幅减少对IdGenerator表的请求次数，提升并发处理能力，同时依然保证ID的严格递增和唯一性。

优化方案2：引入API Gateway + Lambda中间层 #

将ID生成和数据插入的逻辑封装到Lambda函数中，客户端通过API Gateway调用Lambda来完成整个操作：

• 客户端向API Gateway发送数据插入请求，无需关心ID生成逻辑。
• Lambda函数内部执行原子递增ID + 插入主表的操作，利用Lambda的高并发特性（默认并发上限1000）轻松应对100个客户端的请求。
• 可在Lambda中加入幂等逻辑（比如用请求唯一标识作为条件），防止重复请求导致的ID重复或数据重复插入。

该方案将业务逻辑与客户端解耦，同时借助AWS托管服务的弹性能力，应对更高并发的场景。

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