Отложенные задачи в YDB: 4 способа реализации без внешних очередей

Когда бэкенду требуется отложенная обработка задач — отправить письмо после регистрации, пересчитать агрегаты или выполнить действие по расписанию — многие разработчики по привычке подключают внешние системы вроде RabbitMQ, Kafka или Redis. Но если данные уже хранятся в YDB, все необходимые инструменты уже встроены: таблицы, changefeed, топики и координационные ноды. В этой статье разберём четыре подхода к асинхронной обработке задач, от простой таблицы до production-готовой архитектуры. Каждый следующий метод решает проблемы предыдущего, но добавляет сложность. Вместо абстрактных описаний — рабочий код на Go с использованием ydb-go-sdk.

Четыре подхода к отложенным задачам в YDB

Первый подход — самая простая таблица задач. Создаётся таблица с полями: идентификатор задачи, время выполнения, статус, полезная нагрузка. Фоновый процесс периодически опрашивает таблицу, выбирая задачи со временем выполнения меньше текущего и статусом «ожидает». После обработки статус меняется на «выполнено». Такой подход легко реализовать, но он имеет серьёзные ограничения: при большом количестве задач таблица разрастается, а частые запросы создают нагрузку. Кроме того, если обработчик упадёт после выполнения задачи, но до обновления статуса, задача будет обработана повторно. Для простых сценариев с низкой нагрузкой этого достаточно.

Второй подход — использование changefeed. YDB позволяет создавать поток изменений для таблицы: каждое добавление, изменение или удаление записи попадает в changefeed. Подписчик получает уведомления и может обрабатывать задачи по мере их появления. Это избавляет от необходимости периодического опроса таблицы — система реагирует на события мгновенно. Однако changefeed не гарантирует доставку в порядке появления, и если подписчик отстаёт, сообщения накапливаются. Также нужно аккуратно обрабатывать повторные доставки, так как YDB может повторно отправить сообщение в случае сбоя.

Третий подход — использование топиков. Топики в YDB — это аналог Kafka: они хранят сообщения, поддерживают партиционирование и позволяют нескольким потребителям читать из разных партиций. Это даёт горизонтальное масштабирование: можно запустить несколько обработчиков, каждый из которых читает свою партицию. Топики также поддерживают хранение сообщений в течение заданного времени, что удобно для отложенных задач. Но для этого нужно настроить продюсер и консьюмер, управлять смещениями и обрабатывать ошибки чтения. Этот подход сложнее предыдущих, но он уже пригоден для production-сценариев с высокой нагрузкой.

Четвёртый подход — координационные ноды. Это самый сложный, но и самый надёжный вариант. Координационные ноды YDB предоставляют распределённые примитивы: блокировки, барьеры, распределённые счётчики. С их помощью можно реализовать распределённый планировщик, который гарантирует, что каждая задача будет выполнена ровно один раз, даже при сбоях. Например, можно использовать распределённую блокировку, чтобы только один обработчик мог взять задачу в работу. Это решает проблему повторной обработки и позволяет строить отказоустойчивые системы.

Предыстория и контекст

YDB — это распределённая SQL-база данных, разработанная в Яндексе. Она спроектирована для горизонтального масштабирования и высокой доступности, что делает её привлекательной для бэкендов, работающих с большими объёмами данных. В YDB изначально заложены такие возможности, как топики и changefeed, но многие разработчики не знают о них и подключают внешние очереди, хотя можно обойтись встроенными средствами. Это увеличивает сложность инфраструктуры и стоимость поддержки. Статья на Хабре призвана закрыть этот пробел, показывая, как использовать уже имеющиеся инструменты.

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

Как работает таблица задач в YDB?

Таблица задач — это обычная таблица в YDB, в которой каждая строка представляет собой задачу. Структура может выглядеть так: id (UUID), payload (JSON), executeat (timestamp), status (string). Фоновый процесс с определённой периодичностью выполняет запрос: SELECT FROM tasks WHERE executeat <= NOW() AND status = 'pending'. Полученные задачи обрабатываются, после чего статус меняется на 'done'. Чтобы избежать повторной обработки, можно использовать транзакции: атомарно выбирать и обновлять статус. В YDB для этого есть транзакции с сериализуемой изоляцией. Но при большом количестве задач этот подход становится неэффективным из-за частых сканирований таблицы.

Чем changefeed отличается от топиков?

Changefeed — это поток изменений, который YDB генерирует при изменении данных в таблице. Он позволяет приложению получать уведомления о вставках, обновлениях и удалениях. Топики — это отдельное хранилище сообщений, которое не привязано к таблицам. В топик можно писать любые данные, а потребители читают их в порядке партиций. Основное отличие — changefeed автоматически отслеживает изменения в таблице, а топики требуют явной записи. Для отложенных задач топики удобнее, так как они поддерживают хранение сообщений и могут быть использованы как очередь. Однако changefeed проще в настройке, если задачи уже хранятся в таблице.

Технические детали реализации

В статье приведён код на Go с использованием ydb-go-sdk. Для таблицы задач показано, как создавать таблицу, вставлять задачи и выполнять фоновый опрос. Для changefeed — как создать поток изменений и подписаться на него. Для топиков — как создать топик, писать сообщения и читать их с помощью потребителя. Для координационных нод — как использовать распределённую блокировку для гарантии единственного выполнения. Каждый фрагмент кода сопровождается пояснениями, что делает статью полезной для разработчиков, которые хотят внедрить эти подходы в своих проектах.

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

Кого затронет и как

Разработчики бэкенд-сервисов, которые используют YDB, могут упростить свою архитектуру, отказавшись от внешних очередей. Это снижает количество компонентов в инфраструктуре и уменьшает задержки, так как данные не покидают базу данных. Компании, которые уже используют YDB, могут сэкономить на лицензиях и обслуживании дополнительных систем. В России и СНГ YDB активно используется в Яндексе и других компаниях, поэтому статья будет полезна локальному сообществу разработчиков.

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

Что будет дальше

Автор статьи, вероятно, продолжит развивать тему, публикуя более детальные разборы каждого подхода с полным кодом и бенчмарками. Возможно, появятся готовые библиотеки, которые упростят работу с отложенными задачами в YDB. YDB сама по себе развивается, и можно ожидать улучшения встроенных инструментов для работы с очередями. Следите за обновлениями документации и блога YDB, чтобы быть в курсе новых возможностей.

Итог

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