- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
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.
Contenuto pertinente
- AWS UFFICIALEAggiornata 4 mesi fa
- AWS UFFICIALEAggiornata 7 mesi fa
- AWS UFFICIALEAggiornata 2 anni fa
- Perché il ripristino point-in-time della mia istanza di database di Amazon RDS richiede molto tempo?AWS UFFICIALEAggiornata 2 anni fa