Вопрос первый — что использовать. Варианты есть, я пробовал три. Gearman — штука тяжелая, и для работы (в смысле потребных ресурсов), и для использования. На мой взгляд, его использование оправданно только если вы дали себе труд его полноценно освоить, и вся его функциональность вам действительно необходима. Кому-то, видимо, это может потребоваться.
Beamstalkd — на мой взгляд, чуть мутный. При его освоении у меня возникало вопросов чуть больше, чем он реально требует. Вероятно, это проблема его документированности. Но именно в процессе его освоения я пришел к выводу, что для моих нужд функциональность очереди сообщений требуется самая минимальная.
Тут-то под рукой и оказался MemcacheQ. Первое же, бросающееся в глаза достоинство — один технологический ряд с memcache(d). Протокол общий. Разница только в реализации технологии очередей, причем именно в минимальной функциональности. Зато барьер освоения (learning curve) тоже нулевой. Общий протокол позволяет и использовать те же драйверы, например для PHP, и соответствующие модули nginx.
Вопрос второй — как использовать. В процессе освоения всех вариантов, особенно первого, возникало ощущение — вещь на вид очень полезная, только непонятно чем. Можно устроить очередь задач (путем последовательной обработки очереди сообщений), но каких? Во всех примерах приводится обработка отправки почтового сообщения (сообщений). Чудесно, особенно для спамеров, но что еще?
На данный момент я готов сформулировать, на мой взгляд, чуть ли не самое полезное применение очереди задач в обычном сайтостроении. Одна из главных проблем (задач) в устроении сайтов — производительность. Причем для задачи чтения данных из базы проблема производительности стандартно решается кэшированием. Ничего лучше и эффективнее пока не придумали. А как с записью в базу? А с записью самое лучшее с точки зрения эффективности — использование очереди.
В двух словах — получил данные, отправил их в очередь, сообщил посетителю, что все ОК. Потом в фоне отправил данные из очереди в базу. Заставлять пользователя ждать результата записи, все равно что заставлять клиента химчистки ждать в приемной результата услуги.
Можно еще лучше — получил данные, ответил пользователю ОК, после этого отправил данные в очередь (здесь напомним про fastcgi_finish_request). Кстати, fastcgi_finish_request позволит при желании и для обработки очереди обойтись без крона. Впрочем, это уже изыски.
Даже на весьма нагруженных сайтах нагрузка не бывает равномерной. Можно разгребать очередь в интенсивности, обратно пропорциональной нагрузке (или наоборот, кому как лучше). Главное, что использование очереди для записи в базу и кэша для чтения может поднять производительность просто фантастически. Особенно если учесть, что, какой бы базой вы ни пользовались, это полностью решает проблему блокирования (locking) базы при записи.