この記事は、記事に基づいて 、実行にソースコードを解析XXLジョブ 解析
1.どのように派遣センターのフェールオーバー（フェイルオーバー）？
ステーションは、要求処理が完了し、通常のアクチュエータスケジューリング及び機械の自動切り替えをサポートするために失敗した場合、フェイルオーバーは、ディスパッチステージで実行され
まず、ときに、新しいスケジュールされたタスク、ルーティングポリシーをフェイルオーバ選択します。
ソースXxlJobTrigger processTrigger方法を行う場合、次のように：
私たちは、フェイルオーバーに対応する図は、赤い箱のフェイルオーバーで、ルーティングポリシーの多様性を見ることができます。
今processTrigger方法がダウンしていきソースに従います。
私たちは、それは我々がルートメソッドをExecutorRouteFailover来るルーティング戦略に応じてルーティング対応する結果が返されることがわかります。
IPアドレスがハートビート通信を行います、アドレスリストが自動的に上記のコードでアドレスリストのアドレスリストに基づいて、ブート時に派遣センターに登録し実行されます。
今、私たちは二つのアクチュエータIP1、IP2があることを前提としてい.. したがって、上述したサイクル二つ心拍IP1とIP2、心拍検出解析派遣センターに基づいて検出される送信方法を実行するための実際のRPC要求を知ることができるExecutorBizImplが上記操作ソースに応じて容器を倒す行います。
IPアドレスが正常心拍ReturnT.SUCCESS、その後、現在のリターンアドレスIP、IPアドレスを使用して実行するには、通常のスケジューリング要求を返された場合。すべての登録済みのIPアドレスハートビート検出に失敗した場合、のはprocessTrigger方法ダウンを見にいきましょう：
ハートビートの故障アドレスが空のIPすべてのアドレスが登録されている場合、その後triggerResult、XxlJobLogへの更新に対応する実行結果に失敗の結果を返します。
2.実装のタスクスケジューリング派遣センターの結果は対処することができませんでしたか？
派遣センターは、デーモンを起動したときスケジューリング失敗ログをリッスンするスレッドを開始します
2.1障害の再試行
私たちは下を見に失敗し再試行する方法をされ続けます
再試行の失敗回数が0より大きい場合、再スケジューリングに行くここで私は、反復その後、最初の負荷は、すべてのタスクスケジューリングログIDを失敗したことを見ることができます。
再試行は、新しいタスクを設定されています。
我々は（）log.getExecutorFailRetryCount再試行--1このパラメータが表示されます。これは、スケジューリングが失敗した場合に再試行回数が0以上になるまで、常にので、ディスパッチ障害リトライ機能を完了し、再試行されます再試行されます
2.2電子メール警告
電子メール・アラート機能で読みます
あなたが見ることができる場合は、電子メールの送信者と受信者の構成は、電子メール警告を行うことができるよう、そして複数の電子メール受信者のためにサポートします。次のように送信者が設定されています。
新しいタスクでの受信者を設定することができます。
電子メール警告が完了した後、結果はこのように電子メール警告機能を完了し、スケジュール・ログを更新するには、警告になります
3.または異常どのように対処するのタイムアウトのタスクを実行する実行しますか？
3.1アクチュエータタスクのタイムアウト処理機構
上記から明らかである、スケジューリングタスクは、最終的にJobThreadのスレッドに、triggerQueueトリガーキューを配置します。
JobThreadがどのように処理されるかを見て続行します。
タイムアウトが設定されている場合、新しいタスクが0より大きい場合、タスク処理スレッドは、triggerQueueから削除されます。
タスクが非同期的に実行されたときに得られた結果タイムアウトがTimeoutExceptionをスローした場合、その後FutureTaskは、タイムアウト期間内に結果を得るために使用されます
そしてexecuteResultに実行タイムアウトの結果を割り当て、非同期の割り込みは、最終的にはfutureThreadスレッドの結果を得ることができます。
3.2タスクの実行がスロー
例外がスローされた場合は、図のノウハウ、handler.executeタスクの実行は、executeResultに失敗の結果を代入します
3.3コールバック処理結果
最終的にはプロセスで、タスクの実行後に見て続行します。
ここでcallBackQueueコールバックキューに結果と関連するパラメータになり、コールバックキューは、アクチュエータハンドルガードが開始スレッドの消費が開始されます。
コールバックスレッドの処理方法で読みます：
ここでは、タスクがバッチから削除されますcallBackQueueコールバックキュー処理のために、上読んで：
ここでは、adminBizの初期化プロセスを見てadminBiz.callback方法を実行することになります。
：（理解していない、あなたが私の記事を参照することができますpsのは、我々は理解するであろう、上の画像を参照するにはGetObjectメソッドXXL-ジョブが実行するためにソースコードを解析し、この時を除き、今度はRPC要求である）、アクチュエータ→要求は、それがadminBiz.callbackコールバックメソッドがAdminBizImpl内部コントロール・センターを実行することになるスケジューラによって送信されました：
コールバックの詳細な実装プロセスで読みます：
あなたは成功したタスクの実行スケジュールを見ることができるとサブタスクにIDに対応するサブタスクを実行するように構成されますが（PS：子タスクIDは、新しいタスクの時に設定されている）、スケジュールされたタスクの実行には、（失敗した場合、すなわち、タイムアウトや異常）、上でお読みください。
タスクが失敗した場合、コードの実行結果の失敗は、障害情報の更新xxl_job_logテーブルに対応して、リスナーに上記の作業の障害によって、対応する再試行またはアラームを実行されることがわかります。これまでのところ、最初のミッションの結果は、プロセスを完了する予定
要約：
全体的XXL-ジョブがxxl_job_logへの異常な結果で実行した後、ハンドルの例外に失敗して、アラームの方法を再試行してデーモンスレッドを引き起こすJobFailMonitorHelperスケジューリングタスクを開始しています
