tgoop.com/eshu_coding/187
Last Update:
Палантир. Часть 2. Жизненный цикл команд.
#палантир@eshu_coding
Как я уже упоминал, мой сборщик построен на микросервисной архитектуре: центральный сервер - master для хранения информации, находящийся над БД (postgresql) и slave-ы сборщики, в некотором количестве.
В master-е генерируются приказы: загрузить историю из определенного чатика/канала или проверить наличие чата для дискуссий у канала.
И как только пошла +- боевая нагрузка, я начал собирать грабли за граблями. Казалось бы, логика работы простая:
1. Чекаем базу, если есть чаты или каналы, которые давно не обновлялись - создаём приказ на обновление.
2. Сборщик берет приказ, пытается выполнить его.
З. Если приказ не может быть выполнен каким-либо сборщиком (лимиты телеги на спам например) - приказ возвращается "на базу", авось кто сможет выполнить.
Всё логично? Но если счёт приказов идёт на десятки тысяч, достаточно быстро возникает "шторм" из невыполнимых приказов: сервисы перебрасываются ими 99% времени.
Пришлось додумывать жизненный цикл приказов. Проблема вроде решилась.
Через какое-то время я обнаружил, что полезли дубли в засосанных сообщениях. Сначала нашел небольшой баг в сборщике, пофиксил. А следом началась чертовщина: дубли никуда не делись, их стало только больше.
Выяснилось, что при рабочей нагрузке возникает ситуация, когда приказ уже ушел на исполнение, данные грузятся, грузятся, грузятся, попадают в длииинную очередь. В это время приходит время генерации следующей партии приказов, генерится дубль уже выполняющегося и отправляется на исполнение другому сборщику. Как результат - число дублей в какой-то момент дошло до 25%.
Пришлось додумывать жизненный цикл приказов. Проблема вроде решилась.
Но вылезла другая проблема: "узкий" запрос на получение чатика от канала имеет один счетчик флуда с простым поиском юзера/канала по юзернейму. В итоге у меня сеть перестала расти, т.к. сборщики исчерпывали свой суточный лимит запросов буквально за час.
Будь у меня один сборщик - проблем бы не было, т.к. вся нужная для доступа информация сохраняется в сессии. Но у меня их несколько, потому, чтобы получить доступ к каналу/чату первый раз нужно сделать поиск.
Пришлось додумывать жизненный цикл приказов. Проблема вроде решилась.
Вся система стала работать как часы, производительность сборки улучшилась... И тут всплыла проблема ограниченной памяти сервера: если все сборщики одновременно натыкаются на огромные каналы/чаты база перестает справляться с нагрузкой на запись, потребление оперативки растет, что в итоге засталяет линукс sacrifice cild убить или postgres или master сборщика.
Пришлось додумывать жизненный цикл приказов. Проблема вроде решилась.
Продолжение следует...
P.S. В итоге у меня приказы возвращаются ограниченное количество раз, а поиск по юзернейму случается только когда предыдущие несколько сборщиков вернули запрос. Кроме того менеджер приказов анализирует очереди и при необходимости выдает slave-ам команду "поспать".
BY Эшу быдлокодит
Share with your friend now:
tgoop.com/eshu_coding/187