Understanding Queues
- I find that a lot of devs have problems with thinking about queues and planning their architecture with them in mind. They get lost in the technical details and fail to see how queues really should be planned and organized to get the most out of them.
- Imagine you’re at a grocery store with a single checkout counter and a single queue, where all the shoppers are lining up. You go up to the queue, and join the back – after all, all these people have been waiting before you, don’t be rude. The check out counter then calls the first person in line forward.
- The person manning the counter scans all the groceries
- They charge the customer
- The customer pays
- The customer bags their groceries (or the groceries are bagged for them)
- They leave and the person manning the counter calls the next person forward.\
- This process will continue to repeat for as long as there are people in the queue. As soon as everyone in the queue is gone, the person at the counter will just sit there and wait until someone shows up. That’s their job as a worker.
- Notice that the queue didn’t exist at the checkout counter itself, it existed BEFORE the checkout counter. This is the biggest benefit of having a queue system. Now, if we open a second counter next to the first, they can utilize the same queue and ideally get twice as much work done. Add a third, and three times the work gets done.
- However! That only works when the counters never need to talk to each other. The minute a counter needs to talk to another counter to verify something BOTH counters need to stop working to talk before they can go back to whatever they were doing. This is where a lot of problems happen, and causes slowdowns and forces the queues to backup. Each counter needs to function completely independently for the best performance.
Pros
- It provides an easy way to measure when you need to start looking at scaling your system. If you notice the length of your queue start growing, it means you’re not able to work through your data fast enough, so you can easily add a few more workers to help with the load. And because you’re using a queue…
- Your workers don’t need to reside on the same servers! You can have any number/spec of servers with their own number of workers each and they can all still interact with the same queue. You’ve now allowed your system to scale both horizontally (more systems) AND vertically (better systems).
- One of the favourite features of Queues seems to be overlooked a lot of the time. Queues provide a place for data to wait until you get to processing it. This means that if your processing side ever breaks, or needs to be taken offline temporarily YOU’RE NOT LOSING USER DATA. Data is still being collected in the queue and when your workers come back online they can get right back to work retroactively processing the data that was waiting for them.
Cons
- Of course, with every new component there is some overhead. You will need to devote some resources to just handling the queue. It’s another component you need to manage from an infrastructure point of view.
- Ideally, the queue would be its own server which means there’s additional latency when pushing/pulling data to a queue.
Tools for queuing
- While you can write your own queue service fairly simply (for example, piggy backing on Redis) there are also some great tools for you to use and incorporate into your projects right away. I’ll be honest, I don’t feel comfortable giving a full review of them because I’ve only ever used SQS. Instead, I’d recommend you just do some research and figure out what makes sense for you.
- RabbitMQ – http://www.rabbitmq.com/
- IronMQ – http://www.iron.io/mq
- SQS – http://aws.amazon.com/sqs/
