Różnica w partii sprężyny między Wielowątkowością a partycjonowaniem

Question

Nie mogę zrozumieć różnicy między wielowątkowością a partycjonowaniem w partii wiosennej. Wdrożenie jest oczywiście inne: w partycjonowaniu musisz przygotować partycje, a następnie je przetworzyć. Chcę wiedzieć, jaka jest różnica i która z nich jest bardziej efektywnym sposobem przetwarzania, gdy wąskie gardło jest procesorem przedmiotów.

Answer 1

TL; DR;
Żadne z tych podejść nie ma na celu pomóc w przypadku wystąpienia wąskiego gardła w procesorze. Zyskasz na tym, że wiele elementów przechodzi przez procesor w tym samym czasie, ale obie opcje, które wskazujesz, przynoszą pełne korzyści, gdy są używane w procesach związanych z wejściem/wyjściem. Opcja /// może być lepszym rozwiązaniem.

Przegląd Wiosna Batch Skalowalność
Istnieje pięć możliwości skalowania pracy Wiosna serii:

1. wielowątkowe krok
2. Równoległe kroki
3. działowe
4. Remote wyrwy
5. AsyncItemProcessor/AsyncItemWriter

Każda ma swoje zalety i wady. Omówmy każdy:

wielowątkowe krok
wielowątkowy krok wykonuje jeden krok i wykonuje każda porcja w tym kroku na osobnym wątku. Oznacza to, że te same wystąpienia każdego składnika wsadowego (czytniki, programy piszące itp.) Są współużytkowane w wątkach. Może to zwiększyć wydajność, dodając paralelność do kroku kosztem ponownego uruchomienia w większości przypadków. Poświęcasz możliwość ponownego uruchomienia, ponieważ w większości przypadków możliwość ponownego uruchomienia opiera się na stanie utrzymywanym w czytniku/programie piszącym/etc. Z wieloma wątkami aktualizującymi ten stan, staje się niepoprawny i bezużyteczny do ponownego uruchomienia. Z tego powodu zwykle trzeba wyłączyć stan składowania na poszczególnych komponentach i ustawić opcję wznowienia flagi na false w zadaniu.

Równoległe kroki
Równoległe kroki są realizowane poprzez podział. Umożliwia wykonywanie wielu niezależnych kroków równolegle za pośrednictwem wątków. Nie oznacza to rezygnacji ze wznowienia, ale nie poprawia wydajności pojedynczego kroku lub logiki biznesowej.

podziału
Partycjonowanie jest podziału danych, z góry na mniejsze kawałki (nazywane partycjami) według etapu głównego, a następnie o slave pracować niezależnie od przegród. W Spring Batch, zarówno master, jak i każdy slave, jest niezależnym krokiem, dzięki czemu można uzyskać korzyści z równoległości w jednym kroku bez rezygnacji z ponownego uruchamiania. Partycjonowanie zapewnia także możliwość skalowania poza pojedynczą maszynę JVM, ponieważ niewolnicy nie muszą być lokalni (do komunikacji ze zdalnymi urządzeniami podrzędnymi można używać różnych mechanizmów komunikacyjnych).

Ważną informacją na temat partycjonowania jest to, że jedyną komunikacją między urządzeniem nadrzędnym a urządzeniem podrzędnym jest opis danych, a nie samych danych.Na przykład master może nakazać procesowi slave1 przetwarzanie rekordów 1-100, slave2 w celu przetwarzania rekordów 101-200 itd. Master nie wysyła rzeczywistych danych, a jedynie informacje wymagane dla urządzenia slave w celu uzyskania danych, które ma przetwarzać . Z tego powodu dane muszą być lokalne dla procesów slave, a master może być zlokalizowany w dowolnym miejscu.

Remote wyrwy
Remote wyrwy pozwala skalować proces i ewentualnie logikę zapisu całej JVMs. W tym przypadku urządzenie master odczytuje dane, a następnie przesyła je przez przewód do urządzeń podrzędnych, w których są przetwarzane, a następnie albo zapisywane lokalnie do urządzenia slave, albo zwracane do urządzenia master w celu zapisywania lokalnego do urządzenia master.

Ważną różnicą pomiędzy podziałem i zdalnym wyrwy jest to, że zamiast opisem dzieje nad drutu, zdalne dzielenie na porcje wysyła rzeczywiste dane nad drutu. Zamiast pojedynczego pakietu, mówiącego o rekordach procesu 1-100, zdalne dzielenie będzie wysyłać rzeczywiste rekordy 1-100. Może to mieć duży wpływ na profil I/O kroku, ale jeśli procesor jest wystarczająco wąskim gardłem, może to być przydatne.

AsyncItemProcessor/AsyncItemWriter
Końcowy możliwość skalowania procesów Wiosna wsadowych jest połączenie AsyncItemProcessor/AsycnItemWriter. W takim przypadku AsyncItemProcessor opakowuje implementację ItemProcessor i wykonuje wywołanie do implementacji w osobnym wątku. Następnie AsyncItemProcessor zwraca Future, który jest przekazywany do AsyncItemWriter, gdzie jest rozpakowywany i przekazywany do implementacji delegata ItemWriter.

Ze względu na charakter danych przepływających przez tę opcję, niektóre scenariusze słuchacza nie są obsługiwane (ponieważ nie znamy wyniku połączenia ItemProcessor aż do wnętrza ItemWriter), ale ogólnie rzecz biorąc, mogą stanowić przydatne narzędzie do Równoległa logika ItemProcessor w pojedynczej maszynie JVM bez poświęcania możliwości ponownego uruchomienia.