Cron jobs essentially pass control of your code to the operating system. Although the Cron job is a valuable tool, it’s not the only option.
Because a Message Queue Broker is a separate system that your project interfaces with, you could feasibly use many different apps created in many different languages.
Cluster support will be a priority for a lot of people, but it was not a priority for us. (Cluster support is the ability to have a cluster of MQ Brokers.)
To achieve this, we consider two concepts (on next slides).
This is what that looks like in production. Many of these components exist on dedicated servers and/or server clusters.
Some people who are more familiar with Carrot and Celery might wonder why not use the “always eager” setting, which processes MQ tasks in real time. However, in our experience that setting does not provide the effect we are after, and it is frustrating to get timeouts on long-running processes in development.
You want to replace trouble spots in your project as they come up. No need to rewrite your entire project right away.
The MockHTTP object always serializes GET and POST data. It then saves any additional HTTPRequest attributes specified when it is called.
Massaging the Pony: Message Queues and You
Massaging the Pony:Message Queues and You<br />Shawn Rider<br />PBS Education<br />DjangoCon 2010<br />http://www.flickr.com/photos/funtik/1175522045<br />
What is a Message Queue?<br />A system for enabling asynchronous processing of discrete tasks.<br />Super awesome.<br />http://www.flickr.com/photos/gadl/89650415<br />
What are they good for?<br />Alleviate server issues by offloading processing<br />http://www.flickr.com/photos/islandgyrl/3197469932<br />
What are they good for?<br />Make better user experiences<br />http://www.flickr.com/photos/bbaltimore/6779682<br />
What are they good for?<br />Increase the reliability of third party service integrations.<br />
What are they good for?<br />Background media processing<br />http://www.flickr.com/photos/factoryjoe/2882992091<br />
What are they good for?<br /> Repeating Tasks can replace Cron jobs <br /> Keep all your code in your project<br />
Available MQ Solutions<br />There are many solutions out there. To name a few of them:<br />RabbitMQ<br />Amazon Simple Queue System<br />Apache MQ<br />Gearman<br />OpenAMQ<br />Peafowl<br />Q4M<br />Starling<br />Sun Java System Message Queue<br />
Criteria for Broker Selection<br />The following criteria were important to us in selecting a solution. You may have some different needs.<br />Handling exceptions and recovery<br />Low level of required maintenance<br />Ease of deployment<br />Persistent queuing<br />Community support<br />What language is it written in? How compatible is that with our current systems?<br />Cluster support<br />
Failsafe MQ Brokers<br />Must be able to survive a server failure.<br />Upon restarting the MQ Broker, processing should resume from the last un-processed messages in queues<br />
Queue Durability<br />The Messages Queue Broker must be able to reconstruct the queues when it is restarted.<br />http://www.flickr.com/photos/raul/846318014<br />
Message Persistence<br />The Messages (tasks to be completed) must persist between shutdowns and restarts of MQ Server<br />
The Production System<br />Webapp<br />Rabbit<br />MQ<br />Celery<br />Worker<br />Server(s)<br />Database<br />
MQ in Development Environs<br />It is important to be able to develop Message Queue tasks in Django without being concerned about running the broker process, queue setup, persistence etc.<br />
MQ in Development Environs<br />CARROT_BACKEND = ‘qhettoq.taproot.Database’<br />Carrot can be set up to use different queuing backend for development purposes<br />GhettoQ provides database backend for carrot where a database serves as the queue storage<br />The broker is a simple Django application that monitors the queue in DB<br />Inefficient, therefore only suitable for development environments<br />
Ease a future MQ implementation<br />Isolate functionality into reusable components.<br />
Django, HTTP Requests & MQ<br />Most functionalities provided throughDjangoapplications are tightly coupled with HTTP requests e.g. form data processing<br />In order to asynchronously execute a task, Celery (any task management platform) must serialize & store parameters<br />HTTP requests are usually large and not easily serializable. e.g. WSGI requests<br />
Making Message Queue Tasks<br />It is fast and easy to add a decorator to specific functions to create Message Queue tasks.<br />from celery.decoratorsimport task<br />@task<br />def add(x, y):<br />return x + y<br />
Explicitly Inherit from Celery’s Task Object<br />
Then What?<br />Some Message Queue tasks can complete with no notification required.<br />For other tasks:<br />Notify by email<br />Use an AJAX listener to notify users<br />Some other messaging<br />
In Review<br />Choose your MQ solution wisely<br />Set up a robust system<br />Leverage your existing code<br />Replace trouble spots as they come up<br />Profit!<br />