Всем привет, хочу обсудить один кейс. Есть таблица в бд

Question

Всем привет, хочу обсудить один кейс. Есть таблица в бд

с сущностями. У сущности есть дедлайн и задача сделать нотификацию с напоминанием о дедлайне. Общая схема - запускаем цикл, в котором через каждые 5 минут запрашиваем 10 сущностей, которые еще не напоминались, и отправляем это в месседжер какой нить типо кафки. Вопрос - как масштабировать такую систему? Например как следить по сколько забирать записей за раз, или с каким таймаутом, или как целостность тут поддерживать, что бы 2 инстанса не забрали одни и теже сущности, SELECT FOR UPDATE делать? но когда тогда завершать транзакцию. Делать UPDATE + RETURNING и сразу помечать нотификации как обработанные, но тогда может возникнуть проблема, что сущность отметили как напомненную, а во время отправки в месседжер паника случилась и мы нифига не отправили

#backend #go #programming #russian

0

25.06.2020

3 ответов

14 просмотров

Dmitry Goncharov

побей массив сущностей на разделы по какому-нибудь постоянному признаку, например идентификатор или время создания деленный на константу. остаток от деления будет номер раздела и их обрабатывай отдельно. для примера, в простейшем случае, для 2 разделов четный - нечетный идентификатор

0

25.06.2020

Владимир Гришин

я делаю SELECT FOR UPDATE, которая сразу выставляет новый статус типа PROCESSING, и дальше уже работаю со статусом записи в воркере

0

25.06.2020

Elmanov Anton · Accepted Answer

Если вы знаете кол-во воркеров и воркер знает свой индекс, то воркер может брать только "свои" записи, например всего 3 воркера, каждый из трёх будет брать записи, остаток от деления id которых будет равен индексу воркера (0, 1,2). Это разнесет процессинг воркерами изначально... Можно сделать транзакции и select for update, но если будут селектиться одни и те же строки, то эти запросы будут ждать друг друга и это негативно скажется на скорости процессинга.

170 похожих чатов

Всем привет, хочу обсудить один кейс. Есть таблица в бд

3 ответов

Похожие вопросы