Почему я очень просто сломал RabbitMQ?

Question

[vaservaser]

Всем привет!
Почитал много хорошего про RabbitMQ и решил поставить на один из своих Ubuntu-серверов.
Установил, запустил, проверил, всё работает - принимает сообщения с других машин, и точно так же хорошо их отдаёт другим машинам. Вроде бы работает как надо.
Но потом я решил запустить python-скрипт, который отсылал в RabbitMQ сообщения (base64 в 100Кб) десятки раз в секунду.
Какое-то время всё работало - второй скрипт забирал сообщения из очереди, но периодически был фризы на 1-5 секунд. Потом всё опять работало.
И вот в какой-то момент всё сломалось. Второй скрипт перестал получать сообщения от RabbitMQ.
Захожу в веб-панель https://bla.bla.la:15672 чтобы посмотреть что там с кроликом и вижу сообщения о 500-х ошибках, панели управления нет - Rabbit не работает.
В общем, никак он не поднимается и дошло дело до полной его переустановки.
Вопро такой - неужели RabbitMQ настолько плох и такой ненадёжный, что ломается так просто? Это же его основная задача - принимать сообщения в очередь и отдавать их.
И тут на тебе, на ровном месте сломался, десятки сообщений в секунду обработать нормально не смог.

Answer 1

[sokoloid]

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

Comments

[vaservaser]

чтобы получить ссылку на файл, его сначала надо сохранить, а это медленная операция.
Предполагается нагрузка порядка 1000 таких запросов в секунду, или 10000.

Answer 2

[Иван Шумов]

Судя по другим комментариям вы используете кролика не по назначению. Message Broker так называется по тому что передает сообщения. Если вы хотите прислать сообщение о ресурсе то передавать надо только ссылку на него. Не городите огород

Comments

[vaservaser]

Хорошо. Как получить эту ссылку? Вот пользователь отправляет файл в API. Что делать с ним дальше?
10000 таких POST-запросов в секунду.

[Иван Шумов]

vaservaser, не загружайте вы кроликом файлы в AWS. Загружайте синхронно, в чем проблема? Это операция , требующая консистентности. Для чего вам тут кроль?

[vaservaser]

Иван Шумов, напрямую из API на NodeJs отправлять файлы в облако? Чувствую, что это довольно быстро загнётся

[Иван Шумов]

vaservaser,  если у вас есть необходимость разорвать связь то вы все-равно сохраняете файл на сервере (вероятнее всего) - используйте это как буфер и кидайте в кролика сообщение с этим путем. Проблем не будет, но встает другая интересная вещь - eventual consistency after write. Ваша система позволяет сохранять файл с задержкой относительно ответа клиенту?

[vaservaser]

Да, позволяет.
Схема приблизительно такая: клиент передаёт файлик на сервер, сервер его быстро принимает, в ответ быстро отдаёт сгенерированный ID этого файла, дальше какая-то ресурсоёмкая магия с этим файликом (обработка, сохранение).
При этом предполагается шардинг для возможности горизонтального масштабирования

[Иван Шумов]

vaservaser, ну, тогда сделайте файловый буфер. Учтите только что вы не гарантируете клиенту что файл действительно будет доставлен в ваше облако и обработан

Answer 3

[rino906]

Я бы не был так категоричен к кролику, возможно, он сломался из-за того что вы забили всю доступную оперативную память и не настроили ватермарки(по памяти, по диску) + из-за того что у вас довольно крупные сообщения вам потребуется настроить вытеснение сообщений из оперативной памяти на диск. При этом хочу отметить, что предложенный sokoloid вариант с сохранением файлов во временное хранилище является более надёжным

Comments

[vaservaser]

у меня как раз и стоит такая задача - быстро принять много файлов и сохранить их.
Как это решить?

[rino906]

простейший вариант:

1. принимаем файл от пользователя
   
2. складываем на локальный s3 в бакет #1 (minio - https://min.io/)
   
3. создаем запись в кролике со ссылкой на локальный s3
   
4. берем сообщение
   
5. скачиваем файл
   
6. обрабатываем файл
   
7. заливаем на локальный s3 бакет 2
   
8. через event механизм minio получаем в том же кролике сообщения о новых файлах локальном s3 бакет #2 и синхронизируем их в aws s3, после файлы можно удалять с локального s3
   

Answer 4

[Fixid]

Кролик на одной ноде не любит большие сообщения за короткий промежуток. Надо или тюнить или менять тип очереди.

Comments

[vaservaser]

А какая тогда замена кролику для моих задач? Я хочу отправлять порядка тысячи запросов в секунду по 100Кб в очередь и я хотел бы быть уверенным, что очередь на захлебнётся и нормально отдаст данные обработчикам.

[Fixid]

vaservaser, очередь должна быть с гарантированной доставкой? Для чего вобще нужна очередь?

[vaservaser]

Fixid, Есть множество клиентских приложений, они отсылают небольшие файлики на сервер через API (Nodejs), затем эти файлики отправляются в очередь RabbitMQ, чтобы обработчики забрали их, обработали если надо, и сохранили в облаке на AWS. Пользователи в дальнейшем могут пользоваться этими файликами.
Я хотел проверить кролика нагрузкой и он её не выдержал.
Если NodeJs будет сам обрабатывать файлы и сохранять в облаке, то очень быстро он загнётся. Даже если их несколько и они балансируются через Nginx.