#spring-boot #apache-kafka #rabbitmq
#весенняя загрузка #apache-kafka #rabbitmq
Вопрос:
Для моего проекта я должен создать файловый менеджер, предназначенный для хранения многих файлов (из многих мест) и предоставления URL для их загрузки.
В экосистеме микросервисов (я привык использовать spring boot) мне интересно, каков наилучший способ обмена такими файлами, я имею в виду отправку файлов в файловый менеджер?
С одной стороны, я всегда думал, что лучше обмениваться ими асинхронно, поэтому HTTP не кажется хорошим выбором. Но, возможно, я ошибаюсь.
Хороший ли выбор — разбивать файлы на фрагменты (чтобы уменьшить количество байтов для каждой части) и отправлять каждый из них через что-то вроде RabbitMQ или Kafka? Или мне лучше перенести целые файлы на NAS или через FTP и позволить файловому менеджеру обрабатывать их? Или что-то еще, например, хранение байтов во временной базе данных (возможно, не самый лучший выбор)…
Проблема фрагментации заключается в том, что я должен реализовать логику для сохранения сортировки каждого фрагмента, что усложняет обработку очередей тем.
Ответ №1:
IMO, никогда не отправляйте фактические файлы через посредник сообщений.
Сначала настройте какую-нибудь систему хранения объектов, например S3 (с AWS или локально с Ceph), затем отправьте путь к файлу в виде строки производителю, затем попросите потребителя прочитать этот путь и загрузить файл.
Если вы хотите собирать файлы с NAS или FTP, то Apache NiFi — это один из инструментов, который имеет соединители с подобными системами.
Комментарии:
1. Это то, что рекомендует команда инженеров RabbitMQ. Отправляйте файлы, используя что-то, предназначенное для отправки файлов, и используйте свой message broker для отправки URI в файл.
Ответ №2:
Основываясь на моем профессиональном опыте работы с распределенными системами (на основе JMS), для передачи огромного контента между участниками:
- для модели запрос — ответ управляющие сигналы следует использовать фрагментный подход (имеет следующий счетчик фрагментов)
- дельта-подход для обновлений.
Чтобы избежать повреждения данных, результат хэш-функции также может быть передан и проверен в обоих сценариях.
Но, как упоминалось в этой ветке электронной почты, лучшим подходом является использование FTP для такого рода сценариев:
RabbitMQ на самом деле не следует использовать для передачи больших файлов или только с большой осторожностью и фрагментацией файлов на отдельные сообщения меньшего размера.
При запуске одного экземпляра брокера вы по-прежнему будете в безопасности, но при кластерной настройке очень большие сообщения нарушат работу кластера. Кластеризованные узлы подключены через 1 tcp-соединение, которое также должно передавать сердцебиение (erlang). Если для передачи вашего большого сообщения между узлами требуется больше времени, чем время ожидания сердцебиения (где-то между ~ 20-45 секундами, если я прав), кластер сломается, и ваше сообщение будет потеряно. Предпочтительная архитектура для передачи файлов через amqp — это просто отправить сообщение со ссылкой на загружаемый ресурс и позволить передаче файлов обрабатываться специализированным протоколом, таким как ftp 🙂
Надеюсь, это поможет.
Комментарии:
1. Это интересный ответ. Но мне интересно, как это может работать в экосистеме микросервисов. В частности, когда служба файлового менеджера запускается с docker. Контейнер должен быть независим от физического сервера, на котором он выполняется. Итак, я не знаю, как я могу использовать FTP таким образом. Однако это открывает возможности для решения с общими томами…