よくある質問

マルチスレッドやマルチプロセスでジョブを実行することは可能ですか ?

これにアプローチするには 3 つの方法がありますが、そのような要件 (本当に必要か ? ) の分析には注意することをお勧めします。

  • TaskExecutor をステップに追加します。ステップを構成するために提供される `StepBuilder` には、設定できる "taskExecutor" プロパティがあります。これは、ステップが本質的に再起動可能 (事実上冪等) である限り機能します。並列ジョブのサンプルは、実際にどのように機能するかを示しています。これは、「プロセスインジケーター」パターンを使用して、ビジネストランザクション内で入力レコードを完了としてマークします。

  • PartitionStep を使用して、ステップの実行を複数の Step インスタンスに明示的に分割します。Spring Batch には、このための主要な戦略 (PartitionHandler) のローカルマルチスレッド実装があり、IO 集中型のジョブに最適です。このメソッドで実行するステップでは、ステートフルコンポーネントに必ず scope="step" を使用してください。これにより、ステップ実行ごとに個別のインスタンスが作成され、スレッド間のクロストークが発生しません。

  • spring-batch-integration モジュールに実装されている リモートチャンキングアプローチを使用します。これには、駆動ステップと リモートワーカー の間で信頼性の高い通信を行うための耐久性のあるミドルウェア (JMS など) が必要です。基本的なアイデアは、駆動プロセスで特別な ItemWriter を使用し、ワーカープロセスで ( ChunkProcessor 経由で) リスナーパターンを使用することです。

アイテムリーダーをスレッドセーフにするにはどうすればよいですか ?

read() メソッドを同期できます (たとえば、同期を実行するデリゲータでラップすることによって)。再起動可能性が失われるため、ベストプラクティスとしては、ステップを再起動不可としてマークし、安全 (かつ効率的) のためにリーダーに saveState=false を設定することもできます。

柔軟な戦略とデフォルトの実装の使用に関する Spring Batch の哲学は何ですか ? このプロパティまたはそのプロパティにパブリック getter を追加できますか ?

Spring Batch には、(ビジネスロジックの実装者ではなく) フレームワーク開発者向けの拡張ポイントが多数あります。クライアントが、コミット間隔 ( CompletionPolicy )、例外の処理方法に関するルール ( ExceptionHandler ) などの制御に組み込むことができる独自のより具体的な戦略を作成することを期待しています。

一般に、ユーザーがフレームワーククラスを継承することを思いとどまるように努めます。Java 言語では、クラスやインターフェースを内部としてマークする柔軟性があまりありません。一般に、パッケージ org.springframework.batch.* のソースツリーの最上位にあるものはすべてパブリックであると予想できますが、必ずしもサブクラス化できるわけではありません。ほとんどの戦略の具体的な実装を継承することは推奨されず、合成またはフォークのアプローチが推奨されます。コードで Spring Batch のインターフェースのみを使用できる場合、最大限の移植性が得られます。

Spring Batch と Quartz の違いは何ですか ? 解決策の中に両者の居場所はあるでしょうか ?

Spring Batch と Quartz ではゴールが異なります。Spring Batch は大量のデータを処理する機能を提供し、Quartz はタスクをスケジュールする機能を提供します。Quartz は Spring Batch を補完する可能性がありますが、テクノロジーを排除するものではありません。一般的な組み合わせは、Cron 式と Spring コアの便利な SchedulerFactoryBean を使用する Spring Batch ジョブのトリガーとして Quartz を使用することです。

Spring Batch でジョブをスケジュールするにはどうすればよいですか ?

スケジュールツールを使用します。そこにはたくさんあります。例: Quartz、Control-M、Autosys。Quartz は Control-M や Autosys のすべての機能を備えているわけではありません。軽量であることが想定されています。さらに軽量なものが必要な場合は、OS (cron、at など) を使用できます。

単純な順次依存関係は、Spring Batch のジョブステップモデルと Spring Batch の非順次機能を使用して実装できます。これは非常に一般的なことだと思います。そして実際、これにより、スケジューラのよくある誤用、つまり何百ものジョブが設定されており、その多くは独立しておらず、相互にのみ依存しているという問題を修正することが容易になります。

Spring Batch を使用すると、(並列処理などを通じて) プロジェクトのパフォーマンスとスケーラビリティをどのように最適化できますか ?

これは Job または Step のロールの 1 つであると考えられます。ステップの特定の実装は、ビジネスロジックを分割し、並列プロセスまたはプロセッサー間で効率的に共有するという関心事に対処します (PartitionStep を参照)。ここでロールを果たすことができるテクノロジーが数多くあります。本質は、一部のビジネス処理を処理できる分散エージェントへの一連の同時 リモート 呼び出しにすぎません。ビジネス処理はすでにモジュール化されているのが一般的であるため、たとえばアイテムを入力し、それを処理します。Spring Batch はさまざまな方法で配布の戦略を立てることができます。ある程度の経験を積んだ実装の 1 つは、ビジネス処理を処理する一連の リモート Web サービスです。入力の主キーの特定の範囲を、多数の リモート 呼び出しのそれぞれに送信します。同じ基本戦略は、実行層の構成を数行変更するだけで、Spring リモーティングプロトコル (プレーンな RMI、HttpInvoker、JMS、Hessian など) のいずれでも機能します。

バッチアーキテクチャを拡張するためにメッセージングをどのように使用できますか ?

既存のプロジェクトからは、バッチ処理へのパイプラインアプローチが非常に有益であり、回復力と高スループットにつながるという実践的な証拠が数多くあります。監査証跡が不可欠で保証された処理が要求される一方で、負荷時のパフォーマンスに非常に厳しい制限がある場合や、高いスループットが競争上の優位性をもたらすような、ミッションクリティカルなアプリケーションに直面することがよくあります。

Matt Welsh 氏の研究は、ステージドイベントドリブンアーキテクチャ (SEDA) には、より厳格な処理アーキテクチャに比べて多大な利点があり、メッセージ指向のミドルウェア (JMS、AQ、MQ、Tibco など) がすぐに多くの回復力を与えてくれることを示しています。下流段階と上流段階の間にフィードバックがあるシステムには特に利点があり、需要量に応じてコンシューマーの数を調整できます。では、これは Spring Batch にどのように適合するのでしょうか ? spring-batch-integration プロジェクトでは、このパターンが Spring Integration に実装されており、処理項目が多い任意のステップの リモート 処理をスケールアップするために使用できます。特に "chunk" パッケージと、その中の ItemWriter および ChunkHandler 実装を参照してください。