А каким образом вдруг передача немаленького ЦФ через кролика становится быстрее ФТП?
Как правильно передавать CF в условиях РИБ
Мы точно единообразно понимаем как по РИБу правильно организовывать передачу CF в двух сценариях
- новый CF - новый узел
- обновление CF - обновление узла
Как мы помним - обновление CF узла вызывает необходимость зайти в Конфигуратор и применить изменения. Если мне память не изменяет.
Предлагаю поделиться сценариями кто как делает. Чтобы у всех было единое понимание и терминология
Иногда можно обойтись отвязкой от центра, обновлением, последующей привязкой.
А с каких пор по AMQP является транспортом для передачи файлов (я про CF)?
Я, возможно, сильно отстал и то-то изменилось за последние пару лет, но передавать большие данные и тем более хранить в очереди - плохая, не рекомендуемая практика.
Согласно best practices в очередь должно уходить сообщение со ссылкой на файл, который можно положить на тот же FTP или ссылкой на торрент и т.п.
1 Симпатия
Дык бспшный риб это делает автоматически.
нет, автоматически не делает, если его не просить или соглашаться с ним 
2 Симпатий
Формально не для файлов, а для paload https://stackoverflow.com/questions/22070639/sending-binary-file-through-rabbitmq
Самое веселое это вот это
тут еще веселей https://www.cloudamqp.com/blog/2017-12-29-part1-rabbitmq-best-practice.html
К вопросу о БестПрактикс. Решением фактически является - сжатие, а затем “сплит”, для последующего собирания из кусочков.
Исходя из вышесказанного - не передавать. РИБ - зло! Мы задумывали это дополнение к БСП, как именно средство транспорта данных при обмене. Отправка CF в узлы с целью обновления конфигурации - это вообще говоря, костыль. Попытка натянуть Continuous Delivery и прочий DevOps на глобус планов обмена. Поэтому, я и не люблю этот механизм.
Обновление конфигурации на распределенных узлах должно делаться средствами Ansible и иже с ним.
1 Симпатия
Ну тогда этот Риб/не риб это просто обмен по “звезде” между идентичными конфигурациями. Я конечно все равно никак не могу осознать, зачем мене нужен кролик, и чем еже пятисекундный запрос ФТП сервера на тему появления нового сообщения обмена медленнее, чем такой же опрос кролика.
Тем, что можно объявить доставку гарантированной и передавать в сообщении не все накопленные данные, а только изменившиеся с последнего пакета?
Так я с тем же успехом могу объявить надежным ФТП сервер, каждый узел будет удалять прочитанные им сообщения, читать только сообщение с номером N+1, а отправляющий соответственно будет формировать сообщение только из объектов, у которых не заполнен номер сообщения передачи.
Кто будет тратить ресурсы на создание/выдачу сообщений в каждый удаленный узел - сервер 1С или кролик, запущенный на том же сервере вроде должно быть не сильно принципиально. Особенно с учетом того, что при наличии фильтрации для каждого узла все равно сервер 1С будет готовить уникальное сообщение. Несколько подписчиков на одну очередь не получится.
Или выигрыш идет на уровне накладных расходов на хендшейки?
Выигрыш не в скорости по сути, а в гибкости. Да, можно использовать FTP. Совершенно никто не запрещает. Я не знаю, как ответить на вопрос, не написав полноценной статьи…
Всю ветку Огненный РИБ на базе YRMQ
и эту иже с ней идет разговор про скорость. (без фтп и фоновых заданий) И вдруг оказывается, что про гибкость.
Вы бы маркетинг в другой канал складывали. Где клиенты сидят, а не 1Сники. А то и “огненный РИБ” не про РИБ, и скорость это гибкость
Так - таймаут. Я про скорость, Андрей про гибкость.
Запишем видеоролик - станет все понятней.