Size: a a a

2020 October 14

BA

Bohdan Antonenko in symfony
Dmitry
а потом можно продать "standalone сервер только для вас, круче чем приоритетная очередь"
вот там уже можно делать отдельную очередь под конкретного клиента
Сейчас именно так и сделано, под каждого клиента свой сервер
источник

D

Dmitry in symfony
Bohdan Antonenko
Сейчас именно так и сделано, под каждого клиента свой сервер
если у вас такие нагрузки что под каждого клиента свой сервер, то поставьте под него отдельный сервер очереди на этом же сервере
источник

BA

Bohdan Antonenko in symfony
Dmitry
и разгружать очереди за счет повышения числа консьюмеров которые шустро-шустро разгребут очередь но при этом заставят слегка ждать
но там все зависит от того как быстро консьюмер обрабатывает сообщение
Обработка не занимает много времени, так как она дальше перекладывается в другие воркеры.
У начальства идея это все в один сервис упаковать. Чтобы на каждого клиента не приходилось делать лишних манипуляций
источник

BA

Bohdan Antonenko in symfony
Dmitry
я бы на вашем месте пошел к начальству и спросил какой план у продажников на расширение
например это будет 30 компаний в месяц максимум
значит это 360 в год
если у вас будет 360 очередей это будет минимум 360 консьюмеров
а то и больше потому что вряд ли вам нужно обрабатывать команды последовательно от каждой компании
в зависимости от ресурсоемкости консьюмера количество серверов просто для запуска консьюмеров будет расти быстро
но 30 клиентов в месяц - это очень много, так как задача решается крайне узкая) просто в одного клиента может быть достаточно много юзеров
источник

D

Dmitry in symfony
ну, я вам ход размышлений дал, дальше, думаю, вы сделаете выводы сами
источник

BA

Bohdan Antonenko in symfony
Dmitry
ну, я вам ход размышлений дал, дальше, думаю, вы сделаете выводы сами
Да, благодарю
источник

D

Dmitry in symfony
по итогу, из тех данных что вы дали, я бы сделал следующее
1. взял бы один сервер очереди и сделал бы в нем очередь на каждую компанию и их обрабатывал бы параллельно (если идея с приоритетами недоступна для бизнеса)
2. заложил бы возможность ручного шардирования из конфигов чтобы каждую компанию можно было легко перекинуть на новый сервер очереди
3. консьюмеры должны быть тоже готовы к шардированию и подключатся на нужный сервер автоматически по конфигу
источник

АЯ

Андрей Ява in symfony
Dmitry
задача выкопать яму под септик, берем карьерный бульдозер, если его не хватит, возьмем карьерный экскаватор с ковшом на 50 тонн
Какой нахер экскаватор? Реббит прост и лёгок. В отличие от бд решения.
"Нужно выкопать яму, но экскаватор мы брать не будем, мы лучше пригоним грузовик, прицепим к нему плуг, а к плугу прижелаем ковш."
источник

АЯ

Андрей Ява in symfony
Это ваше решкние через бд
источник

BA

Bohdan Antonenko in symfony
Dmitry
по итогу, из тех данных что вы дали, я бы сделал следующее
1. взял бы один сервер очереди и сделал бы в нем очередь на каждую компанию и их обрабатывал бы параллельно (если идея с приоритетами недоступна для бизнеса)
2. заложил бы возможность ручного шардирования из конфигов чтобы каждую компанию можно было легко перекинуть на новый сервер очереди
3. консьюмеры должны быть тоже готовы к шардированию и подключатся на нужный сервер автоматически по конфигу
Вот по первому пункту - насколько дорого обходится новая очередь? было бы хорошо, что когда нет запросов - нет и очереди)
источник

АЯ

Андрей Ява in symfony
Новая очередь в реббите регирируется одним запросом.
источник

СВ

Сергей Вершинин... in symfony
+ еще воркера создать)
источник

D

Dmitry in symfony
Bohdan Antonenko
Вот по первому пункту - насколько дорого обходится новая очередь? было бы хорошо, что когда нет запросов - нет и очереди)
просто держать очередь стоит недорого
я не смог с пол пинка найти данные бенчмарков, поэтому рекомендую вам просто сделать стресс-тест самому на вашем железе и поглядеть как будет изменятся поведение брокера при разном количестве очередей
источник

BA

Bohdan Antonenko in symfony
Dmitry
просто держать очередь стоит недорого
я не смог с пол пинка найти данные бенчмарков, поэтому рекомендую вам просто сделать стресс-тест самому на вашем железе и поглядеть как будет изменятся поведение брокера при разном количестве очередей
благодарю еще раз за развернутые ответы)
источник

D

Dmitry in symfony
Андрей Ява
Это ваше решкние через бд
ага, удачи вам с обеспечении acid на очередях в брокерах :)
еще раз - каждая задача рассматривается отдельно
человек спросил в чем разница, а вы, с какого-то перепугу, решили что мой выбор это очереди на основе базы
источник

AC

Artur Chobanyan in symfony
@i_s_snezhko спасибо за книгу)
источник

ИС

Игорь Снежко... in symfony
Artur Chobanyan
@i_s_snezhko спасибо за книгу)
Пожалуйста ;)
источник

AN

Alexander Nazarov in symfony
Подскажите, почему composer require symfony/form —no-cache пишет что все ок, но в vendor папке нету и половины того что есть в репозе https://github.com/symfony/form ?
источник

SP

Sergey Protko in symfony
Андрей Ява
Почему одно? Два. Если не хватает реббита, то кафка.
это чуть-чуть так разные вещи, не находишь? мол у этих двух тулов чуть отличаются юзкейсы.

На тему "быстрый легкий и стабильный" - это все быстро легко и стабильно если только пол часика почитать доки наискосок и деплоить его на стабильную дедикейтед железяку.

Если тебе нужны репликации и крутится это все на каком-нибудь класстере с автоскейлингом (то есть вдруг у тебя рэббит был на одной ноде и теперь он на другой) то все уже не так просто и легко.

В этом плане с точки зрения operations если базы хватает для базовых кейсов это вполне здравая идея. Мол если уже есть экспертиза как все это дело крутить вертеть и надежно что бы было а экспертизы с кроликом нет - то лучше на базе.
источник

SP

Sergey Protko in symfony
p.s. а еще есть cloudamqp всякие
источник