JP6847112B2 - ノードの再起動後にデータを処理する方法及びデバイス - Google Patents

Description

本開示は、通信技術の分野に関し、特に、ノードの再起動後にデータを処理する方法に関する。本開示は、また、データ処理デバイスに関する。

インターネット技術の継続的な発展とともに、クラウドプラットフォームとも呼ばれるクラウドコンピューティングプラットフォームは、ますます注目されてきている。クラウドプラットフォームは、機能に応じて３つのカテゴリ、主にデータストレージ用のストレージクラウドプラットフォーム、主にデータ処理用のコンピューティングクラウドプラットフォーム、ならびにコンピューティング及びデータストレージ処理双方のための包括的クラウドコンピューティングプラットフォームに分類され得る。クラウドプラットフォームは、開発者が、クラウド内で書かれたプログラムを実行すること、もしくはクラウド内で提供されるサービスを使用することのいずれか、またはその両方を可能にする。

図１は、従来技術による、クラウドプラットフォームのリアルタイムモニタリングサービスのアーキテクチャ設計の概略図である。クラウドプラットフォームログサービスのアーキテクチャ設計は、通常、５つのレイヤ、（ログ）収集レイヤ、（ログ）移送レイヤ、処理レイヤ、記憶レイヤ、及びモニタリングセンタに分割される。収集レイヤは、ユーザの様々なログを読み出し、次いで、記憶する必要があるログを移送レイヤに送信することを担当する。図１に示す従来技術による、クラウドプラットフォームのログサービスの概略的アーキテクチャ図では、レイヤの機能は、既存のクラウドサービス機能と組み合わせて様々なエージェントによって実装される。エージェントは、全レベルにおいて物理マシンまたは仮想マシン上に配備されて、ルールによりユーザのログを読み出し、ログを送信する。処理レイヤは、概して、複数のスケーラブルなワーカノード（図２における処理ワーカ）から構成され、移送レイヤからログを受信し、ログを処理し、様々な記憶デバイス内にログを記憶することを担当する。処理ワーカは、本質的には、システムプロセスであり、システムプロセスはステートレスであり、水平スケールされ得る。ログの順序が保証され得るかどうかは、処理レイヤのロジックに密接に関連する。記憶レイヤは、データストレージを担当し、物理ディスク、または分散型ファイルシステムによって提供される仮想ディスクであってもよい。移送レイヤは、収集レイヤと処理レイヤの間に位置し、ログが処理レイヤに送信されるのを保証することを担当する。移送レイヤは、概して、冗長性をもたらすメッセージキューによって実装され、ヒープを用いて実装されてもよく、収集レイヤと処理レイヤの間のブリッジの役割をする。記憶レイヤは、データストレージを担当する。モニタリングセンタは、アクセスレイヤを含む。アクセスレイヤには、統合されたデータアクセスインタフェースを外部に提供するための、専用アクセスＡＰＩが提供される。

リアルタイムモニタリングサービスは、リアルタイム性能に関してより高い要件を有し、概して、モニタリング遅延が５分未満であり、１分あたり１つのモニタリングデータであることを要する。このような高いリアルタイム要件の下では、システム再起動中に、（モニタリング曲線が、不安定過ぎることなく、いかなる損失点も有しないことを少なくとも保証するために）どのようにしてデータの損失及び重複を出来る限り防止するかが、技術的な問題である。最も重大な課題は、ステートフルノードの再起動ポリシー、即ち、リアルタイムコンピューティングシステムにおける処理ノードの再起動である。

ノードの再起動によって生じるモニタリング曲線のジッタの問題を回避するために、従来技術は、主に、以下の３つの方法を採用している。
（１）データリプレイ
この方法は、再起動中にメッセージキューの最初の数分においてデータをリプレイし、データが喪失していないことを保証する。
（２）永続的中間状態
この方法は、統計状態を永続的データベースに周期的に保存し、再起動中にその状態を復元する。
（３）２つのデータの同時処理
この方法は、メッセージキューが複数の消費者をサポートする特性に従って、２つのリアルタイム計算タスクを同時に実行する。１つのリアルタイム計算タスクが再起動されるとき、他のリアルタイム計算タスクのデータが使用され、次いで、方法は、再起動後に、再起動された計算タスクに切り戻しする。

しかしながら、本開示を実施するプロセスにおいて、発明者は、従来技術が以下の欠点を有することを発見した。
（１）データリプレイは、データ重複を容易にもたらし、メッセージキューに依存する。データ処理は、複数のデータ記憶手続を伴うことが多く、例えば、それは、ＭｙＳＱＬメタデータを更新し、生データをＨａｄｏｏｐに記憶する必要がある。この場合、データリプレイは、記憶したデータのうちのいくつかの重複をもたらすとみられる。さらに、データリプレイは、Ｋａｆｋａなどのメッセージキューのリプレイ機能に依存するが、ＯＮＳはそれをサポートしていない。
（２）永続的中間状態は、スケーリング及びアップグレードに適しておらず、論理的に複雑である。多くの状況下において、システム再起動は、スケーリングまたはシステムアップグレードのために実施され、各処理ノードが担当するデータは、スケーリング後に変化することになり、元の中間状態とは整合しなくなる。アップグレードもまた、中間状態の間に不整合をもたらし得る。さらに、永続化及び回復のロジックは、計算が複雑であるとき、多くの中間状態を伴い比較的複雑である。
（３）２つのデータを同時に処理することは、過剰なコストがかかり、より多くの計算リソース及び記憶リソースを必要とする。処理されるデータの量が多くなればなるほど、より多くの無駄が生じる原因となる。

したがって、ハードウェアリソースの消費を減少させつつ、ノード再起動によって引き起こされるデータ処理の遅れの問題をいかにして出来る限り回避するかが、当業者によって解決されるべき緊急の技術的問題であることは、明白である。

本開示は、ノードの再起動後にデータを処理する方法を提供して、ハードウェア修正のためのコストを減少させつつ、ノード再起動によって引き起こされるデータ処理の遅れの問題を回避する。方法は、分散型メッセージキュー及び処理ノードを含むデータ処理システムに適用され、以下のステップ、
処理ノードによって、処理ノードの再起動が完了した後で、分散型メッセージキュー内の最長キャッシュ時間を有する現在のレガシーデータの時点を取得することと、
処理ノードによって、現在時点及びレガシーデータの時点に従って、回復サイクルを決定することと、
処理ノードによって、レガシーデータ、及び回復サイクル内に分散型メッセージキューに新規追加されたデータを処理することと、を含む。

好ましくは、データ処理システムが、記憶ノードをさらに含み、処理ノードの再起動が完了する前に、方法が、
処理ノードによって、計算タスクを終了する命令を受信することと、
処理ノードによって、分散型メッセージキューからデータを受信すること、及びデータの処理完了時に、処理ノード内に現在キャッシュされているデータを記憶ノードに書き込むことを中断することと、をさらに含む。

好ましくは、処理ノードによって、現在時点及びレガシーデータの時点に従って、回復サイクルを決定するステップは、特に、
最長キャッシュ時間を有するレガシーデータに対応する時点から現在時点までの時間長を取得することと、
時間長と一致する時間長を有する回復サイクルを生成することと、を含む。

好ましくは、処理ノードによって、レガシーデータ、及び回復サイクル内に分散型メッセージキューに新規追加されたデータを処理するステップは、特に、
回復サイクルの単位時間長に従って、複数の処理時間ピリオドを逐次的に設定すること、ならびにレガシーデータ及び新規追加されたデータに基づいて、処理時間ピリオドのそれぞれに処理対象データを割り当てることと、
それぞれの処理時間ピリオド内に、対応する処理対象データを処理すること、及び回復サイクル終了後に、計算タスクを通常の処理ロジックに回復させることと、を含む。

好ましくは、処理時間ピリオドが、データ処理時間及びデータ同期時間で順番に構成され、それぞれの処理時間ピリオド内に、対応する処理対象データを処理するステップは、特に、
データ処理時間内に処理対象データを処理すること、及びデータ処理時間終了後に、処理された処理対象データを記憶することと、
データ処理時間終了後、処理されなかった処理対象データが存在する場合に、処理されなかった処理対象データを、データ同期時間内に破棄することを含む。

これに対応して、本開示は、データ処理デバイスをさらに提供し、分散型メッセージキュー及び処理ノードを含むデータ処理システムに処理ノードとして適用される。データ処理デバイスは、
再起動が完了した後で、分散型メッセージキュー内の最長キャッシュ時間を有する現在のレガシーデータの時点を取得するように構成される取得モジュールと、
現在時点及びレガシーデータの時点に従って、回復サイクルを決定するように構成される決定モジュールと、
レガシーデータ、及び回復サイクル内に分散型メッセージキューに新規追加されたデータを処理するように構成される処理モジュールと、を含む。

好ましくは、データ処理システムは、記憶ノードをさらに含み、データ処理デバイスは、
計算タスクを終了する命令を受信し、分散型メッセージキューからデータを受信すること、及びデータの処理完了時に、データ処理デバイス内に現在キャッシュされているデータを記憶ノードに書き込むことを中断するように構成される、終了モジュールをさらに含む。

好ましくは、判断モジュールは、特に、
最長キャッシュ時間を有するレガシーデータに対応する時点から現在時点までの時間長を取得するように構成される取得サブモジュールと、
時間長と一致する時間長を有する回復サイクルを生成するように構成される生成サブモジュールと、を含む。

好ましくは、処理モジュールは、特に、
回復サイクルの単位時間長に従って、複数の処理時間ピリオドを逐次的に設定し、レガシーデータ及び新規追加されたデータに基づいて、処理時間ピリオドのそれぞれに処理対象データを割り当てるように構成される、設定サブモジュールと、
それぞれの処理時間ピリオド内に、対応する処理対象データを処理するように構成される処理サブモジュールと、
回復サイクル終了後に、計算タスクを通常の処理ロジックに回復させるように構成される、回復サブモジュールと、を含む。

好ましくは、処理時間ピリオドは、データ処理時間及びデータ同期時間で順番に構成され、処理サブモジュールは、特に、
データ処理時間内に処理対象データを処理し、データ処理時間終了後に、処理された処理対象データを記憶し、
データ処理時間終了後、処理されなかった処理対象データが存在する場合に、処理されなかった処理対象データを、データ同期時間内に破棄するように構成される。

本開示の技術的解決策から分かるように、処理ノードは、処理ノードの再起動が完了した後で、分散型メッセージキュー内の最長キャッシュ時間を有する現在のレガシーデータの時点を取得し、現在時点及びレガシーデータの時点に従って、回復サイクルを決定し、レガシーデータ、及び回復サイクル内に分散型メッセージキューに新規追加されたデータを処理する。したがって、再起動から生じるデータ処理の割り込みが回避されてもよく、ユーザの感情に対する影響が除去されてもよく、ユーザエクスペリエンスが改善される。

従来技術におけるクラウドプラットフォームのリアルタイムモニタリングサービスの、概略的なアーキテクチャ図である。 本開示による、ノードの再起動後にデータを処理する方法のフローチャートである。 本開示の特定の例としての実施形態による、回復サイクル内のデータ処理の概略図である。 本開示による、データ処理デバイスの概略的な構造図である。

従来技術における問題の点から見て、本開示は、ノードの再起動後にデータを処理する方法を提供する。方法は、分散型メッセージキュー及び処理ノードを含むデータ処理システムに適用されて、データ処理システム内の処理ノードが何らかの理由で再起動される際に生じるデータ処理の割り込みによって、ユーザの感情が影響を受けるという問題を回避する。データ処理システムは、従来技術におけるリアルタイムモニタリングシステム、またはユーザログ記録システムであってもよいことに留意すべきである。これに基づいて、当業者は、本開示の解決策を、データに関するリアルタイム処理要件を有する他のシステムにも適用してもよく、そのような適用もまた、本開示の保護範囲に属するものとする。

図２に示されるように、方法は、以下のステップを含む。

Ｓ２０１．処理ノードが、処理ノードの再起動が完了した後で、分散型メッセージキュー内の最長キャッシュ時間を有する現在のレガシーデータの時点を取得する。

リアルタイムでデータを処理するための現在のデータ処理システムでは、処理ノードが、デバイスそれ自体または人為的な原因のために、再起動される必要があることがよくある。処理ノードは、通常単一のデータ処理デバイス、または複数のデータ処理デバイスの論理和であるため、処理ノードは、再起動中にそれと接続される分散型メッセージキューからデータを適時に取ることができないことが多い。それによって、メッセージキュー内に処理対象データのレガシーがもたらされる。したがって、処理ノードの再起動が完了したとき、再起動プロセスにどのくらい時間がかかるかが、メッセージキュー内の最古データの時点と、現在時点とを比較することによって判断され得る。このステップにおける最長キャッシュ時間を有するレガシーデータの時点は、キャッシュされたデータが生成された時点に設定されてもよく、または処理ノードがキャッシュされたデータを取得すべき時点に設定されてもよいことに、ここで留意すべきである。処理ノードが再起動期間を決定し得るという前提で、異なる状況について異なる時点を設定することは、本開示の保護範囲に属する。

さらに、処理ノードがメッセージキューからのデータ取得を中断してから、正式な再起動までに時間ピリオドがしばしば存在し、その間、処理ノードそれ自体が、メッセージキューから以前に取得した何らかのデータをやはりキャッシュする。したがって、処理ノードが、データ受信機能を終了しつつ、タイムアウトの場合に損失なく、処理ノードにキャッシュされたデータを自動的に保存し得ることを保証するために、本開示の好適な例としての実施形態では、計算タスクの終了命令を受信した後（命令は、処理ノードの状態に従ってシステムにより自動的に送信されてもよく、または手動で送信されてもよい）、処理ノードは、一方では分散型メッセージキューからのデータ受信を中断し、他方では、データの処理完了時に、処理ノードに現在キャッシュされているデータを現在のデータ処理システム内の記憶ノードに書き込んで、キャッシュされたデータの自動保存を達成する。

本開示の特定の例としての実施形態では、まず、終了命令が、処理ノードのリアルタイム計算タスクにシステムを通じて送信される。計算タスクは、命令受信後、終了状態に入り、メッセージキューからのメッセージの受信を中断する。処理ノードは、キャッシュされたデータを処理し続け、次いで、計算結果のタイムアウトを待って、データを記憶サービスに自動的に書き込む。リアルタイム計算は、時間ピリオドの間新規データが全くない状況での処理を意味し、時間ウィンドウが超過する際に計算結果を自動保存するメカニズムが存在することになる。したがって、処理されたデータは、このステップを通じて永続的であってもよく、したがって、それは中間状態の保存及び回復を必要としない。

Ｓ２０２．処理ノードが、現在時点及びレガシーデータの時点に従って、回復サイクルを決定する。

Ｓ２０１におけるレガシーデータの時点に基づいて、本開示の好適な例としての実施形態では、最長キャッシュ時間を有するレガシーデータに対応する時点から現在時点までの時間長が取得され、その時間長に一致する時間長を有する回復サイクルが生成される。

例えば、処理ノードのタスクが再起動された後、処理ノードは、メッセージキュー内のデータ時間とシステム時間との差を比較し、データ回復サイクルを設定することになる。例えば、データ時間が１２：０２：１０であり、現在時間が１２：０４：０８である場合、タスクを終了し、開始の間タスクを初期化するのに約２分かかっており、２分間のデータ処理が巻き返される（catch up）必要があることを示している。例えば、２分の回復サイクルは、データサイズと処理ケイパビリティとの均衡がとれた後で設定されてもよい。タスクをオフにし、開始することにより消費される時間、及びデータを巻き返すための時間は、５分以内であるべきであり、そうでなければ、データ遅延が５分を超えることになる。

Ｓ２０３．処理ノードが、レガシーデータ、及び回復サイクル内に分散型メッセージキューに新規追加されたデータを処理する。

回復サイクルが決定された後、処理ノードは、続いて、サイクル内においてデータの２つのバッチを同時に処理する必要がある。１つは、メッセージキュー内のレガシーデータであり、もう１つは、サイクル内にメッセージキューに新規追加されたデータである。データの２つのバッチを順番に処理するために、本開示の好適な例としての実施形態では、複数の処理時間ピリオドが、まず、回復サイクルの単位時間長に従って、逐次的に設定され得る。次いで、処理対象データが、レガシーデータ及び新規追加データに基づいて、処理時間ピリオドのそれぞれに割り当てられる。このプロセスでは、レガシーデータ及び新規追加データは、互いに混合されて、処理時間ピリオドに均等に分散されてもよく、または、カテゴリに従って、異なる処理時間ピリオドに対して別々に割り当てられてもよい。２つの実施態様の双方が、本開示の保護範囲に属する。

対応する処理対象データが、処理時間ピリオドのそれぞれに割り当てられた後、この例としての実施形態では、対応する処理対象データが、それぞれの処理時間ピリオド内に処理され得る。計算タスクは、回復サイクル終了後、通常の処理ロジックに回復され得る。このようにして、処理ノードが再起動された後のデータ処理のシームレスな接続が完了する。

さらに、処理ノードが、各処理時間ピリオド内にデータ処理を効率的に完了することを可能にするために、本開示の好適な例としての実施形態では、処理時間ピリオドは、データ処理時間及びデータ同期時間に分割され、その２つが、順番に（データ処理時間−データ同期時間）形成される。対応する処理対象データが、各処理時間ピリオド内に処理されるとき、処理対象データが、まず、データ処理時間内に処理され、データ処理時間終了後、処理された処理対象データが記憶される。次いで、データ処理時間終了後、処理されなかった処理対象データが存在する場合に、処理されなかった処理対象データは、データ同期時間内に破棄される。

このステップにおいて、Ｓ２０２における特定の例としての実施形態、及び例として図３に示されるデータ処理の概略図におけるデータを使用することによって、処理ノードは、２分以内に４分間分のデータを巻き返す必要がある。したがって、特定の例としての実施形態では、２分が、４つの部分に均等に分割され、次いで、各部分が、比率に従ってデータ処理時間と同期時間に分割される。処理時間内に、対応する分におけるデータが処理され、その結果が記憶される。同期時間内に、現在の分におけるデータが、素早く破棄され、処理ノードは、次の分における処理に同期される。

処理ノードの再起動前後の一連の動作に基づいて、ノード再起動からもたらされるデータ処理の割り込みによって引き起こされ得るユーザの感情に対する影響が回避され、ユーザエクスペリエンスが改善される。

前述の技術目的を達成するために、本開示は、データ処理デバイスをさらに提供し、データ処理デバイスは、分散型メッセージキュー及び処理ノードを含むデータ処理システムに処理ノードとして適用される。図４に示すように、データ処理デバイスは、
再起動が完了した後で、分散型メッセージキュー内の最長キャッシュ時間を有する現在のレガシーデータの時点を取得するように構成される取得モジュールと、
現在時点及びレガシーデータの時点に従って、回復サイクルを決定するように構成される決定モジュールと、
レガシーデータ、及び回復サイクル内に分散型メッセージキューに新規追加されたデータを処理するように構成される処理モジュールと、を含む。

好適な例としての実施形態では、データ処理システムは、記憶ノードをさらに含み、データ処理デバイスは、
計算タスクを終了する命令を受信し、分散型メッセージキューからデータを受信すること、及びデータの処理完了時に、データ処理デバイス内に現在キャッシュされているデータを記憶ノードに書き込むことを中断するように構成される、終了モジュールをさらに含む。

好適な例としての実施形態では、決定モジュールは、特に、
最長キャッシュ時間を有するレガシーデータに対応する時点から現在時点までの時間長を取得するように構成される取得サブモジュールと、
時間長と一致する時間長を有する回復サイクルを生成するように構成される生成サブモジュールと、を含む。

好適な例としての実施形態では、処理モジュールは、特に、
回復サイクルの単位時間長に従って、複数の処理時間ピリオドを逐次的に設定し、レガシーデータ及び新規追加されたデータに基づいて、処理時間ピリオドのそれぞれに処理対象データを割り当てるように構成される、設定サブモジュールと、
それぞれの処理時間ピリオド内に、対応する処理対象データを処理するように構成される処理サブモジュールと、
回復サイクル終了後に、計算タスクを通常の処理ロジックに回復させるように構成される、回復サブモジュールと、を含む。

好適な例としての実施形態では、処理時間ピリオドは、データ処理時間及びデータ同期時間で順番に構成され、処理サブモジュールは、特に、
データ処理時間内に処理対象データを処理し、データ処理時間終了後に、処理された処理対象データを記憶し、
データ処理時間終了後、処理されなかった処理対象データが存在する場合に、処理されなかった処理対象データを、データ同期時間内に破棄するように構成される。

上記実施態様の説明から、当業者は、本発明が、ハードウェアによって実施されてもよく、またはソフトウェアに加えて必要な汎用のハードウェアプラットフォームによって実施されてもよいことを、明確に理解し得る。このような理解に基づいて、本発明の技術的解決策は、ソフトウェア製品の形態で実施されてもよい。ソフトウェア製品は、不揮発性記憶媒体（ＣＤ−ＲＯＭ、ＵＳＢフラッシュディスク、リムーバブルハードディスクなどであり得る）に記憶されてもよく、コンピュータデバイス（パーソナルコンピュータ、サーバ、ネットワークデバイスなどであり得る）に、本発明の様々な実施態様シナリオにおいて説明される方法を実行するように命令するための複数の命令を含む。

当業者は、添付図面が単なる好適な実施態様シナリオの概略図であり、添付図面中のモジュールまたは手続が、本発明を実施するのに必ずしも必須ではないことを理解し得る。

当業者は、実施態様シナリオ中の装置内のモジュールが、実施態様シナリオの説明に従って実施態様シナリオ中の装置内に分散されてもよく、または、実施態様シナリオ中のものとは異なる１つもしくは複数の装置内において、それに対応して変更され位置していてもよいことを、理解し得る。実施態様シナリオ中のモジュールは、１つのモジュールへと結合されてもよく、または複数のサブモジュールにさらに分割されてもよい。

本発明の連続番号は、単に、説明の便宜上のためであり、実施態様シナリオ間の優先度を示唆するものではない。

上記開示は、単に、本発明の複数の特定の実施態様シナリオであるが、本発明は、これらに限定されない。当業者が想到し得るいかなる変更も、本発明の保護範囲内に入るものとする。

Claims (10)

1. ノードの再起動後にデータを処理する方法であって、前記方法は、分散型メッセージキュー及び処理ノードを備えるデータ処理システムに適用され、
   前記処理ノードによって、前記処理ノードの再起動が完了した後で、前記分散型メッセージキュー内の最長キャッシュ時間を有する現在のレガシーデータの時点を取得することと、
   前記処理ノードによって、現在時点及び前記レガシーデータの前記時点に従って、回復サイクルを決定することと、
   前記処理ノードによって、前記レガシーデータ、及び前記回復サイクル内に前記分散型メッセージキューに新規追加されたデータを処理することと、を含む、方法。
2. 前記データ処理システムが、記憶ノードをさらに備え、前記処理ノードの前記再起動が完了する前に、前記方法が、
   前記処理ノードによって、計算タスクを終了する命令を受信することと、
   前記処理ノードによって、前記分散型メッセージキューからデータを受信すること、及び前記データの処理完了時に、前記処理ノード内に現在キャッシュされているデータを前記記憶ノードに書き込むことを中断することと、をさらに含む、請求項１に記載の方法。
3. 前記処理ノードによって、前記現在時点及び前記レガシーデータの前記時点に従って、前記回復サイクルを前記決定することが、
   前記最長キャッシュ時間を有する前記レガシーデータに対応する前記時点から前記現在時点までの時間長を取得することと、
   前記時間長と一致する時間長を有する前記回復サイクルを生成することと、を含む、請求項１に記載の方法。
4. 前記処理ノードによって、前記レガシーデータ、及び前記回復サイクル内に前記分散型メッセージキューに前記新規追加されたデータを前記処理することが、
   前記回復サイクルの単位時間長に従って、複数の処理時間ピリオドを逐次的に設定すること、ならびに前記レガシーデータ及び前記新規追加されたデータに基づいて、前記処理時間ピリオドのそれぞれに処理対象データを割り当てることと、
   それぞれの前記処理時間ピリオド内に、対応する処理対象データを処理すること、及び前記回復サイクル終了後に、計算タスクを通常の処理ロジックに回復させることと、を含む、請求項１に記載の方法。
5. 前記処理時間ピリオドが、データ処理時間及びデータ同期時間で順番に構成され、それぞれの前記処理時間ピリオド内に、前記対応する処理対象データを前記処理することが、
   前記データ処理時間内に前記処理対象データを処理すること、及び前記データ処理時間終了後に、処理された前記処理対象データを記憶することと、
   前記データ処理時間終了後、処理されなかった前記処理対象データが存在する場合に、処理されなかった前記処理対象データを、前記データ同期時間内に破棄することと、を含む、請求項４に記載の方法。
6. 分散型メッセージキュー及び処理ノードを含むデータ処理システムに、前記処理ノードとして適用されるデータ処理デバイスであって、
   再起動が完了した後で、前記分散型メッセージキュー内の最長キャッシュ時間を有する現在のレガシーデータの時点を取得するように構成される取得モジュールと、
   現在時点及び前記レガシーデータの前記時点に従って、回復サイクルを決定するように構成される決定モジュールと、
   前記レガシーデータ、及び前記回復サイクル内に前記分散型メッセージキューに新規追加されたデータを処理するように構成される処理モジュールと、を備える、データ処理デバイス。
7. 前記データ処理システムが、記憶ノードをさらに備え、前記データ処理デバイスが、
   計算タスクを終了する命令を受信し、前記分散型メッセージキューからデータを受信すること、及び前記データの処理完了時に、前記データ処理デバイス内に現在キャッシュされているデータを前記記憶ノードに書き込むことを中断するように構成される、終了モジュールをさらに備える、請求項６に記載のデータ処理デバイス。
8. 前記決定モジュールが、
   前記最長キャッシュ時間を有する前記レガシーデータに対応する前記時点から前記現在時点までの時間長を取得するように構成される取得サブモジュールと、
   前記時間長と一致する時間長を有する前記回復サイクルを生成するように構成される生成サブモジュールと、をさらに含む、請求項６に記載のデータ処理デバイス。
9. 前記処理モジュールが、
   前記回復サイクルの単位時間長に従って、複数の処理時間ピリオドを逐次的に設定し、前記レガシーデータ及び前記新規追加されたデータに基づいて、前記処理時間ピリオドのそれぞれに処理対象データを割り当てるように構成される、設定サブモジュールと、
   それぞれの前記処理時間ピリオド内に、対応する処理対象データを処理するように構成される処理サブモジュールと、
   前記回復サイクル終了後に、計算タスクを通常の処理ロジックに回復させるように構成される、回復サブモジュールと、をさらに含む、請求項６に記載のデータ処理デバイス。
10. 前記処理時間ピリオドが、データ処理時間及びデータ同期時間で順番に構成され、前記処理サブモジュールが、
    前記データ処理時間内に前記処理対象データを処理し、前記データ処理時間終了後に、処理された前記処理対象データを記憶し、
    前記データ処理時間終了後、処理されなかった前記処理対象データが存在する場合に、処理されなかった前記処理対象データを、前記データ同期時間内に破棄するように構成される、請求項９に記載のデータ処理デバイス。

Images