RabbitMQ какой тип exchange выбрать для сообщений?
Бизнес логика :
user1 создает событие (event)
user1.....userN отправляют заявку на участие в событии (не оновременно а в течении актуальности срока до начала события)
user1 получает заявку из очереди и обрабатывает (отклоняет принимает)
Все N user-ов могут создавать ивенты и принимать в них участие. Общее кол-во юзеров сервиса> 10k. Но в конкретном ивенте максимальное кол-во участников не более 50.
Как правильно реализовать схему взаимодействия , какой тип обменника выбрать, надо ли для каждого пользователя создавать свою очередь или какая то одна очередь и из нее по какому то критерию отдавать нужному пользователю сообщение?
Многое зависит от остальной архитектуры. Например, что такое "userX" со стороны RabbitMQ? Это прямое подключение клиента к RabbitMQ или клиент подключается через какую-то бизнес-логику (сколько инстансов)?
Держит ли клиент постоянное подключеие до БЛ/RabbitMQ или делает периодические запросы к ним? Храняться ли данные в СУБД? Какие требования к отклику? Сколько событий/заявок в секунду/минуту ожидается?
Это асинхронное вебприложение на python. В качестве клиента aio-pika. Пользователь жмет на кнопку 'Присоединиться' создается запись в БД , идентификатор которой используется в качестве message. Создается event_loop в котором выполняется передача сообщения в очередь, соединение закрывается. Это что касается producer
Для consumer немного по другому. В качестве консюмера выступает пользователь - создатель ивента. Он должен обработать поступившие заявки. Предполагается постоянное подключение, при каждом обновлении страницы будет выполняться запрос в соответствующую очередь и если там есть сообщение то обрабатывать его (делать запрос в БД по id содержащемуся в сообщениии и в UI выводить эту инфу)
По перфомансу, на текущий момент не предполагается что это будет более 1000 заявок в минуту на пике (скорее всего существенно меньше но хотелось бы предусмотерть и такой вариант прии возможности). Требования к отклику - ну тут ничего сверестественного, это не онлайн чат и секунда другаю вообще никак не влияют.
Чтобы не делать сложную систему, попробуйте (условно) раз в 10 секунд опрашивать БД на тему необработанных заявок, без необходимости создавать очереди на RabbitMQ. При ваших цифрах это выглядит оправданно.
Сергей, А если всетаки хочется rabbit ? Если есть большое желание с ним поработать ? Или в моем случае использование кролика выглядит совсем нездорово?
В данном случае я бы рекомендовал, если и использовать RabbitMQ, то только для нотификации пользователя о новых данных. Но в таком случае всё усложняется для клиентского (два источника данных) и серверного кода (дополнительные компоненты, долгие коннекты, очереди).
Но, если очень хочется (наиболее простой вариант):
Создаётся один обменник типа fanout. При создании события продьюсер посылает в него сообщение. Каждый сервер, который принимает долгие коннекты и может отправить пользователю сообщение, подключается к этому обменнику со своей очередью, получает сообщения и рассылает их, если есть кому.
Простой
Простой
Средний
