如何按序处理事件且保证单员工仅一个活跃进程？

你的核心问题在于手动重新入队会破坏FIFO队列的顺序——当你把未获取到锁的事件重新入队时，该事件会被放到对应员工消息分组的队尾，后续新传入的同员工事件会先于它被处理，直接打乱顺序。

正确的实现思路（无需手动加锁+重新入队） #

利用FIFO SQS的两个核心特性，就能同时满足你的所有需求：

• 消息分组ID（Message Group ID）：为每个员工分配唯一的分组ID（比如员工ID）。FIFO队列会保证同一分组内的消息严格按入队顺序依次处理，不同分组的消息则可以并行处理，天然实现"不同员工并行、同员工顺序"的要求。
• 可见性超时（Visibility Timeout）：当Lambda触发处理某条消息时，该消息会进入不可见状态，时长由Visibility Timeout设置决定。在这段时间内，同一分组的下一条消息不会被Lambda拉取处理，直到当前消息处理完成（成功从队列删除）或者超时。这就自动保证了单个员工仅存在一个活跃处理进程，无需额外的DynamoDB锁。

补充细节 #

1. Lambda配置：将Lambda的并发数设置为合理值（根据你的并行处理需求），FIFO队列会自动按分组分配消息，避免同员工的消息被并发处理。
2. 处理失败的情况：如果Lambda处理某条消息失败，不要主动重新入队，让消息在Visibility Timeout到期后自动回到队列。由于同一分组的顺序性，这条失败的消息会排在后续新消息的前面，保证处理顺序不被打乱。
3. 消息去重：如果上游可能重复发送同一件事，可利用FIFO SQS的消息去重ID（Message Deduplication ID），避免重复处理相同事件。

如果你坚持要用DynamoDB锁方案（不推荐） #

如果必须保留手动加锁逻辑，要避免顺序被破坏，需做以下调整：

• 当Lambda获取锁失败时，不要主动将消息重新入队，而是直接抛出异常，让消息的Visibility Timeout到期后自动回到队列。这样消息会保持在原分组的顺序位置，不会被新消息插队。
• 若一定要主动重新入队，需为重新入队的消息设置与原事件一致的消息去重ID，并确保FIFO队列的去重机制生效，避免消息被放到队尾。

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