Amazon dynamodb 使用SQS或DynamoDB控制订单状态

我正在建立一个处理订单的系统。每个订单将遵循一个工作流。因此，可以预订、接受、批准付款、取消订单等。 每次订单状态发生变化时，我都会将此变化发布到SNS。要知道状态顺序是否已更改，我需要向外部API发出请求，并与上次已知的状态进行比较。 问题是：存储最后一个已知订单状态的最佳位置是什么？ 1.SQS队列。所以每次我从队列中读取消息时，使用外部API检查状态，删除消息并插入另一条具有新状态的消息。

---

2.使用数据库（如Dynamo DB）控制订单状态

我将使用数据库选项而不是SQS：

1） 选项SQS：

• 您将有一个将更改状态的应用程序
• 将状态值添加到SQS中
• 现在，另一个应用程序将检查您的邮件并发送通知，删除邮件

2） 选项DynamoDB：

• 在DynamoDB中插入更新的状态
• 在更新该字段时配置Lambda函数
• Lambda函数将发送通知
  数据库选项看起来很清楚。此外，您不必担心维护任何队列，而且一次可以从队列中读取一条消息，除非您实现并行读取器从队列中读取消息。在数据库中，您可以更新多行，它将触发lambda，您不必担心它

---

希望这有帮助

您不应该使用“存储”一词来描述有状态事实和队列发生的事情。有状态的、事实性的信息应该存储——持久化——到数据库中

队列消息应被视为“需要做什么工作的提示”——一个考虑拟议行动合理性的请求，并且如果合理，执行该动作。p> 我的意思是，当队列使用者看到创建订单的消息时，它应该检查数据库并创建订单（如果尚未存在）。更新订单？检查数据库，查看订单状态是否正确，以便进行更新。（取消已发货的订单将是状态不匹配的一个示例）

从设计上讲，队列的操作不能像数据库那样精确和原子化。在处理队列（事实上在设计队列系统时）时，消息可能会多次丢失或传递，这是其中的一种情况

---

当消息被多次传递（从队列接收）时，“队列是权威的”场景中会发生什么？如果消息丢失，会发生什么情况？使用队列没有错，但我恭敬地建议，在这种情况下，队列不应被视为权威队列。

工作流完成后会发生什么？或者每个阶段的SNS通知是enuf？可以有重复的通知吗？@Shibashis:在工作流完成后，我可以从SQS/数据库中删除消息。我不能有重复的通知。