Это насколько я понял из чтения документации, но я вполне мог ошибаться, в таком случае проголосуйте против, и я удалю этот ответ.
Документация о parallel
:
разделение данных на несколько «рельсов», соответствующих количеству ядер ЦП, циклическим способом.
Flux#parallel
вернет ParallelFlux
, который будет разделен на части любая работа над количеством так называемых rails
, которые будут распределять рабочую нагрузку циклически по количеству ядер компьютера. Вам гарантируется, что работа будет размещена на нескольких ядрах компьютера.
Документация по плоской карте:
Преобразуйте элементы, испускаемые этим Flux, асинхронно в Publishers, затем объединить этих внутренних издателей в единый поток посредством слияния, что позволяет им чередоваться.
Хотя flatMap
(и здесь я могу ошибаться) просто делает работу асинхронной, помещая все элементы по отдельности Mono<T>
и назначенные потоки будут переключаться между рабочими нагрузками, пытающимися выполнить рабочую нагрузку, и разрешать Mono<T>
s как можно быстрее, используя назначенные потоки в заданном планировщике. Здесь, похоже, нет гарантии, что будет использоваться несколько ядер.
Это я понял из чтения документации.
Распараллеливание работы с ParallelFlux
Flux # parallel
Flux # FlatMap
Мое личное мнение, что, вероятно, было бы излишним назначать собственное core для каждого запроса, вероятно, есть время на настройку, чтобы назначить задания ядрам et c. et c.
Я бы использовал параллельную работу только для интенсивной работы ЦП, в то время как обычный flatMap
отлично подойдет для blocking
задач, где потоки могут просто переключиться на другую работу, ожидая ответа .