Эшу быдлокодит

Палантир. Часть 13. Жизненный цикл приказов, эпизод черт знает какой.
#палантир@eshu_coding

Изначальная идея взаимодействия мастера и сборщиков заключалась в следующем:

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

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

Решением стала полная перекройка логики. При работе клиент телеграма сохраняет "сессию" - данные для упрощения повторных логинов и повторных запросов к чатам и каналам, которые уже встречались аккаунту на просторах телеграма. В моем случае база централизовано хранится в отдельном сервере Postgres с помощью очень удобного инструмента, ссылку на который я обнаружил, читая документацию к telethon (да, я иногда это делаю:)).

У всех чатов и канало в базе добавилась колонка Finder, где содержится массив всех номеров телефонов сборщиков, "знакомых" с этим каналом. Сборщик, когда просит данные, "представляется" и сообщает, заблокированы ли у него тяжелые запросы.

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

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

Telegram

Эшу быдлокодит

Палантир. Часть 2. Жизненный цикл команд.
#палантир@eshu_coding

Как я уже упоминал, мой сборщик построен на микросервисной архитектуре: центральный сервер - master для хранения информации, находящийся над БД (postgresql) и slave-ы сборщики, в некотором количестве.…

www.tgoop.com/eshu_coding/217

365 viewsEshu Marabo, edited  Jul 21, 2021 at 05:41

Палантир. Часть 13. Жизненный цикл приказов, эпизод черт знает какой.
#палантир@eshu_coding

Изначальная идея взаимодействия мастера и сборщиков заключалась в следующем:

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

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

Решением стала полная перекройка логики. При работе клиент телеграма сохраняет "сессию" - данные для упрощения повторных логинов и повторных запросов к чатам и каналам, которые уже встречались аккаунту на просторах телеграма. В моем случае база централизовано хранится в отдельном сервере Postgres с помощью очень удобного инструмента, ссылку на который я обнаружил, читая документацию к telethon (да, я иногда это делаю:)).

У всех чатов и канало в базе добавилась колонка Finder, где содержится массив всех номеров телефонов сборщиков, "знакомых" с этим каналом. Сборщик, когда просит данные, "представляется" и сообщает, заблокированы ли у него тяжелые запросы.

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

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

BY Эшу быдлокодит