Цитата:
Сообщение от
mazzy
а кто-то говорил "одним куском"?!
Ну вот же 2-я опция из 3-х в исходном сообщении
Цитата:
Сообщение от
mazzy
передавать по одном элементу - слишком много накладных расходов.
передавать всю коллекцию - в момент передачи все это богатство превратится в XML и разорвет все внутренние буфера.
делить на чанки и передавать чанками по несколько сотен элементов - надо возиться и тоже никакой гарантии, что не разорвет внутренние буфера.
Цитата:
Сообщение от
mazzy
собственно тема КАК правильно решить на местах?
Если речь про разбивку 100500 сообщений на пачки, то - принимать во внимание имеющиеся ограничения в ядре и смотреть по опыту, какой размер лучше подходит в рамках имеющихся ограничений. Поскольку неизвестно, что именно за данные надо передавать и как обрабатывать на принимающей стороне, то сложно тут придумать что-то универсальное на все случаи жизни.
Если уж говорить про "ручную" разбивку сообщений на пачки, то можно пойти таким путем. Допустим, ограничение, которое мы хотим "соблюсти", - это заранее известный размер буфера сериализованных сообщений на принимающей стороне, при этом размеры отдельных сообщений нам заранее неизвестны. Выходит, нам надо
адаптивно менять размер пачки так, чтобы он каждый раз был максимально близок к размеру буфера (ограничению), но не превышал его. Под такие требования подходит вариант, реализованный в 12-ке для разноски журналов ГК с распараллеливанием в пакетном режиме. Там аналогично попытались соблюсти баланс между распараллеливанием разноски и накладными расходами, связанными с большим числом пакетных задач.
Суть подхода в том, что есть "сборщик" условных пачек, которому по одному за раз подаются элементы (журналы для разноски или сообщения в нашем случае). Сборщик принимает решение, добавить очередной элемент в текущую пачку или же завершить ее формирование и добавить очередной элемент уже в новую пачку. В случае журналов ГК сборщик смотрит на суммарное количество строк журналов в текущей пачке - эти журналы будут
последовательно разноситься в
одной пакетной задаче. В случае пакетирования сообщений сборщик может смотреть на суммарный размер сериализованных сообщений в текущей пачке с учетом ограничения на размер буфера и условного размера закрывающих XML-тегов для пачки. Такой подход обычно работает более гибко, чем грубое поштучное деление сообщений на пачки.
Цитата:
Сообщение от
mazzy
для начала какую именно технологию ты называешь асинхронным обменом?
Асинхронным я называю обмен, который позволяет системе-отправителю не ждать ответа системы-получателя (этот ответ при необходимости может быть получен в другое время), а системе-получателю позволяет обрабатывать входящие сообщения в отложенном режиме и с той скоростью, которая комфортна системе-получателю, а не системе-отправителю. Это подразумевает, что:
- сообщения обычно обрабатываются медленнее либо с меньшим параллелизмом, чем формируются и отправляются
- желательно сгладить для системы-получателя пиковые нагрузки и/или управлять ресурсами, выделяемыми на обработку того или иного типа сообщений
- если система-получатель недоступна на момент отправки сообщения, это не должно быть препятствием для системы-отправителя
- между отправителем и получателем есть некая буферная система (stream, очередь, брокер сообщений, как угодно).
подразумевается, что буферная система:
- способна принимать сообщения заведомо быстрее, чем они формируются системой-отправителем
- обеспечивает более высокую доступность своих сервисов, чем система-получатель
- обладает достаточными ресурсами для накопления передаваемых сообщений в случае пиковых нагрузок или недоступности системы-получателя
- может поставлять данные (счетчики производительности) для систем мониторинга
- в качестве бонуса позволяет сохранять передаваемые сообщения для разбора полетов и т.п.
С некоторой натяжкой в качестве буферной системы можно рассматривать файл-сервер
Но мне в последнее время, особенно на всяких там "сложных ИТ-ландшафтах" импанируют RabbitMQ и Kafka. Они позволяют реализовать своего рода амортизаторы между разными системами, особенно когда системам выделены разные ресурсы, возможны пиковые нагрузки, периоды недоступности и т.п.