Собственно изучаю аналоги/замены RabbitMQ прочих кафок

Вроде как режим хранения сообщений можно в памяти, на диске или mysql/postgres

любая стстема обмена сообщениями-это отдельное приложение,которое еще и администрировать и намтраивать нужно,а для 1с это все часто из пушки по воробьям.

(1) Таки на 1С есть уже система обмена сообщениями своя?

(2) сервер взаимодействий же.

(3) Это немного не то.
Речь про https://ru.wikipedia.org/wiki/Очередь_сообщений
Аля https://ru.wikipedia.org/wiki/Брокер_сообщений

имеет смысл когда 1 ко многим.
а 1к1 не очень. ибо отлаживать сложнее

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

в 1с схеме источник ждет подтверждения. в а очереди ничего не ждет

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

(8) >если придет 2,то 1 можно отбросить

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

(7) Гарантированная доставка решает, в жпо подтверждения.
Это совсем отличная от привычной типовым 1Сникам схема обмена.

В базах 1С есть тоже очереди, исходящих и входящих сообщений и есть сервер сообщений с очередями.
При записи 1С пишет сообщения в свою очередь исходящих, затем оно висит там пока гарантированно не уйдет в брокер.
Далее брокер держит сообщение у себя, дублируя/перенаправляя их нужным получателям.
Затем каждая 1С получатель забирает сообщения по очереди из брокера и помещает их в свою входящих.
Далее из своих входящих обрабатывает (записывает в нужные объекты создавая/обновляя их) и только затем удаляя из своей очереди.

Короче подтверждения на каждом этапе а не всего одно.
База 1С которая отправила сообщение не ждет подтверждений от каждого получателя, снимает с себя как оно ушло в брокер.

Это единственная вменяем работающая механизма на больших объемах и распределенной структуре.

(6) Если ошибка на любом этапе то можно посмотреть на это зависшее сообщение.
Не ушло от 1С источника.
Или пришло в 1С получатель но не обработалось (на создался или не обновился объект 1С) - смотрим в очередь входящих и разбираемся что не так.

Т.е. всегда понятна кто виноват а не как с типовым обменом например УТ11-БП3 где уй знает кто виноват когда упало после обновления баз.

(11)+ И да сообщение это json описание одного объекта, сериализованное.
А не как в типовой синхронизации 1С где сообщение (пакет данных) это куча объектов разом.

как гарантированная доставка решит вопрос, если объект нужно перевыгрузить?

(13) а никак
если объект нужно переотправить,то это будет еще одно сообщение.
если сообщение не обработалось,то оно торчит в очереди,и его можно обработать еще раз.

гарантированная доставка,на самом деле,никакая не гарантированная,просто,если сообщения не доставляются,то проблема в отсутствии связи.

на самом деле,в стандартных обменах все еще проще,так как никакой очереди нет,так как каждый раз выгружается все,что готово к выгрузке и не помечено полученным.
но,1с не умеет подтверждать получение каждого объекта,а также ввгружает состояние объекта на момент выгрузки,а не на момент изменения,что в случае нескольких получателей может приводить к волнам обмена и прочим прелестям,которые очень сложно выявить и исправить,не переписывая полностью модель обмена.

при желании,сообщения можно хранить в базе 1с и ее же и использовать как брокера,то есть повторить полностью функционал стандартного брокера-он даже проще,чем обмен 1с,но,возникает вопрос,а надо ли?

зачем нам сейчас пилить велосипед, когда вендор скоро выдаст мотик?
не порше конечно, но вам ехать или шашечки?

(15) А хотя бы примерные сроки выпуска мотика с завода?