JP6703147B2 - データ処理方法及びデバイス - Google Patents

Description

本願は、２０１６年６月２８日に中国特許庁に出願され「データ処理方法及びデバイス」と題された中国特許出願第２０１６１０４９０８０８．１号の優先権を主張し、上記中国特許出願は参照によってその全体が本明細書に組み込まれる。

本願は、コンピュータ技術の分野に関し、特に、データ処理方法及びデバイスに関する。

近年、ライブストリーミング及びテレビ生放送等のシナリオにおいて、データライブブロードキャストが広く適用されている（データライブブロードキャストとはデータのリアルタイム表示である）。ユーザは、データライブブロードキャストによって、対応する情報を適時に得ることができる。

例えば、春節の交通ピーク時の旅客流動量をテレビの生放送中に表示できるため、テレビの生放送を見ているユーザは、春節における交通ピーク時の旅客流動量を知ることができる。別の例として、ショッピングウェブサイトのアクセス量、販売量等をウェブサイトに表示できるので、ショッピングウェブサイトにアクセスするユーザは、該当ページのアクセス量及び販売量を知ることができる。

データのライブ表示は、通常、サーバ（又はサーバクラスタ）上のライブデータサービス（ライブデータサービスは対応するサーバ上で作動する）によって実施される。ライブデータサービスは、データソースからデータをリアルタイムに取得し、対応する統計処理を実行してライブデータを取得し、取得されたライブデータを表示用端末デバイスへ送信する。注記すると、実際のデータライブ表示工程は、基本的には、ディレイ（遅延）ライブブロードキャストである。具体的には、端末デバイスにより表示されるデータと、サーバにより生成されるデータとの間には、時間差がある。言い換えると、端末デバイスにより表示されるライブデータは、通常、ｎ秒前にサーバによって生成されたデータである。

ただし、実際のアプリケーションシナリオでは、ライブデータサービスの実行時に例外（例えば、カウントエラーや遅延）が発生することがあり、対応するサービススタッフがトラブルシューティングや修復をする必要がある。

従来技術では、ライブデータサービスで例外が発生すると、サーバが、バックアップライブデータサービスへ切り替えることにより、異常なライブデータサービスを置き換える。

しかし、バックアップサービスへの切り替え方法では、以下の理由で、リアルタイムデータの「ジャンプ」即ちロールバックを発生することがある。その理由とは、サーバ上で作動しているライブデータサービスは、データソースから取得したリアルタイムデータをバッファリングして、対応する統計処理を実行する。ライブデータサービスにおいて例外が発生し、ライブデータサービスがバックアップライブデータサービスに切り替えられると、ライブデータサービスのバッファに記憶されているリアルタイムデータは消去され、バックアップライブデータサービスは実際のデータを再びバッファリングし、バックアップライブデータサービスの作動後、統計処理を実行する。この場合、データ統計処理が繰り返されるため、データライブブロードキャストでロールバックが発生する。

一例としてアクセストラフィックデータを用いると、オリジナルのライブデータサービスはデータソースから取得したリアルタイムデータａ９００〜ａ９６０をバッファリングし、６０個のデータに対して統計処理を実行してアクセストラフィックデータ９００〜９６０を生成する。ライブデータサーバは、リアルタイムデータａ９３０〜ａ９５０に基づいてアクセストラフィックデータ９３０〜９５０を生成し、アクセストラフィックデータを、表示のために端末デバイスへ送信する。図１ａに示すように、サーバからのアクセストラフィックデータに基づいて端末デバイスによって現在表示されているアクセストラフィックは９３５である。

ライブデータサービスがアクセストラフィックデータ９５５を生成するときに例外が発生した場合、サーバは、異常なライブデータサービスを停止し、バックアップライブデータサービスが異常なライブデータサービスにとって代わることができるようにする。バックアップライブデータサービスの実行後、元のライブデータサービスによってバッファリングされていたデータは消去され、バックアップライブデータサービスはリアルタイムデータａ９００〜ａ９６０を再びバッファリングして統計処理を行い、アクセストラフィックデータ９００〜９２０を生成してから、アクセストラフィックデータを、表示のために端末デバイスへ送信する。この場合、端末デバイスは、（図１ｂに示すように）先に受信したアクセストラフィックデータに基づいてアクセストラフィック９５０を表示した後、最新のアクセストラフィックデータ９００〜９２０に基づいてアクセストラフィックを９００へロールバックする。図１ｃに示すように、端末デバイスは９００から始まる表示を行う。これがデータのロールバックである。

明らかに、このような方法は、端末デバイスによって表示されるライブデータに影響を及ぼす。

本願の実施は、従来技術においてライブデータの例外（エクセプション）によって引き起こされるジャンプ、ロールバック等を低減するため、データを処理する方法を提供する。

本願の実施は、従来技術においてライブデータの例外によって引き起こされるジャンプ、ロールバック等を低減するため、データを処理するデバイスを提供する。

以下の技術的解決策が本願の実施で用いられる。

本願の実施は、データを処理するための方法を提供し、前記方法は：ライブデータサービスの作動状態を、サーバによりモニタするステップと；前記作動状態において例外が発生したことを検出すると、予測修復時間（予測されるリカバリ時間）を特定するステップと；前記予測修復時間に基づいて第１のレートを計算するステップと；前記端末デバイスが前記第１のレートに基づいてライブデータを表示するように、前記計算された第１のレートを端末デバイスへ送信するステップと；を含む。

本願の実施は、データを処理するための方法を更に提供し、前記方法は：サーバによって送信される第１のレートを、端末デバイスによって受信するステップであって、前記第１のレートは、作動状態において例外が発生したことを前記サーバが検出すると、前記サーバによって特定された予測修復時間に基づいて前記サーバによって計算される、前記受信するステップと；前記第１のレートに基づいてライブデータを表示するステップと；を含む。

本願の実施は、データを処理するためのデバイスを提供し、前記デバイスは：ライブデータサービスの作動状態をモニタするよう構成されたモニタモジュールと；前記作動状態において例外が発生したことを検出すると、予測修復時間を特定するよう構成された予測モジュールと；前記予測修復時間に基づいて第１のレートを計算するよう構成された計算モジュールと；前記端末デバイスが前記第１のレートに基づいてライブデータを表示するように、前記計算された第１のレートを端末デバイスへ送信するよう構成された送信モジュールと；を含む。

本願の実施は、データを処理するためのデバイスを更に提供し、前記デバイスは：サーバによって送信される第１のレートを受信するよう構成された受信モジュールであって、前記第１のレートは、作動状態において例外が発生したことを前記サーバが検出すると、前記サーバによって特定される予測修復時間に基づいて前記サーバによって計算される、前記受信モジュールと；前記第１のレートに基づいてライブデータを表示するよう構成された表示モジュールと；を含む。

本願の実施において用いられる少なくとも１つの技術的解決策は、以下の有益な効果を奏することができる。

ライブデータサービスで例外が発生したことを検出すると、サーバは予測修復時間を特定し、予測修復時間に基づいて第１のレートを計算し、第１のレートを端末デバイスへ送信する。第１のレートは、端末デバイスによってライブデータを表示する際の表示レートを制御するために用いることができる。言い換えると、端末デバイスによってライブデータを表示する際の表示レートを第１のレートを用いて下げることができ、端末デバイスは、第１のレートに基づいてライブデータの表示レートを下げる。したがって、端末デバイスが表示対象のローカルに記憶されたライブデータを表示するには、より多くの時間がかかることになる。そのようにして、サーバ側では、サービススタッフはサーバ上で作動しているライブデータサービスのトラブルシューティングや修復を実行するのに十分な時間を持つことができる。

従来技術におけるバックアップライブデータサービスへの切り替え方法と比較して、本願の方法では元のライブデータサービスを保有しておくことができる（サービスの切り替えは行わない）。ライブデータサービスが正常に戻った後、ライブデータサービスは更に、ライブデータサービスによってバッファされているリアルタイムデータに基づいて統計処理を実行する。言い換えると、ライブデータサービスの切り替えが実行されない場合、ライブデータサービスによってバッファされているリアルタイムデータは消去されない。そのため、ライブデータのロールバックやライブデータのジャンプなどの例外は発生しない。

更に、エンドユーザは、ライブデータのジャンプ、ロールバック、又は停滞等の変化を特に意識することはない。

添付図面は、本願の更なる理解を提供するために使用され、本願の一部を構成する。本願の例示的な実施及び実施の説明は、本願を説明するために使用されており、本願に対する不適切な制限を構成するものではない。

図１ａは、既存技術におけるデータライブブロードキャストを示す概略図である。 図１ｂは、既存技術におけるデータライブブロードキャストを示す概略図である。 図１ｃは、既存技術におけるデータライブブロードキャストを示す概略図である。

図２ａは、本願の実施による、データ処理工程を示す概略図である。

図２ｂは、本願の実施による、サーバにより端末デバイスの表示レートを調整する工程を示す概略図である。 図２ｃは、本願の実施による、サーバにより端末デバイスの表示レートを調整する工程を示す概略図である。 図２ｄは、本願の実施による、サーバにより端末デバイスの表示レートを調整する工程を示す概略図である。

図３は、本願の実施による、サーバ側のデータ処理デバイスを示す概略構造図である。

図４は、本願の実施による、端末デバイス側のデータ処理デバイスを示す概略構造図である。

本願の目的、技術的解決策、及び利点をより明確にするために、以下は、本願の特定の実施及び対応する添付図面を参照して本願の技術的解決策を明確かつ包括的に説明する。明らかに、記載された実施は、本願の実施のすべてではなく、一部である。創造的な努力なしに本願の実施に基づいて当業者によって得られる他のすべての実施は、本願の保護範囲内に入るものである。

上で説明したように、データライブブロードキャストのシナリオでは、サーバによって生成されたライブデータが常に端末デバイスへ送信されるので、端末デバイスはライブデータに基づいてデータのライブ表示を実行できる。ただし、サーバ側のライブデータサービスにおいて例外が発生すると、サーバはバックアップサービスへ切り替わる。これにより、データライブブロードキャスト工程でデータロールバックやデータジャンプなどの変化が発生する。それによってデータライブブロードキャストの正常な作動に影響を与える。

この点を考慮すると、データライブブロードキャスト工程におけるデータロールバック又はデータジャンプを低減するための方法が必要となる。したがって、本願の実施はデータ処理のための方法を提供し、それにより、サーバ上のライブデータサービスにおいて例外が発生した場合でもデータロールバック又はデータジャンプは発生せず、データライブブロードキャストの正常な作動が保証される。

本願の実施では、サーバは、ライブデータサービスを提供可能であればよく、ウェブサイトサーバ、データセンタサーバ等であり、限定されない。サーバは独立して稼働できても（ライブデータサービスを提供するサーバは１つのみ）、クラスタ内で稼働できてもよい。端末デバイスは、データ表示機能を有するユーザ端末デバイス、例えば携帯電話、タブレット型コンピュータ、スマートＴＶ、又はコンピュータでもよい。実際のアプリケーションシナリオによっては、端末デバイスは大型表示デバイス（例えば、ライブホールの大型スクリーンを備えたデバイス）でもよい。本願では端末デバイスは限定されない。

注記すると、サーバ上のライブデータサービスは、通常、ライブデータを生成するための統計処理を実行する工程で、ライブデータをバッチで生成する。言い換えると、ライブデータサービスは非常に短い時間間隔で一定量のライブデータを生成する。例えば、ライブデータサービスは、最後のライブデータ生成から１５ミリ秒後の時点で２０００個のライブデータを生成する。もちろん、実際には、毎回ライブデータサービスによってライブデータを生成する時間間隔及び毎回生成されるライブデータの量は、データソースのリアルタイムデータ及びサーバの運用負荷に関係する。この実施は本願において限定されない。

サーバ上のライブデータサービスが正常に作動する場合、端末デバイスによるライブデータの表示工程は以下の通りである。

最初に、端末デバイスはサーバと対話（相互作用）してライブデータを取得する。

本願の実施の方法では、端末デバイスは、非常に短い時間間隔でサーバからライブデータを定期的に取得する。例えば、端末デバイスは０．５秒毎にサーバからライブデータを取得する。この方法では、端末デバイスは積極的にサーバからデータを取得する。実際には、この方法は、サーバが多数（複数）の端末デバイスに対してデータライブサービスを提供するシナリオに適用可能である。

別の方法では、端末デバイスはサーバとの持続的接続を維持する。サーバは、サーバ上のライブデータサービスがライブデータを生成するたびに、新たに生成されたライブデータを、サーバと端末デバイスとの間の持続的接続を介して端末デバイスへ送信する。もちろん、実際には、端末デバイスとサーバとの間に持続的接続を確立する方法は、データライブホール（ｄａｔａ ｌｉｖｅ ｈａｌｌ）及び集中データライブブロードキャスト等のシナリオに、より適合する。端末デバイスが複数存在し且つサーバが各端末デバイスと持続的接続を維持すると、サーバの作業負荷が大幅に増加する可能性がある。もちろん、実際には、サーバが作業負荷に十分耐えることができれば、持続的接続を確立する方法は、端末デバイスが複数存在する場合にも用いることができる。実施は本願において限定されない。

ライブデータを取得した後、端末デバイスはライブデータを表示する。

端末デバイスによって取得されたライブデータは、先に説明した内容に基づいてデータライブサービスによって生成されたライブデータのバッチ（ライブデータのバッチは複数のデータを含む）である。ライブデータを取得した後、端末デバイスは、ライブデータをローカルにバッファし、サーバによって指定されたレートに基づいてライブデータを表示する。例えば、ウェブサイトアクセストラフィックのデータライブブロードキャスト工程では、端末デバイスによってサーバから取得されたアクセストラフィックデータのバッチは、アクセストラフィックデータ３００〜３５０を含み、サーバは、アクセストラフィックデータの表示レートが１秒ごとに変化する（データを毎回５個増やす）ことを指定する。この場合、端末デバイスが０８：０１：１０にアクセストラフィック３００を表示すると、端末デバイスが０８：０１：１１に表示したアクセストラフィックは３０５となる。

本願の実施において提供される技術的解決策は、先に説明した内容を参照して以下詳細に説明する。

図２ａは、本願の実施におけるデータ処理工程を示す。この工程は具体的には以下のステップを含む。

Ｓ２０１：サーバが、ライブデータサービスの作動状態をモニタする。

ライブデータサービスはサーバ上で作動する。ライブデータサービスは、データソースからリアルタイムデータを取得し、対応する統計処理を実行して表示用ライブデータを生成する。実際には、ライブデータサービスは大量のデータを処理する。したがって、実行中の工程で、バックエンド呼び出しの競合が発生したり、多数の操作が原因で操作が不安定になったりして、ライブデータサービスが異常に作動する可能性がある。ライブデータサービスにおいて例外が発生した後、ライブデータサービスによって生成されたライブデータは異常であることが分かる。

したがって、サーバは、ライブデータサービスの作動状態をモニタして、ライブデータサービスにおいて例外が発生すると対応措置を講じ、それにより端末デバイスが表示するライブデータの明らかなジャンプ又はロールバック等の例外を減らす。

Ｓ２０２：作動状態における例外の発生を検出した場合、予測修復時間を特定する。

実際には、ライブデータサービスにおいて例外が発生した場合には、対応するサービススタッフがトラブルシューティングや修復等の操作を実行できる。トラブルシューティングや修復操作の実行にはしばらく時間がかかる。したがって、サーバは、ライブデータサービスにおける例外の発生から、予測される修復時刻までの期間（予測修復時間）を特定する。

Ｓ２０３：予測修復時間に基づいて第１のレートを計算する。

注記すると、本願のこの実施における第１のレートは、ライブデータの変化レートであってもよい。例えば、ライブデータはｎ秒ごとに変わる。

あるいは、第１のレートはライブデータの各変化の大きさとしてもよい。例えば、１回にｎ個のライブデータが増加する、又は１回にｎ個のライブデータが減少するなどである。

あるいは、第１のレートは時間経過レートとすることができる。具体的には、実時間を基準とし、レート係数に単位時間を乗じて第１のレートを特定する。例えば、第１のレートの１秒＝実時間１．５＊１秒と指定できる。言い換えると、端末デバイスにおける１秒は、実時間の１．５秒であり、第１のレートである。もちろん、第１のレートは任意の何れの方法も本願に限定を課すものではない。

先に説明した内容を考慮すると、端末デバイスがライブデータを表示すると、サーバによって表示レートが指定されるので、端末デバイスは、サーバによって指定された表示レートに基づいて端末デバイスによって取得されたライブデータを表示する。サーバ上のライブデータサービスにおいて例外が発生した場合、端末デバイスについてライブデータの表示レートが下がると、サービススタッフは、ライブデータサービスのトラブルシューティングや修復を実行するための時間を増やすことができる。

例えば、通常、端末デバイスは、アクセストラフィックデータ３００〜３５０をローカルに記憶し、１秒毎にライブデータを更新してライブ表示を行う場合（アクセストラフィックデータが１回で５個増加すると仮定する）、端末デバイスがアクセストラフィック３００〜３５０を表示するには、通常、１０秒必要である。サーバ上のライブデータサービスで例外が発生し、サーバが予測修復時間に基づき計算して第１のレートを取得した場合、２秒ごとに変化させると（アクセストラフィックデータを５個増加するため）、端末デバイスが第１のレートに基づいてアクセストラフィック３００〜３５０を表示するには２０秒必要となる。

先の例からわかるように、第１のレートでは、ライブデータを表示する表示時間は正常な状態よりも１０秒長くなっている。この場合、バックエンドサービスのスタッフは、１０秒を使ってライブデータサービスのトラブルシューティングや修復を実行する。もちろん、先の例は単に第１のレートの関数を説明するだけである。実際には、第１のレートは予測修復時間に基づいて予測できる。実施は本願において限定されない。

Ｓ２０４：端末デバイスが第１のレートに基づいてライブデータを表示するように、計算された第１の時間経過レートを端末デバイスへ送信する。

上記に説明したように第１のレートを取得した後、サーバは第１のレートを端末デバイスへ送信し、端末デバイスは、第１のレートに基づいて端末デバイスによって取得されたライブデータを表示する。詳細については、先の例を参照できる。

先の各ステップでは、ライブデータサービスにおいて例外が発生したことを検出すると、サーバは予測修復時間を特定し、予測修復時間に基づいて第１のレートを計算し、第１のレートを端末デバイスへ送信する。第１のレートは、端末デバイスがライブデータを表示する際の表示レートを制御するために用いることができる。言い換えると、端末デバイスはライブデータの表示レートを第１のレートを用いて下げることができる、即ち、端末デバイスは、第１のレートに基づいてライブデータの表示レートを下げる。したがって、端末デバイスがローカルに記憶された表示対象のライブデータを表示するには、更に時間がかかることになる。その結果、サーバ側では、サービススタッフがサーバ上で作動しているライブデータサービスのトラブルシューティングや修復を実行するのに十分な時間を持てる。

従来技術におけるバックアップライブデータサービスへの切り替え方法と比較して、本願の方法では元のライブデータサービスを取っておくことができる（サービスの切り替えは行わない）。ライブデータサービスが正常に戻った後、ライブデータサービスは更に、ライブデータサービスによってバッファされているリアルタイムデータに基づいて統計処理を実行する。言い換えると、ライブデータサービスの切り替えが実行されない場合、ライブデータサービスによってバッファされているリアルタイムデータは消去されない。そのため、ライブデータのロールバックやライブデータのジャンプなどの例外は発生しない。

注記すると、先の実施で提供された方法の各ステップは、１つのデバイス、具体的にはサーバで実行できる。

ライブデータサービスにおいて例外が発生した場合の詳細について以下説明する。

注記すると、実際には、ライブデータサービスにおいて例外が発生した場合、通常、異常なライブデータサービスに対して手動でトラブルシューティング又は修復が実行される。この工程では、対応するサービススタッフが予測修復時間を特定する。もちろん、サーバは、任意の方法で対応する診断インタフェースを提供し、インタフェースは予測修復時間の選択肢を提供する。トラブルシューティング又は修復の実行時、サービススタッフは対応する予想修復時間をオプションで入力できる。

本願のこの実施において、予測修復時間を特定するステップは具体的に：予測された修復時刻を特定するステップと；例外がライブデータサービスの作動状態において発生した時刻を特定するステップと；特定された予測された修復時刻と、特定された時刻とに基づいて予測修復時間を特定するステップと；を含む。

例えば、ライブデータサービスにおいて例外が発生した時刻が１２：０８：０２で、サービススタッフが予測した修復時刻が１２：０８：４０の場合、予測修復時間は３８秒である。

予測修復時間の特定後、第１の時間経過レートを更に計算することができる。具体的には、ライブデータサービスの作動状態において例外が発生すると、端末デバイスがライブデータの表示を停止した時刻が特定され、前記特定された時刻、即ち端末デバイスがライブデータの表示を停止した時刻と予測修復時刻とに基づいて第１のレートが特定される。

予測修復時間が長いほど、第１のレートが低いことが示される。説明を容易にするために、予測修復時間を、以下ではＴ_ｙｕとする。

注記すると、ライブデータサービスにおいて例外が発生すると、サーバは端末デバイスへのライブデータの送信を停止し、端末デバイスはローカルのライブデータを元の表示レートで表示する。しばらくすると、端末デバイスは表示されていないローカルライブデータの表示を完了してしまうということが分かる。したがって、最後のライブデータを表示した後、端末デバイスはライブデータの更新を停止する（というのは、この場合、端末デバイスはローカルにバッファされたすべてのライブデータを表示し、サーバによって提供された新しいライブデータを取得していないためである）。そのことは以下のように表される。即ち、端末デバイスによって表示されるライブデータはある値で停止する。例えば、端末デバイスによって表示されるアクセストラフィックは５００で停止する。

したがって、本願のこの実施では、ライブデータサービスの作動状態において例外が発生すると、サーバは、現在時刻と端末デバイスによるライブデータの更新停止時刻との間の期間を特定する（説明を簡単にするために、ライブデータサービスにおける例外の発生と端末デバイスによるライブデータの更新停止との間の期間を、以下、Ｔ_ｃ１とする）。もちろん、本願の任意選択の方法では、端末デバイスによるライブデータを表示する際の表示レートがサーバによって指定されるので、サーバは端末デバイスの表示レートを知ることができる。更に、サーバ上のライブデータサービスが毎回ライブデータを生成するための統計処理を実行する時間が（例えば、対応するデータログに）記録されるので、その時間に対応するライブデータの量も記録される。サーバは、端末デバイスへ最後に送信されたライブデータを生成する時間を特定できるので、サーバは、端末デバイスに記憶されたライブデータの量を特定できる。端末デバイスに記憶されているライブデータの量と表示レートとは既知であるので、サーバはＴ_ｃ１を特定できる。

Ｔ_ｃ１は、表示レートに変化がなければ、端末デバイスがライブデータを表示する期間と見なすことができるが、Ｔ_ｃ１後、端末デバイスはライブデータの更新を停止し、それによって、データライブブロードキャストに表示の例外が引き起こされる。Ｔ_ｙｕはバックエンドサービススタッフが修復を実行するために必要とする時間期間なので、本願のこの実施では、第１のレートはＴ_ｃ１とＴ_ｙｕとに基づいて特定され、それにより第１のレートでＴ_ｃ１が延長される。

端末デバイスがウェブサイトのアクセストラフィックデータを表示する際の表示レートは、毎秒１０個のデータを増やすことであり、端末デバイスがサーバから取得したアクセストラフィックデータは、現在１０００〜１２００を含むと仮定する。ディスプレイにアクセストラフィック１０００が表示されているときにサーバ上で作動しているライブデータサービスにおいて例外が発生した場合、端末デバイスはサーバからアクセストラフィックデータを取得し続けることができない。２０秒の時間Ｔ_ｃ１が、表示レートで、端末デバイスによってアクセストラフィック１０００からアクセストラフィック１２００を表示するために必要とされることが分かる。しかしながら、予測修復時間Ｔ_ｙｕは４０秒であるので、端末デバイスの現在の表示レートは、２０秒後のデータの停滞を減らすために調整される必要がある。

この例では、第１のレート＝Ｔ_ｃ１／Ｔ_ｙｕ＊現在の表示レート＝０．５＊１０＝５である。

言い換えると、第１のレートは、毎秒５個のデータを増やすことである。明らかに、第１のレートに基づいて端末デバイスがアクセストラフィック１０００からアクセストラフィック１２００を表示するのに必要な期間は４０秒であり、元の表示期間は延長される。

もちろん、先の方法は、第１のレートがライブデータ量の変化を示す場合の説明である。第１のレートが時間経過レートである場合、第１のレートは次のように計算できる。

第１のレート（クライアントの時間経過レート）＝［（サーバとクライアントの時間差＊クライアントの時間）／Ｔ_ｙｕ］＋クライアントの元の時間経過レート

先に説明した内容は、ライブデータサービスにおいて例外が発生したときの端末デバイスの表示レートを調整する工程である。具体的には、図２ｂに示すように、先の工程では、端末デバイスの表示レートは、計算された第１のレートに基づいて本質的に減少する。実際のアプリケーションシナリオでは、バックエンドサービススタッフがライブデータサービスを修復した後、ライブデータサービスは、通常、リアルタイムデータに対して統計処理を実行して対応するライブデータを生成し、そのライブデータを端末デバイスへ送信する。端末デバイスは、第１のレートに基づいて比較的低い表示レートでライブデータを表示する。端末デバイスがサーバによって送信されたライブデータを通常受信できるようになった後、端末デバイスは新しいライブデータに適応するために表示レートを上げることができる。

ライブデータサービスの修復後の工程を詳しく説明する。

先の修復工程では、サービススタッフは、ライブデータサービスを修復できる時間（予測修復時間）を予測していた。実際のアプリケーションシナリオでは、ライブデータサービスの実際の修復時刻と、サービススタッフによって予測された修復時刻との間に時間差が存在する可能性がある。例えば、サービススタッフが予測した修復時刻が１２：０８：４０で、実際のデータサービスが１２：０７：５０に修復した場合、２つの時刻には５０秒の時間差がある。

実際には、第１のレートは予測修復時間に基づいて特定されるため、ライブデータサービスの実際の修復時刻と予測された修復時刻の間に時間差がある場合は、端末デバイスの表示レートの増分は時間差に基づいて特定される必要がある、すなわち第２のレートが特定される。

したがって、ライブデータサービスが修復した後、本方法は：ライブデータサービスの作動状態が正常に戻ったことが検出されたときの修復時間差を特定するステップと；修復時間差に基づいて第２のレートを計算するステップと；端末デバイスは第２のレートに基づいてライブデータを表示するように、計算された第２の時間経過レートを端末デバイスへ送信するステップと；を含む。

もちろん、先に説明した内容から分かるように、修復時間差を特定するステップは、具体的には：ライブデータサービスの作動状態が正常に戻る時刻を特定するステップと；ライブデータサービスの作動状態が正常に戻る時刻と予測された修復時刻とに基づいて修復時間差を特定するステップと；を含む。

先の例では、ライブデータサービスで１２：０１：００に例外が発生した場合、予測修復時間は４０秒であるので、予測された修復時刻は１２：０１：４０であるが、ライブデータサービスの実際の修復時刻は１２：０１：２０である（この時点で新しいアクセストラフィックデータが生成される）。言い換えると、ライブデータサービスは予測された修復時刻よりも２０秒早く修復する。この場合、端末デバイスには表示されていないアクセストラフィックデータが１００個存在する。ライブデータサービスが正常に作動した後、サーバは作動端末デバイスの現在の表示レート（第１のレート）を調整する必要があり、それによりライブデータサービスが正常に作動した後に、端末デバイスがライブデータサービスによって生成された新しいアクセストラフィックデータに適応できる。この場合、端末デバイスは、残りのアクセストラフィックデータの表示を加速する（つまり、第２のレートが生成される）。

もちろん、修復時間の差が小さいほど、第２のレートは高いことを示していることがわかる。

同様に、先の方法は、第２のレートがライブデータ量の変化を示す場合の説明である。第２のレートが時間経過レートである場合、第２のレートは次のように計算できる。

第２のレート（クライアントの時間経過レート）＝［（実際の修復時間−クライアント時間）＊Ｔ_ｙｕ／実際の修復時間差］＋第１のレート

ライブデータサービスが正常に戻ったときに端末デバイスの表示レートを調整する工程は、上記で説明される。詳細な工程を図２ｃに示す。

もちろん、端末デバイスが残りのライブデータの表示を加速した（及び新しいライブデータを受信した）後、それによりサーバは、端末デバイスが再び正常なレートに基づいてライブデータを表示するように、端末デバイスへ正常なレートを送信する。この工程は図２ｄに示される。

更に注記すると、実際のアプリケーションシナリオでは、ライブデータサービスの実際の修復時刻は、予測された修復時刻より遅くなる可能性がある。例えば、１２：０１：００にライブデータサービスで例外が発生し、予測された修復時刻が１２：０１：４０になっているが、実際には１２：０２：２０にライブデータサービスが正常に戻るとする。明らかに、この場合、端末デバイスが先の方法で計算された第１のレートのみに基づいてライブデータを表示する場合、ライブデータ表示は依然として停止される可能性がある。したがって、本願のこの実施では、そのような場合を減らすために第１のレートを動的に調整できる。言い換えると、複数の第１のレートを計算して端末デバイスへ送信できる。

例えば、第１のレートについて先の例を続けると、最初に生成される第１のレートは１秒ごとに５個のアクセストラフィックデータを増やすことがわかる。データサービスは、１０秒後にまだ修復されていない（この場合、端末デバイスによって表示されるアクセストラフィックは１１５０であり、１５０個のアクセストラフィックデータが残っており、３０秒ですべて表示できる）。したがって、サーバは、（端末デバイスの表示期間を延長するために用いられる）新しい第１のレートを計算できる。新しい第１のレートが毎秒２個のアクセストラフィックデータを増やす場合、端末デバイスの表示期間は７５秒まで延長できる。

もちろん、先の例は、本願のこの実施における実際のアプリケーションシナリオのための可能な方法に過ぎず、本願に対する制限を構成するものではない。

先に説明した内容では、サーバ上のライブデータサービスにおいて例外が発生した場合、サーバは端末デバイスの現在の表示レートを下げ、エンドユーザに、ジャンプ、ロールバック、ライブデータの停滞などの変化を十分に意識させることなく、バックエンドスタッフのトラブルシューティングや修復の時間を延長できる。それに対応して、ライブデータサービスが修復した後、端末デバイスの表示レートを増加させることができ、それによって端末デバイスはサーバによって送信される新しいライブデータに適応できる。

もちろん、端末デバイス側では、本願はデータを処理するための方法を提供する。具体的には、サーバ上のライブデータサービスで例外が発生した場合、この方法は以下のステップを含む。

ステップ１：端末デバイスが、サーバによって送信された第１のレートを受信する。ここで、第１のレートは、サーバが作動状態において例外が発生したことを検出すると、サーバによって特定される予測修復時間に基づいてサーバによって計算される。

ステップ２：第１のレートに基づいてライブデータを表示する。

サーバ上のライブデータサービスが正常に戻ると、この方法は：サーバによって送信された第２のレートを端末デバイスによって受信するステップであって、第２のレートは、サーバがライブデータサービスの作動状態が正常に戻ったことを検出するとサーバによって特定される修復時間差に基づいてサーバによって計算される、前記受信するステップと；第２のレートに基づいてライブデータを表示するステップと；を更に含む。

端末デバイス側が異なるレートに基づいてライブデータを取得してライブデータを表示する実施工程については、先に説明した内容を参照することができる。詳細はここでは省略する。

本願の実施において提供されるデータを処理するための方法を上記で説明した。同じ考えに基づいて、本願の実施はデータを処理するためのデバイスを更に提供する。

図３に示すように、データを処理するためのこのデバイスは、サーバ側に配置され：ライブデータサービスの作動状態をモニタするよう構成されたモニタモジュール３０１と；作動状態において例外が発生したことが検出されると予測修復時間を特定するよう構成された予測モジュール３０２と；予測修復時間に基づいて第１のレートを計算するよう構成された計算モジュール３０３と；端末デバイスが第１のレートに基づいてライブデータを表示するように、計算された第１のレートを端末デバイスへ送信するように構成された送信モジュール３０４と；を含む。

具体的には、予測モジュール３０２は、予測された修復時刻を特定し、ライブデータサービスの作動状態に例外が発生した時刻を特定し、特定された予測された修復時刻と特定された発生時刻とに基づいて予測修復時間を特定する。

更に、予測モジュール３０２は、ライブデータサービスの作動状態において例外が発生すると、端末デバイスによるライブデータの更新を停止する時刻を特定し、端末デバイスによるライブデータの表示を停止する時刻と予測された修復時刻とに基づいて第１のレートを特定する。

予測修復時間が長いほど、第１のレートは低いことを示す。

このデバイスは、更に：ライブデータサービスの作動状態が正常に戻ったことが検出されると修復時間差を特定し；修復時間差に基づいて第２のレートを計算し；端末デバイスが第２のレートに基づいてライブデータを表示するように、計算された第２の時間経過レートを端末デバイスへ送信するよう構成された修復モジュール３０５を含む。

更に、修復モジュール３０５は、ライブデータサービスの作動状態が正常に戻る時刻を特定し；ライブデータサービスの作動状態が正常に戻る時刻と、予測された修復時刻とに基づいて修復時間差を特定する。

これに基づいて、計算モジュール３０３は、修復時間差と第１のレートとに基づいて第２のレートを特定する。

修復時間差が小さいほど、第２のレートは高いことを示す。

図４に示すように、本願の実施は、更に、端末デバイス側に配置されたデータを処理するためのデバイスを提供し、デバイスは：サーバによって送信される第１のレートを受信するよう構成された受信モジュール４０１であって、第１のレートはサーバが作動状態において例外が発生したことを検出するとサーバによって特定される予測修復時間に基づいてサーバによって計算される、前記受信モジュール４０１と；第１のレートに基づいてライブデータを表示するよう構成された表示モジュール４０２と；を含む。

もちろん、ライブデータサービスが修復した後、サーバは更に端末デバイスへ第２のレートを送信し、受信モジュール４０１はサーバによって送信された第２のレートを受信する。第２のレートは、ライブデータサービスの作動状態が正常に戻ったことをサーバが検出すると、サーバによって特定される修復時間差に基づいてサーバによって計算される。

表示モジュール４０２は、第２のレートに基づいてライブデータを表示する。

当業者は、本開示の実施が方法、システム、又はコンピュータプログラム製品として提供され得ることを理解するはずである。したがって、本開示は、ハードウェアのみの実施、ソフトウェアのみの実施、又はソフトウェアとハードウェアの組み合わせを用いた実施の形態をとることができる。更に、本開示は、コンピュータで使用可能なプログラムコードを含む１つ又は複数のコンピュータ使用可能記憶媒体（磁気ディスク記憶装置、ＣＤ−ＲＯＭ、光メモリなどを含むがこれらに限定されない）上で実施されるコンピュータプログラム製品の形態をとることができる。

本開示は、本開示の実施による方法、デバイス（システム）、及びコンピュータプログラム製品のフローチャート及び／又はブロック図を参照して説明される。フローチャート及び／又はブロック図中の各プロセス及び／又は各ブロック、並びにフローチャート及び／又はブロック図中のプロセス及び／又はブロックの組み合わせを実施するためにコンピュータプログラム命令を使用できることを理解されたい。これらのコンピュータプログラム命令は、汎用コンピュータ、専用コンピュータ、組み込みプロセッサ、又は他のプログラム可能データ処理デバイスのプロセッサに提供されてマシンを生成することができ、その結果、コンピュータ又は他のプログラム可能データ処理デバイスのプロセッサによって実行される命令は、フローチャート中の１つ以上のプロセス及び／又はブロック図中の１つ以上のブロックにおける特定の機能を実施するための装置を生成する。

これらのコンピュータプログラム命令は、特定の方法で動作するように、コンピュータ又は別のプログラム可能データ処理デバイスに命令することができるコンピュータ可読メモリに格納することができ、その結果、コンピュータ可読メモリに格納された命令は命令装置を含むアーチファクトを生成する。命令装置は、フローチャート内の１つ又は複数のプロセス及び／又はブロック図内の１つ又は複数のブロックにおける特定の機能を実施する。

これらのコンピュータプログラム命令は、コンピュータ又は他のプログラム可能データ処理デバイスにロードすることができ、その結果、コンピュータ又は他のプログラム可能デバイス上で一連の動作及びステップが実行され、それによってコンピュータ実装処理が生成される。したがって、コンピュータ又は他のプログラム可能デバイス上で実行される命令は、フローチャート中の１つ以上のプロセス及び／又はブロック図中の１つ以上のブロックにおける特定の機能を実施するためのステップを提供する。

典型的な構成では、コンピューティングデバイスは、１つ又は複数のプロセッサ（ＣＰＵ）、入力／出力インタフェース、ネットワークインタフェース、及びメモリを含む。

メモリは、非永続的メモリ、ランダムアクセスメモリ（ＲＡＭ）、不揮発性メモリ、及び／又はコンピュータ可読媒体内の他の形態、例えば読み取り専用メモリ（ＲＯＭ）又はフラッシュメモリを含むことができる。メモリは、コンピュータ可読媒体の一例である。

コンピュータ可読媒体は、任意の方法又は技術を使用することによって情報記憶を実施することができる持続的、非持続的、移動可能、及び移動不能の媒体を含む。情報は、コンピュータ可読命令、データ構造、プログラムモジュール、又は他のデータとすることができる。コンピュータ記憶媒体は、相変化ランダムアクセスメモリ（ＰＲＡＭ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、他のタイプのランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ、電気的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリ、又は他のメモリ技術、コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、又は他の光学記憶装置、カセット、カセット磁気ディスク記憶装置、又は他の磁気記憶装置、又は任意の他の非伝送媒体を含むが、これらに限定されない。コンピュータ記憶媒体は、コンピューティングデバイスによってアクセスすることができる情報を記憶するように構成することができる。本明細書の定義に基づいて、コンピュータ可読媒体は、一時的なコンピュータ可読媒体、例えば変調データ信号及び搬送波を含まない。

更に、用語「含む」「包含する」又はそれらの任意の他の変形は、非排他的な包含を網羅することを意図しており、その結果、要素の列挙を含むプロセス、方法、物品、又はデバイスは、これらの要素を含むだけでなく、明示的に列挙されていない他の要素をも含む、又はそのようなプロセス、方法、物品、又はデバイスに固有の要素を更に含む、ことに留意することは価値がある。「〜を含む」が付いた要素は、それ以上の制約がない限り、その要素を含むプロセス、方法、物品、又はデバイスにおける追加の同一の要素の存在を排除するものではない。

当業者は、本願の実施が方法、システム、又はコンピュータプログラム製品として提供され得ることを理解されたい。したがって、本願は、ハードウェアのみの実施、ソフトウェアのみの実施、又はソフトウェアとハードウェアとの組み合わせを用いた実施の形態をとることができる。更に、本願は、コンピュータで使用可能なプログラムコードを含む１つ又は複数のコンピュータ使用可能記憶媒体（磁気ディスク記憶装置、ＣＤ−ＲＯＭ、光メモリなどを含むがこれらに限定されない）上で実施されるコンピュータプログラム製品の形態をとることができる。

前述の説明は、本願の単なる実施であり、本願を限定することを意図するものではない。当業者にとって、本願は様々な修正及び変更を加えることができる。本願の精神及び原理においてなされるいかなる修正、均等物の置換、改良なども本願の特許請求の範囲の範囲内に含まれるものである。
［第１の局面］
ライブデータサービスの作動状態を、サーバによりモニタするステップと；
前記作動状態において例外が発生したことを検出すると、予測修復時間を特定するステップと；
前記予測修復時間に基づいて第１のレートを計算するステップと；
端末デバイスが前記第１のレートに基づいてライブデータを表示するように、計算された前記第１のレートを前記端末デバイスへ送信するステップと；を備える、
データ処理のための方法。
［第２の局面］
予測修復時間を特定する前記ステップは：
予測修復時刻を特定するステップと；
前記ライブデータサービスの作動状態に例外が発生した時刻を特定するステップと；
特定された前記予測修復時刻と、特定された前記時刻とに基づいて前記予測修復時間を特定するステップと；を具体的に備える、
第１の局面に記載のデータ処理のための方法。
［第３の局面］
前記予測修復時間に基づいて第１のレートを計算する前記ステップは：
前記ライブデータサービスの作動状態において例外が発生すると、前記端末デバイスによる前記ライブデータの更新を停止する時刻を特定するステップと；
前記端末デバイスによる前記ライブデータの表示を停止する特定された前記時刻と、前記予測修復時間とに基づいて前記第１のレートを特定するステップと；を具体的に備え、
予測修復時間が長いほど第１のレートは低い、
第２の局面に記載のデータ処理のための方法。
［第４の局面］
前記ライブデータサービスの作動状態が正常に戻ったことが検出されると、修復時間差を特定するステップと；
前記修復時間差に基づいて第２のレートを計算するステップと；
前記端末デバイスが前記第２のレートに基づいて前記ライブデータを表示するように、計算された第２の時間経過レートを前記端末デバイスへ送信するステップと；を更に備える、
第３の局面に記載のデータ処理のための方法。
［第５の局面］
修復時間差を特定する前記ステップは：
前記ライブデータサービスの作動状態が正常に戻る時刻を特定するステップと；
前記ライブデータサービスの作動状態が正常に戻る前記時刻と、前記予測修復時間とに基づいて、前記修復時間差を特定するステップと；を具体的に備える、
第４の局面に記載のデータ処理のための方法。
［第６の局面］
前記修復時間差に基づいて第２の時間経過レートを計算する前記ステップは：
前記修復時間差と前記第１のレートとに基づいて前記第２のレートを特定するステップ；を具体的に備え、
修復時間差が小さいほど第２のレートは高い、
第５の局面に記載のデータ処理のための方法。
［第７の局面］
サーバによって送信される第１のレートを、端末デバイスによって受信するステップであって、前記第１のレートは、作動状態において例外が発生したことを前記サーバが検出すると、前記サーバによって特定された予測修復時間に基づいて前記サーバによって計算される、前記受信するステップと；
前記第１のレートに基づいてライブデータを表示するステップと；を備える、
データ処理のための方法。
［第８の局面］
前記サーバによって送信される第２のレートを、前記端末デバイスによって受信するステップであって、前記第２のレートは、前記サーバがライブデータサービスの作動状態が正常に戻ったことを検出すると、前記サーバによって特定される修復時間差に基づいて前記サーバによって計算される、前記受信するステップと；
前記第２のレートに基づいて前記ライブデータを表示するステップと；を更に備える、
第７の局面に記載のデータ処理のための方法。
［第９の局面］
ライブデータサービスの作動状態をモニタするよう構成されたモニタモジュールと；
前記作動状態において例外が発生したことを検出すると、予測修復時間を特定するよう構成された予測モジュールと；
前記予測修復時間に基づいて第１のレートを計算するよう構成された計算モジュールと；
端末デバイスが前記第１のレートに基づいてライブデータを表示するように、計算された前記第１のレートを前記端末デバイスへ送信するよう構成された送信モジュールと；を備える、
データを処理するためのデバイス。
［第１０の局面］
サーバによって送信される第１のレートを受信するよう構成された受信モジュールであって、前記第１のレートは、作動状態において例外が発生したことを前記サーバが検出すると、前記サーバによって特定される予測修復時間に基づいて前記サーバによって計算される、前記受信モジュールと；
前記第１のレートに基づいてライブデータを表示するよう構成された表示モジュールと；を備える、
データを処理するためのデバイス。

Claims (7)

1. 所定の時間間隔で所定の量のライブデータを生成するように構成されたライブデータサービスの作動状態を、サーバによりモニタするステップ（Ｓ２０１）と；
   前記作動状態において例外が発生したことを検出すると、予測修復時間を特定するステップ（Ｓ２０２）と；
   前記予測修復時間に基づいて第１のレートを計算するステップ（Ｓ２０３）と；
   前記第１のレートに基づいてライブデータを表示するように、計算された前記第１のレートを端末デバイスへ送信するステップ（Ｓ２０４）と；を備え、
   予測修復時間を特定する前記ステップは：
   予測修復時刻を特定するステップと；
   前記ライブデータサービスの作動状態に例外が発生した例外時刻を特定するステップと；
   特定された前記予測修復時刻と、前記例外時刻とに基づいて前記予測修復時間を特定するステップと；を備え、
   前記予測修復時間に基づいて第１のレートを計算する前記ステップは：
   前記ライブデータサービスの作動状態において例外が発生すると、前記端末デバイスによる前記ライブデータの更新を停止する停止時刻を特定するステップと；
   前記端末デバイスによる前記ライブデータの表示を停止する前記停止時刻と、前記予測修復時間とに基づいて前記第１のレートを特定するステップと；を備え、
   予測修復時間が長いほど第１のレートは低い、
   データ処理のための方法。
2. 前記ライブデータサービスの作動状態が正常に戻ったことが検出されると、修復時間差を特定するステップと；
   前記修復時間差に基づいて第２のレートを計算するステップと；
   前記端末デバイスが前記第２のレートに基づいて前記ライブデータを表示するように、計算された第２のレートを前記端末デバイスへ送信するステップと；を更に備える、
   請求項１に記載のデータ処理のための方法。
3. 修復時間差を特定する前記ステップは：
   前記ライブデータサービスの作動状態が正常に戻る時刻を特定するステップと；
   前記ライブデータサービスの作動状態が正常に戻る前記時刻と、前記予測修復時間とに基づいて、前記修復時間差を特定するステップと；を備える、
   請求項２に記載のデータ処理のための方法。
4. 前記修復時間差に基づいて第２のレートを計算する前記ステップは：
   前記修復時間差と前記第１のレートとに基づいて前記第２のレートを特定するステップ；を備え、
   修復時間差が小さいほど第２のレートは高い、
   請求項２又は請求項３に記載のデータ処理のための方法。
5. 前記ライブデータサービスは、表示用のライブデータを生成するために対応する統計処理を実行する、
   請求項１乃至請求項４のいずれか１項に記載のデータ処理のための方法。
6. 前記ライブデータは、前記例外のため異常なレートで生成される、
   請求項１乃至請求項５のいずれか１項に記載の方法。
7. デバイスは、請求項１〜請求項６のいずれか１項に記載のデータ処理のための方法を実行するように構成された、複数のモジュールを含む、
   データを処理するためのデバイス。
   

Images