Положите свою работу в ку

Если вы когда-либо писали приложение, которое должно было реагировать при выполнении некоторых медленных или длительных задач, то вы, вероятно, читали об использовании фоновых заданий. В чудесном мире Ruby существует довольно много вариантов обработки фоновых заданий. Сегодня вы встретитесь с Ку.

Фон на Ку

Что такое Ку? Как и все хорошие проекты, README дает хорошее описание:

Qu — библиотека Ruby для организации очередей и обработки фоновых заданий. Это сильно вдохновлено delayed_job и Resque.

Брэндон Хранители создал Qu, чтобы преодолеть недостатки существующих библиотек очередей, помогая в разработке Harmony , Gaug.es и SpeakerDeck в Ordered List .

Вот некоторые из недостатков, которые Ку пытается преодолеть:

• Тихая неудача
  • некоторые существующие решения потерпят неудачу, и вы никогда не узнаете об этом.
• Единый персистентный бэкэнд
  • будучи рассчитанным только на один постоянный бэкэнд, ограничивает среду, в которой может использоваться библиотека очередей. (например, комбинация Resque / Redis)
• Работа выполняется несколько раз
  • Некоторые библиотеки очередей продемонстрировали конфликт в ActiveRecord, который позволял запускать одно задание нескольким работникам.

Есть несколько других проблем, изложенных в README совсем недавно в блоге Брэндона.

Помимо стремления решить эти проблемы, Ку будет требовать работы, когда работник убит, поэтому никакие работы не будут потеряны. Кроме того, если вы знакомы с Resque, вы заметите, что у Qu есть «похожий на Resque» API, который может помочь вам в переходе.

Silent Fail

Когда работа выполняется, как вы справляетесь со сбоями? Куда идут исключения? Некоторые библиотеки просто ничего не делают, в то время как другие регистрируют ошибку. Когда Qu выполняет задание, он поймает исключение любого типа и зарегистрирует его в коллекции «сбоев» в базе данных. Это удобная функция, но она не должна быть вашим единственным методом обработки ошибок.

Помимо регистрации исключения, ваш собственный код задания должен перехватывать исключения и реагировать соответствующим образом. Естественно, что такой код может страдать от этой проблемы, когда вы пишете один и тот же код снова и снова.

Как только ловушки будут готовы, обработка ошибок, возникающих при выполнении задания, станет проще и понятнее для реализации.

Единый бэкэнд персистентности

Использование библиотеки очередей, привязанной к одному постоянному бэкэнду, может не быть проблемой для многих проектов, но может быть ограничением для некоторых. Возможно, вы не уверены, хотите ли вы использовать Redis или MongoDB для проекта, над которым вы работаете. Или, возможно, вы использовали Redis, но обнаружили, что он не отвечает вашим потребностям. В большинстве случаев для этого потребуется изменить библиотеку очередей.

Qu имеет API, который абстрагирует бэкэнд персистентности, что позволяет использовать многие решения для персистентности. Начиная с версии 0.1.3, Qu имеет встроенную поддержку Redis и MongoDB. Позже в этой статье вы узнаете больше о том, что Брэндон, автор Qu, думает о будущем поддержки дополнительных бэкэндов персистентности.

Вакансии выполнены один раз

Одна из проблем, которую пытается решить, — это вероятность конфликта, который может возникнуть, когда несколько сотрудников получают доступ к базе данных. Брэндон заметил эту проблему с ActiveRecord и решил исправить ее в Qu. Команды LPOP и BLPOP используются с бэкэндом Redis, когда рабочие получают задания. Такое же поведение достигается с MongoDB с помощью операции findAndModify .

Образец

Ниже приведен простой пример, который демонстрирует создание задания и добавление его в очередь. После этого рабочий начинает обрабатывать работу.

class ScrapeWebsite @queue = :data # not required, defaults to :default def self.perform(url) results = url.scrape results.save end end # queue the job job = Qu.enqueue ScrapeWebsite, "http://github.com" 

 $ bundle exec rake qu:work QUEUES=data