Как в RabbitMQ, или без него, настроить классическую очередь?

Question

[Макс Максимов]

Привет!
Продолжительное время думаю над архитектурой одного проекта, но столкнулся с тех. вопросами в плане реализации.

Описание: есть 100к компьютеров-клиентов, скажем, в 50-ти интернет-клубов по стране. После каждой сессии работы на этих компах, они должны соединяться для отправки отчёта с главным серверов №2, который в свою очередь соединяется с главным сервером №1, чтобы передать отчёт, полученный от клиента, получить ответ и передать снова серверу №2, а тот -- клиенту. Время на получение ответа клиентом от сервера №2 составляет 10 секунд, если за это время ответа не получено -- соединение разрывается.

Также существует 2 вида работы: онлайн и оффлайн.
Онлайн: всё работает в порядке классической очереди, каждый отчёт обрабатывается по дате. Клиент начал и завершил сессию -> открыл соединение с сервером №2 для отправки отчёта с ожиданием в 10 секунд -> сервер №2 получил и записал в очередь -> из очереди берутся отчёты и отправляются серверу №1 для проверки и записи -> сервер №1 получает и отправляет ответ серверу №2 -> сервер №2 отправляет ответ об успешном завершении операции клиенту, который ждёт 10 секунд.

Оффлайн: Бывает такое, что сервер №1 может отвалиться в любой момент. И тогда клиент не получает ответа в течение 10 секунд, то он говорит, что сейчас он работает в оффлайн режиме. Но всё так же продолжает отправлять отчёты серверу №2. Сервер №2 так же принимает отчёты, но записывает их уже в очередь-оффлайн, которая так же должна обработаться, как только заработает сервер №1. И другие отчёты, которые приходят от клиента, так же должны ожидать. Потому что сервер №1 принимает всё последовательно.

Вопрос: как правильно организовать такую архитектуру и на чём?
Пока я пришёл к использованию RabbitMQ и микросервисов. Но думаю, что это будет моветоном для каждого клиента (100к компов) создавать свою очередь, причём будем две очереди: онлайн и оффлайн. Онлайн не обработается, пока не закончится оффлайн очередь. Но для каждого компа всё должно обрабатываться последовательно, по дате: получается такая "классическая" Советская очередь. Но параллельно с несколькими компами: 100к компов обрабатывается параллельно, но отчёты с каждого из них -- последовательно. Исходя из подсчётов: 100к клиентов и на каждого 2 очереди = 100 * 2 = 200 очередей, по 2 очередей на каждый комп.

Как правильно тут поступить? Идеи, советы?

Answer 1

[Сергей Тихонов]

из очереди берутся отчёты и отправляются серверу №1 для проверки и записи

Ага, вот это место, в котором решается, оффлайн сервер№1 или онлайн.

Потому что сервер №1 принимает всё последовательно

А это главное требование.

Вариант номер 1.
Одна общая очередь, один воркер. Если сервер №1 оффлайн, воркер просто останавливает свою работу до тех пор, пока сервер не вернется. Для текущего сообщения надо выполнить amqp reject, тогда оно вернется в начало очереди.
Порядок сообщений соблюден, но есть единая точка отказа, она же бутылочное горлышко производительности (впрочем, зависит от скорости обработки отчетов)

Вариант №2.
Одна общая очередь, много воркеров. Схема та же, сервер оффлайн - остановка обработки. Онлайн - возобновление. Узкое место по производительности и точка отказа исчезают, но два последовательных отчета от одного компьютера могут попасть одновременно на соседние воркеры, т.е. требование про "последовательно" может не выполняться.

Вариант №3.
HashRing и прочие алгоритмы хеширования, которые позволяют сократить число очередей и на каждую очередь повесить свой воркер. Необходимость ручной балансировки нагрузки, точки отказа на отдельных очередях.

Как-то так. Сходу придумать, как заставить несколько воркеров обрабатывать одну очередь с сохранением порядка сообщений я не придумал.

Comments

[Макс Максимов]

Вариант #2 кажется более оптимальным. Есть мысли, как можно сделать так, чтобы соединение с каждым клиента не терялось при ожидании ответа от сервера №2? Ну и учесть последовательность от каждого клиента, но параллельно несколько клиентов.

[Сергей Тихонов]

А сервер№2 тут вообще не участвует. Его задача - принять запрос от компьютера и положить в очередь в RabbitMQ, насколько я понял.

[Макс Максимов]

Сергей Тихонов, сервер №2 принимает соединение от клиента, держит открытыми соединение 10 секунд, пока полученный отчёт от клиента обрабатывается сервером №1, а после сервер №2 должен отправить "ОК" клиенту и закрыть соединение. Загляните сюда: Как в RabbitMQ, или без него, настроить классическую очередь?
Не могу прийти к стандартному решению, без потери последовательности и производительности.

[Сергей Тихонов]

Макс Максимов, заглянул, по 500 сообщений в минуту со 100К клиентов - с этим даже кластер кроликов, которым авторы хвалятся на просторах интернета, справляется впритык.
Все-таки кролика не стоит нагружать хранением данных на период оффлайн работы, от непустых очередей он начинает ощутимо притормаживать, да и долгий оффлайн сервера №1 приведет к OutOfMemory.

Я бы пристально посмотрел на средства потоковой обработки данных а-ля Kafka, но сам с ними близко не знаком. Попробуйте перезадать вопрос экспертам по этой теме.

Answer 2

[eRKa]

Не совсем понятно, зачем очередь на каждом компьютере? По сути очередь нужна только на компьютере №2. Все клиенты отправляют на него отчет, отчеты кладутся в очередь, компьютер №1 забирает их из этой очереди. И очередь для того и нужна, чтобы не зависеть, в сети ли компьютер №1. Все сообщения будут лежать в очереди, пока первый их не заберет. Если в течении какого то времени сообщение не забрали, клиенту дается ответ, что первый не доступен и клиент через таймаут шлет очередное сообщение.

Каждый клиент имеет свой идентификатор, каждый отчет свой идентификатор и если в очереди оказалось несколько сообщений от одного клиента и с одним идентификатором отчета, то учитывается последний по дате. Ну в принципе и все.

Comments

[Макс Максимов]

Для того, чтобы не тормозить работу других клиентов. Смотрите, у нас 100к клиентов, и каждый клиент должно обрабатываться параллельно, чтобы они не заставляли ждать друг друга, но при этом отчёты из одного клиента должны обрабатываться последовательно. Собственно поэтому и появился вариант с двумя очередями на каждый клиент. Хз как-то. Как с этим быть?

[Макс Максимов]

Но да, если сервер №1 сломан, то, по факту, все клиенты уйдут в оффлайн.

[eRKa]

Макс Максимов, Как часто будут отправляться отчеты с клиента? Даже если раз в час. И под это выделять отдельную очередь со своим обработчиком? Если конечно они будут слать каждую минуту и это все в реалтайме надо обработать, тогда согласен. Но Вы привели пример с компьютерным клубом, от этого и отталкиваюсь.
Но если все по уму, то рэбит должен справится с 100к сообщений в час в одной очереди, а обрабатывать эти сообщения уже параллельно. Но, конечно, если отчеты не мегабайтные.
Вы первым компом забрали пачку сообщений, допустим раз в минуту он забирает стопку. В этой стопке Вы можете все сообщения отсортировать и сгруппировать как угодно: по клиенту, по идентификатру отчета, по времени. И дальше уже обрабатывайте клиентов параллельно, отчеты последовательно.
Можно конечно для простоты обработки сделать очереди под районы или клубы, но суть не меняется.

[Макс Максимов]

eRKa, с каждого клиента отчёты будут приходить примерно 200-500 в минуту. И необходимо обрабатывать параллельно несколько клиентов, а отчёты от них -- последовательно. Не могу прийти к точке, где всё работает нормально, даже при условии, если поделить их на мелкие микросервисы. Потому что обслуживающий сервер №1 -- один на весь континент.

[eRKa]

Макс Максимов, Да, тогда нужно под каждого отдельная очередь. Но насколько помню, rabbit гарантирует доставку но не гарантирует очередность доставки. Значит нужно будет еще замарочиться буфером с сортировкой по дате, раз нужна последовательная обработка.

А зачем отдельно очередь для офлайна?

Я так понимаю, что обрабатывать отчеты может только комп №1, а второй только накапливать их от клиентов. И если первый отвалится, то ничего не поделаешь, все будет в офлайне. Но сообщения то теряться не будут и в конце концов первый их по любому заберет. А все распараллеливание обработки на первом компьютере.

Забирать сообщения надо только пачками, а не по одному обрабатывать, чтобы всегда понимать, очередь отчетов от одного клиента.

[Макс Максимов]

eRKa, в том-то и проблема, что мы не имеем доступа к серверу №1, а сообщение отправляет наш сервер №2. У этих свой API, и мы подстраиваемся под них.