Java バッチ処理を簡単に…

今日、Apache Hadoop、Apache Kafka、Apache Spark などの分散リアルタイム処理フレームワークがもてはやされていますが、これらのフレームワークの使用方法は非常に簡単です。 これらのフレームワークは確立されたものであり、Facebook、Netflix、LinkedIn のような企業であれば必要不可欠ですが、開発者が本当に親しみやすいものではありません。 私自身は、同じビジネス プロセスで 1 テラバイト以上の関連データを持つ最初の顧客に会う必要があります。

すでに 2 回ほど、数 GB のデータに対して非常に難しい計算を行う必要がありました。 そして、これらのタイプの計算では、信頼性が高く、きれいなコードで仕事を終わらせるのを支援してくれる適切な Java フレームワークを見つけることができませんでした。

Spring Batch (私のお気に入りではありません) や Quartz もありますが、これらのフレームワークはすべてカスタム インターフェイスを実装しなければならず、私がバックグラウンドでいくつかの長時間実行するタスクを実行したいだけなのに、多くのオーバーヘッドを追加します。 例:

BackgroundJob.enqueue(() -> myService.doWork());

この 1 行のコードでは、ラムダ (型、メソッド、引数を含む) が永続ストレージ (Oracle, Postgres, MySql, MariaDB などの RDBMS またはまもなくサポートされる予定の NoSQL データベース) にシリアライズされることを確認します。 スレッドの専用ワーカー プールは、キューに入れられたバックグラウンド ジョブをできるだけ早く実行します。 来週ですか。 来月ですか?

BackgroundJob.schedule(() -> System.out.println("Reliable!"), now().plusHours(5));

定期的なジョブもかつてないほどシンプルになりました – JobRunr では、CRON 式を使用してあらゆる種類の定期的なタスクを実行できます。

シンプル：特別なインターフェースを実装したり、抽象クラスを拡張する必要がないため、あなたのコードはJobRunrにほとんど依存しません。 既存のサービスを変更せずに再利用できます。 利用するサービスが停止したり、ディスクが一杯になったり、SSL証明書が期限切れになったり……悪いことが起こります。 JobRunrが例外に遭遇した場合、デフォルトでは指数関数的なバックオフポリシーでバックグラウンドジョブを再スケジュールします。 バックグラウンドジョブが10回失敗し続けると、Failed状態になります。 その後、根本的な原因が解決されたときに、失敗したジョブを再キューすることを決定できます。

Transparent。 JobRunrには、ジョブを監視することができるダッシュボードが組み込まれています。

分散：ラムダまたはバックグラウンドジョブは、永続的なストレージにシリアライズされるので、バックグラウンドプロセスはJVM境界を越えて移動でき、これは分散処理を可能にします。 1.000.000のバックグラウンドジョブを処理する必要があるのでしょうか？ 一時的に追加のバックグラウンド・ジョブ・サーバー（例えば10台）を追加して、これらのジョブを処理できるようにすれば、総処理時間をほぼ10で割ることができます。

自己メンテナンス：手動でストレージのクリーンアップを行う必要はありません。