У нас есть случай использования, когда нам нужно обработать записи из таблицы (несколько миллионов), где обработка занимает больше времени, чем чтение, и в этой степени мы предпочитаем рабочий узел (принимающий фрагменты через шину событий) для его обработки ( у него будет доступ к той же базе данных, поскольку нам нужно несколько столбцов из других таблиц поиска / внешнего вызова apis для обработки записи) Дело в том, что некоторые из этих внешних вызовов api et c могут быть медленными, и мы не хотим тратить больше времени на устранение проблем с тайм-аутами, ограничением дроссельной заслонки и c ChunkMessageChannelItemWriter.
Также на рабочем узле простой компонент, управляемый Spring Message, может получать сообщение, обрабатывать его и отправлять ответ в очередь ответов . В этом случае рабочий не осведомлен о весенней партии. И worker, и master могут обновлять process_ind, чтобы отслеживать запросы in_flight. Слушатель очереди ответов может находиться на главном или в elswehere, где ему необходимо запустить последующее задание после агрегирования ответов.
Вышеуказанное требует отклонения от стандартные конструкции, используемые для удаленного разбиения на части, и хотелось бы знать, о каких недостатках мы должны помнить в этом подходе.