Как реализовать алгоритм экспайринга элементов в базе данных?

Question

[nakem]

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

Мое решение.
Я создаю мапу ключ-значение. Ключ - время, когда таска заэкспайрится, Значение - айди таски. Далее каждый раз, когда человек берет таск из бд, я в прикладе добавляю значения в мапу. Далее я запускаю джобу каждую секунду, которая чекает мапу на наличие ключей со значением настоящего времени time.Now(). Если такие имеются, то экспайрим таску в базе, добавляем такую же и тд. Если человек вовремя закинул результат таски, то просто удаляем значение из мапы.
Есть подводный камень, который я смог заметить "на берегу". Это если джоба не запустилась из-за чего-то. Чтоб не возникало проблем, мы просто сохраняем последний запуск джобы, если он раньше, чем секунду назад, то запускаемся еще и каждую секунду, в которые не запустились.
Я надеюсь, что нормально объяснил. Хотел бы как-нибудь улучшить алгоритм. Нагрузка будет.

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

Answer 1

[Akina]

По-моему, ты накрутил сверх меры. Всё решается куда проще.

Структура таблицы, максимально упрощённая:

CREATE TABLE tasks (
    id PRIMARY KEY,
    definition,
    performer_id REFERENCES performer (id)
    expired_at DATETIME
);

Взятие (параметры - id обработчика и id задачи):

UPDATE tasks
SET performer_id = @performer_idб
    expired_at  = NOW() + INTERVAL 'performing time'
WHERE ( expired_at IS NULL or expired_at < NOW() )
  AND ( id = @task_id )

То есть, задачу можно взять, если её ещё никто не брал, или если время ожидания ответа на задачу истекло. И в качестве бонуса - видно, что либо задачу никто не брал, либо кто-то брал (только последний, если таких было несколько) и прогавал сроки.

performing time может либо поставляться снаружи как параметр, либо быть свойством задачи (с соотв. полем в структуре таблицы).

Comments

[Михаил]

Умные мысли витают в воздухе :) Прямо вот один-в-один с моим решением.

[Akina]

Михаил, ну ведь очевидное же решение... для того, кто часто работает со стороны СУБД.

[nakem]

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

[Akina]

nakem,

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

А что собственно мешает-то? где это, спрашивается, "это может занять время"? условие WHERE ( expired_at IS NULL or expired_at < NOW() ) точно так же используется и при выборе задач, доступных к резервированию... то есть задача доступна сразу, как только истекло время её резервирования.

[nakem]

после того как таску взяли, она меняет свой статус на ACTIVE. Ее не могут взять другие, нужно поменять статус на expired и создать такую же таску с обычным статусом.

[Akina]

nakem,

после того как таску взяли, она меняет свой статус на ACTIVE.

Во-первых, где это было написано? я должен был типа сам догадаться?
Во-вторых - нахрена? Всё то же самое условие (если его использовать как выражение в выходном наборе) чётко и однозначно определяет, находится ли задача на обработке или нет. А по истечении срока обработки значение выражения самостоятельно, без каких-либо телодвижений, изменится, потому что изменяется текущее время. И оно же, но уже в условии отбора, не позволит взять обрабатываемую задачу с неистёкшим сроком на обработку.

Осмысливая моё решение - будьте любезны полностью забыть про своё. Сейчас у Вас в голове ну просто какая-то каша, что и приводит к весьма нелепым выводам.

[nakem]

У вас прекрасное и лаконичное решение, я понял как оно работает и я его запомню. Спасибо.
Но в данном случае оно, к сожалению, не подходит. После того как таска стала ACTIVE, она никогда не станет прежней. Вот так вот задизайнено.

[Akina]

nakem, в таком случае Вы описали даже не ползадачи. Что-то постоянно всплывают какие-то условия и дополнительные факты, которых ранее не было. Думаю, Вам надо заново обдумать формулировку вопроса, а затем написать его заново, ничего не упуская (или даже создать новую тему). А свой вариант решения можете смело спрятать под спойлер.

Answer 2

[Михаил]

Зачем так сложно?

В БД делаем поля
status - статус таска (NEW, COMPLETED)
assignee - исполнитель
scheduled - дата до которой исполнитель должен предоставить результат.

Когда выбираем список задач для взятия - используем условие

(status = NEW) AND (assignee IS NULL /*не назначена*/ OR scheduled < NOW() /*истекла*/)

Когда пользователь пытается сохранить результат - проверяем что исполнитель он и что таска не истекла. Если условие не выполнено - не даем сохранить.

И никаких демонов, тем более каждую секунду.

Comments

[nakem]

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

[Михаил]

nakem, а что значит "задача стала доступна для других"? Уведомление о ней? Появление в интерфейсе? Как это должно проявиться что "задача доступна для других"?

[nakem]

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

Answer 3

[Wataru]

То, что вы делаете, называется очередью событий.

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

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

Когда идет пробуждение по таймеру (или вообще в любое время), то надо посмотреть, а не пора ли уже какие-то таски удалить по времени и убрать из из приоритетной очереди.

Обычно такое реализуется через какой-то примитив событий: не знаю, что там есть в go. Должна быть функция ожидания события с таймаутом. Вот там надо ждать события, которое выстреливает при добавлении новой таски пользователю, а таймаут должен браться из приоритетной очереди.

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

Answer 4

[mayton2019]

Топик тегирован "Базами Данных". Какими - чорт его знает.

Поэтому есть следующие коробочные решения. Cassandra, Redis, Amazon DynamoDb. Все они поддерживают дополнительное поле TTL и удаляют записи автоматически без участия разработчика.

По поводу подводных камней о которых пишет автор. Это всё очень плохо и почти не работает в боевых условиях. Пока бэкап данных делается в обычном плановом режиме - никто не знает о существовании всяких там левых файлов на сервере приложений. Грубо говоря все думают что состояние системы (state) лежит в базе и только в базе. Поэтому попытка размазать состояние системы по нескольким нодам вычислительной сети приводит к сложным и трудноуловимым последствиям.

Comments

[nakem]

postgres