Статья про Yandex Planer хорошая. Но конечная цель принципиально отличается. Задача Yandex'а как можно плотнее упаковать сервера. Т.к. даже увеличение утилизации на 1% приносит ощутимую экономию.
У меня же задача распределить нагрузку как можно равномерней. И, как мне кажется, это должно быть проще :)
И да, моя изначальная идея о "реактивной" ребалансировке/дефрагментации совпадает с их. Пока есть возможность "поселить" новый процесс и система считается сбалансированной - ничего не трогаем.
Еще моя задача отличается от их тем, что вес процесса динамический. Может как расти, так и уменьшаться со временем.
Про k8s в статье нет описания самого алгоритма распределения подов. А исходники я еще не смотрел.
Василий Банников, Согласен, что идеально может не получиться.
В моем конкретном случае места должно хватать. Просто исторически сейчас процессы равномерно распределены между серверами без учета весов (примерно одинаковое количество процессов на каждом сервере, и новые добавляются на тот сервер, на котором процессов сейчас меньше всего). И система более менее работает. Но есть 1-2 сервера, которые прямо близки к пределу. А есть такие, которые очень сильно недогружены. Поэтому пора ситуацию выплавлять пока не стало поздно.
Сейчас порядка 200 серверов.
Если мне не порекомендуют какой-то известный подход/алгоритм, то я тогда в отдельном вопросе опишу то, как я хочу сам реализовать и тогда сможем пообсуждать насколько мой подход имеет право на жизнь :)
Я как раз и интересуюсь - есть ли общепринятое стороннее решение для приведенного сценария. Неужели ни у кого нет таких проблем? Как все выкручиваются?
Это понятно. Но я написал, что не хочу руками запускать повторно. А что, если сервер включат через неделю? Я же забуду, что между его выключением и включением я что-то обновлял. Хочу исключить человеческий фактор. Тем более, что админов много и вероятность человеческой ошибки повышается.
Как я в вопросе написал - повторю еще раз "Я хочу автоматику"
IMHO для такой задачи писать и поддерживать плагин - это из пушки по воробьям. Правда я не знаю, как писать плагины к кролику и окажется, что это 2 строчки кода на эрланге, но в любом случае в команде знакомых с эрлангом нет и в продакшене на такое решение я не пойду.
Время жизни сообщения к кролике нам не подойдет, т.к. не известно, через сколько штатно будет обработан прайс.
Не понял идею про очистку всех очередей. Можете развить?
Очередь в чистой БД не очень хорошо. Как на чистой БД гарантировать, что два воркера не возьмутся за одну и ту же задачу? Блокировать таблицы? Не хочется :(
И я просто не понял, зачем тогда Rabbit? Пожалуйста, развейте тему. Вдруг это то, что нам нужно?
в лучшем - монгос переберет каждый элемент массива, составит список нод, и отправит всем копию этого запроса - т.е. каждая нода* будет работать с полным списком товара.
Я тут помозговал. Но ведь проблема с тем, что когда приходит запрос (как я с исходном вопросе описывал) с пачкой товаров одного бренда, то при шардировании только по товару этот запрос будет в высокой вероятностью направлен на кучу шардов. А хотелось бы количество затрагиваемых шардов уменьшить. Это снова подталкивает к идее шардировать по бренду со всему вытекающими последствиями.
Да, с чтением будет хорошо. Как в таком случае оптимальней прайсы обновлять? Ну чтобы уж не совсем медленно было :) Т.е. приходит новый прайс. Всю старую информацию (все предложения) нужно удалить и залить новый.
Обработать лишний файл будет точно дольше, чем дополнительный вопрос. Тут скорее вопрос идеологический - этот лишний запрос как бы ломает изолированность Worker'а. Насколько это плохо? Вот в оценки этого плохо мы с коллегой и не сошлись в едином мнении.
Я в тексте вопроса дописал. В моем случае даже нет необходимости Worker'у просматривать всю очередь. Он может по-другому определить необходимо обрабатывать или нет.
В очередь сообщений можно вместе с информацией о куске, который нужно обработать передать ID файла (уникальный). И Worker может дернуть, например, какой-то REST сервис, передав туда ID файла и узнать - были ли более свежие файлы от этого пользователя? И если были, то уже нет смысла обрабатывать этот кусок файла.
Я это отлично понимаю. Поэтому и переспросил.
Просто без RabbitMQ придется логику очереди самому писать? Решать вопросы с тем, чтобы два Worker'а не схватились за одну задачу. Чтобы при падении Worker'а задачи снова появлялись в очереди. Не получится изобретение велосипеда?
Возможно есть готовое решение решение для организации очереди так, как требуется в моем случае?
У меня же задача распределить нагрузку как можно равномерней. И, как мне кажется, это должно быть проще :)
И да, моя изначальная идея о "реактивной" ребалансировке/дефрагментации совпадает с их. Пока есть возможность "поселить" новый процесс и система считается сбалансированной - ничего не трогаем.
Еще моя задача отличается от их тем, что вес процесса динамический. Может как расти, так и уменьшаться со временем.
Про k8s в статье нет описания самого алгоритма распределения подов. А исходники я еще не смотрел.