Need advice about which tool to choose?Ask the StackShare community!
Amazon SQS vs Redis: What are the differences?
Amazon Simple Queue Service (SQS) and Redis are messaging and queuing solutions designed to enhance the scalability and reliability of distributed systems. Let's explore the key differences between the two:
Scalability: The key difference between Amazon SQS and Redis is their approach to scalability. Amazon SQS is a fully managed message queuing service that automatically scales based on the number of messages in the queue. It can handle high traffic and deliver messages reliably, making it suitable for applications with unpredictable workloads. On the other hand, Redis is an in-memory key-value store that can also be used as a message broker. It offers high performance and can handle large amounts of data, making it ideal for use cases that require real-time processing and caching.
Message Persistence: Another major difference is how Amazon SQS and Redis handle message persistence. Amazon SQS stores messages in queues, ensuring durability and persistence even in the event of failures. Messages can be retained in the queue for up to 14 days, providing a reliable messaging system. Redis, on the other hand, is an in-memory database where messages are stored in memory for faster access. While Redis offers persistence options like snapshotting and replication, it primarily relies on memory for performance, making it more suitable for scenarios where message durability is not the primary concern.
Message Ordering: When it comes to message ordering, there is a difference between Amazon SQS and Redis. Amazon SQS guarantees the order of the messages within a single queue, ensuring that they are processed in the order they are received. This makes it suitable for applications where message ordering is crucial, such as task queues or job processing. Redis, on the other hand, does not guarantee message ordering. It offers the flexibility to prioritize messages based on priorities or timestamps, allowing for more specific use cases but sacrificing strict ordering guarantees.
Data Structure Support: Amazon SQS and Redis support different data structures. Amazon SQS primarily handles messages in the form of strings, allowing for flexible message content. Redis, on the other hand, is known for its support of various data structures like strings, hashes, lists, sets, and more. This makes Redis a versatile choice when it comes to storing and manipulating complex data structures, providing additional functionality beyond basic message queuing capabilities.
Pub/Sub Support: Amazon SQS and Redis differ in their support for publish/subscribe (pub/sub) messaging patterns. Amazon SQS focuses on point-to-point messaging, where messages are sent to specific queues and consumed by specific subscribers. Redis, on the other hand, natively supports pub/sub messaging, allowing messages to be published to channels and consumed by multiple subscribers. This makes Redis a suitable choice for real-time messaging scenarios, where multiple components or clients need to receive messages simultaneously.
Managed vs Self-hosted: Lastly, the difference between Amazon SQS and Redis lies in their management. Amazon SQS is a fully managed service provided by Amazon Web Services (AWS), taking care of the infrastructure, scaling, and maintenance. It offers a serverless experience, making it easy to use and suitable for applications that prefer a hands-off approach to managing messaging. Redis, on the other hand, is an open-source software that can be self-hosted or managed through third-party services. While it offers more control and customization options, it requires more effort in terms of deployment, maintenance, and scaling.
In summary, Amazon SQS excels in simplicity and seamless integration within the AWS environment, making it suitable for various distributed applications. On the other hand, Redis stands out for its multifaceted use cases, serving as both a high-performance message broker and a powerful in-memory database, making it a compelling choice for scenarios where caching and persistent storage needs coalesce with messaging requirements.
Hi! I am creating a scraping system in Django, which involves long running tasks between 1 minute & 1 Day. As I am new to Message Brokers and Task Queues, I need advice on which architecture to use for my system. ( Amazon SQS, RabbitMQ, or Celery). The system should be autoscalable using Kubernetes(K8) based on the number of pending tasks in the queue.
Hello, i highly recommend Apache Kafka, to me it's the best. You can deploy it in cluster mode inside K8S, thus you can have a Highly available system (also auto scalable).
Good luck
Hi, we are in a ZMQ set up in a push/pull pattern, and we currently start to have more traffic and cases that the service is unavailable or stuck. We want to: * Not loose messages in services outages * Safely restart service without losing messages (ZeroMQ seems to need to close the socket in the receiver before restart manually)
Do you have experience with this setup with ZeroMQ? Would you suggest RabbitMQ or Amazon SQS (we are in AWS setup) instead? Something else?
Thank you for your time
ZeroMQ is fast but you need to build build reliability yourself. There are a number of patterns described in the zeromq guide. I have used RabbitMQ before which gives lot of functionality out of the box, you can probably use the worker queues example from the tutorial, it can also persists messages in the queue.
I haven't used Amazon SQS before. Another tool you could use is Kafka.
Both would do the trick, but there are some nuances. We work with both.
From the sound of it, your main focus is "not losing messages". In that case, I would go with RabbitMQ with a high availability policy (ha-mode=all) and a main/retry/error queue pattern.
Push messages to an exchange, which sends them to the main queue. If an error occurs, push the errored out message to the retry exchange, which forwards it to the retry queue. Give the retry queue a x-message-ttl and set the main exchange as a dead-letter-exchange. If your message has been retried several times, push it to the error exchange, where the message can remain until someone has time to look at it.
This is a very useful and resilient pattern that allows you to never lose messages. With the high availability policy, you make sure that if one of your rabbitmq nodes dies, another can take over and messages are already mirrored to it.
This is not really possible with SQS, because SQS is a lot more focused on throughput and scaling. Combined with SNS it can do interesting things like deduplication of messages and such. That said, one thing core to its design is that messages have a maximum retention time. The idea is that a message that has stayed in an SQS queue for a while serves no more purpose after a while, so it gets removed - so as to not block up any listener resources for a long time. You can also set up a DLQ here, but these similarly do not hold onto messages forever. Since you seem to depend on messages surviving at all cost, I would suggest that the scaling/throughput benefit of SQS does not outweigh the difference in approach to messages there.
I want to schedule a message. Amazon SQS provides a delay of 15 minutes, but I want it in some hours.
Example: Let's say a Message1 is consumed by a consumer A but somehow it failed inside the consumer. I would want to put it in a queue and retry after 4hrs. Can I do this in Amazon MQ? I have seen in some Amazon MQ videos saying scheduling messages can be done. But, I'm not sure how.
Mithiridi, I believe you are talking about two different things. 1. If you need to process messages with delays of more 15m or at specific times, it's not a good idea to use queues, independently of tool SQM, Rabbit or Amazon MQ. you should considerer another approach using a scheduled job. 2. For dead queues and policy retries RabbitMQ, for example, doesn't support your use case. https://medium.com/@kiennguyen88/rabbitmq-delay-retry-schedule-with-dead-letter-exchange-31fb25a440fc I'm not sure if that is possible SNS/SQS support, they have a maximum delay for delivery (maxDelayTarget) in seconds but it's not clear the number. You can check this out: https://docs.aws.amazon.com/sns/latest/dg/sns-message-delivery-retries.html
Pros of Amazon SQS
- Easy to use, reliable62
- Low cost40
- Simple28
- Doesn't need to maintain it14
- It is Serverless8
- Has a max message size (currently 256K)4
- Triggers Lambda3
- Easy to configure with Terraform3
- Delayed delivery upto 15 mins only3
- Delayed delivery upto 12 hours3
- JMS compliant1
- Support for retry and dead letter queue1
- D1
Pros of Redis
- Performance886
- Super fast542
- Ease of use513
- In-memory cache444
- Advanced key-value cache324
- Open source194
- Easy to deploy182
- Stable164
- Free155
- Fast121
- High-Performance42
- High Availability40
- Data Structures35
- Very Scalable32
- Replication24
- Great community22
- Pub/Sub22
- "NoSQL" key-value data store19
- Hashes16
- Sets13
- Sorted Sets11
- NoSQL10
- Lists10
- Async replication9
- BSD licensed9
- Bitmaps8
- Integrates super easy with Sidekiq for Rails background8
- Keys with a limited time-to-live7
- Open Source7
- Lua scripting6
- Strings6
- Awesomeness for Free5
- Hyperloglogs5
- Transactions4
- Outstanding performance4
- Runs server side LUA4
- LRU eviction of keys4
- Feature Rich4
- Written in ANSI C4
- Networked4
- Data structure server3
- Performance & ease of use3
- Dont save data if no subscribers are found2
- Automatic failover2
- Easy to use2
- Temporarily kept on disk2
- Scalable2
- Existing Laravel Integration2
- Channels concept2
- Object [key/value] size each 500 MB2
- Simple2
Sign up to add or upvote prosMake informed product decisions
Cons of Amazon SQS
- Has a max message size (currently 256K)2
- Proprietary2
- Difficult to configure2
- Has a maximum 15 minutes of delayed messages only1
Cons of Redis
- Cannot query objects directly15
- No secondary indexes for non-numeric data types3
- No WAL1
Sign up to add or upvote consMake informed product decisions
What is Amazon SQS?
What is Redis?
Need advice about which tool to choose?Ask the StackShare community!
Sign up to get full access to all the companiesMake informed product decisions
What tools integrate with Amazon SQS?
What tools integrate with Redis?
Sign up to get full access to all the tool integrationsMake informed product decisions
Blog Posts
+17
+9
+8
+17
+9
+12+23+17