- 最新
- 投票最多
- 评论最多
If you need all messages in a FIFO queue to be delivered in strict order, just use the same MessageGroupId for all messages. You can name it "default-group". Having that will work just fine, but remember that a FIFO queue like that will not give out the next available message until the previously received message is deleted -> this is the way such queue guarantees processing in order. So you maximum throughput of a pure FIFO queue like that will be limited.
There are however common use cases where you don't need strict ordering of all messages. Imagine a system that keeps track of user data and provides notification about changes to user data. You may want to get notification of changes about particular user in order, but you may want to process notification about different users in parallel.
If you use a single FIFO queue, all notifications will get processed in sequence, no parallelism is possible.
If you use a queue per user, then with a lot of users you need a lot of queues and you need to call ReceiveMessage on each queue to find if there's anything to process.
You can use a single FIFO queue and provide user id as MessageGroupId. You can then poll for messages from that single queue and SQS FIFO queue will give you message that belong to same MessageGroupId in order, but messages with different MessageGroupIds in parallel.
This re:Invent talk explores more messaging patterns across AWS services: https://www.youtube.com/watch?v=4-JmX6MIDDI
I didn't know that FIFO queues couldn't subscribe to SNS topics. Never mind on this. It doesn't appear FIFO is ready for prime time. I'll continue using RabbitMQ.
相关内容
- AWS 官方已更新 5 个月前