使用 SQS 或 DynamoDB 控制订单状态答案

【问题标题】：Using SQS or DynamoDB to control order status使用 SQS 或 DynamoDB 控制订单状态
【发布时间】：2016-09-21 02:18:38
【问题描述】：

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

【问题讨论】：

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

标签： amazon-dynamodb message-queue amazon-sqs

【解决方案1】：

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

队列消息应被视为需要完成哪些工作的“提示”——请求考虑所提议操作的合理性，如果合理，则执行该操作。

我的意思是，当队列消费者看到创建订单的消息时，它应该检查数据库并创建订单（如果尚不存在）。更新订单？检查数据库以查看订单是否处于正确状态以进行更新。（取消已经发货的订单就是不匹配状态的一个例子）。

从设计上讲，队列的操作不能像数据库那样精确和原子。 Two Generals Problem 是处理队列（实际上是设计队列系统）时成为问题的几个场景之一——消息可能会丢失或传递多次。

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

【讨论】：

【解决方案2】：

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

1) 选项 SQS：

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

2) 选项 DynamoDB：

在 DynamoDB 中插入您的更新状态
在更新该字段时配置 Lambda 函数
Lambda 函数将发送通知

另外，数据库选项看起来很清晰，您不必担心维护任何队列，而且您可以一次从队列中读取一条消息，除非您实现并行读取器以从队列中读取。在数据库中，您可以更新多行，它会触发 lambda，您不必担心它。

希望有帮助

【讨论】：