Как реализовать события по таймеру?

Question

[Вадим]

Есть БД (PostgreSQL). В БД лежат сущности, много, допустим миллион или несколько. Хочется реализовать возможность что-то с ними делать по таймеру. Например - сущность протухла, надо с ней что-то сделать. Или периодические события, происходящие с сущностью, к примеру - напоминания о статусе.
Не хочется делать выборки SQL запросом, сравнивая даты, предполагаю это потребует много ресурсов. Да и хочется возникновения события вовремя, а не когда там сработает очередной поиск по cron.

Была идея реализовать через очереди просроченных сообщений на RabbitMQ (кладём сообщение с нужной датой просрочки в очередь и оно появится в очереди просроченных как раз когда нужно) или что-то похожее на Redis. Но теперь у нас нет Redis или Rabbit, а есть только Tarantool, Kafka да Java и Postgres. Может быть в Tarantool можно что-то похожее реализовать? Подскажите пожалуйста - куда копать.

Answer 1

[ThunderCat]

что-то с ними делать по таймеру.

Да и хочется возникновения события вовремя, а не когда там сработает очередной поиск по cron.

Так по таймеру, или по експирации? Если у вас речь идет о каком-то событии типа "просрочено" или "напомнить", делайте просто выборку с учетом условия при запросе данных.

Если неймется именно прям менять состояние сущностей - тоже можно делать это
а) по запросу от клиента. То есть предположим вы выбираете какие-то сообщения для пользователя, которые 1) не протухли по времени, 2) не имеют статус "протух", и 3) принадлежат этому пользователю. Перед этим можно сделать апдейт с этими условиями, только выбрать старые без статуса "протух" и записать им статус. Подходит если делаются частые небольшие выборки, тогда большинство запросов будет копеечными по ресурсам, а некоторые вообще никогда статус не поменяют, что значит данные слишком холодные и на них спокойно можно забить болт. Минус - перед выборокой клиенту будет задержка на апдейт бд, скорее всего это комар чихнул нагрузки, но как факт...

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

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