一页精通 Amazon SQS

Source: Dev.to

Introduction

在一家buka（本地小吃店），没人会记下你的排号。端上jollof饭的妈妈不在乎谁先来的；她会给离她最近、喊得最响或把盘子伸得最远的人先盛饭。你可能等了五分钟，却看到后来才到的人先被服务。如果你耐心等下去，最终还是会吃到饭，但速度才是关键。

相反，在GTBank或Access Bank这样的银行，顺序很重要。你不能让柜员在你的转账完成之前就先处理你的取款。顺序决定一切。

这正是 Amazon SQS Standard 队列 与 Amazon SQS FIFO 队列 之间的区别。

Standard Queues – the “buka” model

• 消息被快速、规模化地入队和出队，顺序由系统自行管理。
• 不保证有序投递；同一条消息可能会被投递多次。
• 这种行为是有意为之——为了换取速度和高吞吐量的折中。

何时使用 Standard 队列

• 向用户发送 OTP（一次性密码）通知——顺序无关紧要。
• 上传后对头像进行尺寸调整——任何顺序都可以。
• 为分析记录应用事件日志——顺序不重要。

FIFO Queues – the “bank” model

FIFO（先进先出）队列保证进入队列的第一条消息始终是第一条被处理的，每一次都是如此。

• 一次性处理——不会出现重复投递。
• 严格有序——消息按照发送的顺序被处理。

折中

与 Standard 队列相比，FIFO 队列的吞吐量较低；它们无法匹配 Standard 队列的原始处理量。

何时使用 FIFO 队列

• 处理 Paystack 或 Flutterwave 支付——顺序很重要。
• 在交易确认后扣除钱包余额——顺序很重要。
• 执行相互依赖的入职步骤——顺序很重要。

选择合适的队列

问题不在于“哪个更好”，而是：

• 如果两条消息顺序错误或同一条消息被处理两次，会发生什么？

如果答案是“没事，我们可以接受”，就使用 Standard 队列。
如果答案让你感到不安，就选择 FIFO 队列。

在尼日利亚，大多数金融科技系统需要 FIFO 队列，而大多数通知或媒体系统可以安全地使用 Standard 队列。

Conclusion

了解系统需求有助于你选择合适的 SQS 队列类型。

我接下来应该拆解哪个 AWS 概念？

想了解更多？让我们在 LinkedIn 上联系。