Яков Сироткин (yakov_sirotkin) wrote,
Яков Сироткин
yakov_sirotkin

Асинхронная обработка задач: 9 лет спустя

В далеком 2007 году, под руководством Фила dph Дельгядо я впервые реализовал движок для асинхронной обработки задач. Потом я много раз рассказывал про него на разных конференциях, применял в других проектах и даже написал статью.

В проекте, над которым я сейчас работаю, больше 2 лет не было повода внедрить движок для асинхронной обработки задач. Планы я, конечно, вынашивал, но мы отталкиваемся от бизнес-требований и это ограничивает нашу свободу действий. Неожиданно появилась потребность заменить систему для отправки писем. Это не самая критичная для нас функциональность и идеальная возможность, чтобы опробовать новые подходы. И пользователи сказали нам спасибо, потому что раньше письма отправлялись раз в 10 минут, а теперь - через несколько секунд.

После этого нас попросили сделать один отчёт - типичная для нас задача, мы уже поднаторели в создании сложных запросов с джойнами. Однако, здесь потребовалось включить данные из внешнего сервиса и тут уже в момент запроса нет возможности запросить информацию по всем объектам. К счастью, у нас уже была внедрена асинхронная обработка задач и мы сделали широкую таблицу, в которую стали в фоновом режиме складывать всю информацию для отчёта, в том числе и данные из других систем. В данном случае переиндексация одного объекта представляет собой отдельную задачу.

Фактически у нас появился индекс, по которому легко делать сложный поиск и генерировать отчёты, избавившись от джойнов, view и даже некоторых функций на PL/SQL. И если раньше иногда приходилось идти на компромиссы и показывать то, что можем, а не то, что хотят пользователи, то теперь, во время индексации, мы можем можем обработать данные как угодно и удовлетворить любой каприз.

Однако, с индексацией связана и небольшая техническая сложность: если пользователь создал или обновил какой-то объект, то через несколько секунд он может захотеть найти его поиском, поэтому задачу на переиндексацию нужно создавать в той же транзакции, в которой изменяется объект. Если бы мы не занимались 3 года методичным переходом на DAO, а поддерживали бы по персональному SQL-запросу для изменения каждого конкретного поля, то могло бы быть немного тяжеловато, а так всё получилось довольно просто.

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

Не считая отдельно стоящей системы отчётов, в нашей системе есть 5 разных типов поиска и раньше каждый из них использовал свой хитрый запрос с многочисленными джойнами, а теперь весь этот код существенно упростился и пришёл к единообразному виду. Конечно, поработать пришлось и разработчикам, и QA, но в результате наш проект стал понятней и надёжней.
Tags: code
Subscribe
  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 8 comments