▶ ベイジン バイドゥ ネットコム サイエンス アンド テクノロジー カンパニー リミテッドの特許一覧
特許7127010リソースの割り当て方法、装置、電子設備、コンピュータ可読媒体およびコンピュータプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-08-19
(45)【発行日】2022-08-29
(54)【発明の名称】リソースの割り当て方法、装置、電子設備、コンピュータ可読媒体およびコンピュータプログラム
(51)【国際特許分類】
G06F 9/50 20060101AFI20220822BHJP
【ＦＩ】
G06F9/50 120Z
【請求項の数】
21
【外国語出願】
(21)【出願番号】P 2019227531
(22)【出願日】2019-12-17
(65)【公開番号】P2020173778
(43)【公開日】2020-10-22
【審査請求日】2020-05-15
(31)【優先権主張番号】201910289283.9
(32)【優先日】2019-04-11
(33)【優先権主張国・地域又は機関】CN
(73)【特許権者】
【識別番号】514322098
【氏名又は名称】ベイジン バイドゥ ネットコム サイエンス テクノロジー カンパニー リミテッド
【氏名又は名称原語表記】Ｂｅｉｊｉｎｇ Ｂａｉｄｕ Ｎｅｔｃｏｍ Ｓｃｉｅｎｃｅ Ｔｅｃｈｎｏｌｏｇｙ Ｃｏ．， Ｌｔｄ．
【住所又は居所原語表記】２／Ｆ Ｂａｉｄｕ Ｃａｍｐｕｓ， Ｎｏ．１０， Ｓｈａｎｇｄｉ １０ｔｈ Ｓｔｒｅｅｔ， Ｈａｉｄｉａｎ Ｄｉｓｔｒｉｃｔ， Ｂｅｉｊｉｎｇ １０００８５， Ｃｈｉｎａ
(74)【代理人】
【識別番号】100179969
【弁理士】
【氏名又は名称】駒井 慎二
(74)【代理人】
【識別番号】100173532
【弁理士】
【氏名又は名称】井上 彰文
(72)【発明者】
【氏名】ソン ファンユエン
(72)【発明者】
【氏名】ウ ジンリン
【審査官】坂東 博司
(56)【参考文献】
【文献】特開２０１８－０９７８３７（ＪＰ，Ａ）
【文献】特開２００７－１２２６６４（ＪＰ，Ａ）
【文献】特開２００９－１４００７９（ＪＰ，Ａ）
【文献】特開２０１５－２０４０２６（ＪＰ，Ａ）
【文献】米国特許出願公開第２０１６／００７２７６６（ＵＳ，Ａ１）
【文献】特開２０１０－１７６６３７（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ ９／５０
(57)【特許請求の範囲】
【請求項1】
コンピュータにより実行される、リソースの割り当て方法であって、クライアントから送信されたリクエストから、ターゲットサブサーバにマッチするリソースカテゴリ及び前記リソースカテゴリに対応する需要クォータを抽出するステップと、
前記リクエストに含まれるターゲットサブサーバ数を、前記リクエストを受信するサブサーバグループのサブサーバ数として決定するステップと、
前記リソースカテゴリにマッチするグローバル利用可能クォータ及び予め指定された総バーストを取得するステップと、
前記総バースト及びサブサーバ数に基づいて、前記ターゲットサブサーバにおける、前記リソースカテゴリにマッチするバーストを決定するステップと、
前記需要クォータと前記バーストとの比較結果に基いて、前記リクエストに対し、前記需要クォータに対応するリソース量でリソースを割り当てる操作を実行するステップと、
を含むことを特徴とするリソースの割り当て方法。
【請求項2】
前記需要クォータと前記バーストとの比較結果に基いて、前記リクエストに対し、前記需要クォータに対応するリソース量でリソースを割る当てる操作を実行するステップは、前記需要クォータが前記バースト以下であることに応じて、前記バーストに対応するリソース量から、前記リクエストに対して、前記需要クォータに対応するリソース量を割り当てるステップを含む、請求項１に記載のリソースの割り当て方法。
【請求項3】
前記バーストに対応するリソース量から、前記リクエストに対して、前記需要クォータに対応するリソース量を割り当てるステップの後に、更に前記ターゲットサブサーバから送信された、前記需要クォータが割り当てられた後の残りのバーストを定時的に受信するステップと、
前記ターゲットサブサーバにおける残りのバーストに対応するリソース量へ補充するために、前記グローバル利用可能クォータに対応するリソース量から前記需要クォータに対応するリソース量を割り当てるステップと、
を含む、請求項２に記載のリソースの割り当て方法。
【請求項4】
前記需要クォータと前記バーストとの比較結果に基づいて、前記リクエストに対し、前記需要クォータに対応するリソース量でリソースを割り当てる操作を実行するステップ、前記需要クォータが前記バーストを上回ることに応じて、前記ターゲットサブサーバから、前記リクエストに対して、前記需要クォータに対応するリソース量を割り当てるステップと、
前記需要クォータを前記ターゲットサブサーバに記録するステップと、
を含む、請求項１に記載のリソースの割り当て方法。
【請求項5】
前記需要クォータを前記ターゲットサブサーバに記録するステップの後に、更に前記ターゲットサブサーバから送信された、前記記録された需要クォータを受信するステップと、
クライアントから送信された再度のリクエストを受信するステップと、
前記再度のリクエストを受信したことに応じて、前記グローバル利用可能クォータに対応するリソース量から、前記記録された需要クォータに対応するリソース量を差引くステップと、
を含む、請求項４に記載のリソースの割り当て方法。
【請求項6】
前記需要クォータを前記ターゲットサブサーバに記録するステップの後に、更に記録周期を計時するステップと、
前記ターゲットサブサーバから送信された、前記記録された需要クォータを受信するステップと、
前記記録周期が予め設定された時間の長さに達したことに応じて、前記グローバル利用可能クォータに対応するリソース量から、前記需要クォータに対応するリソース量を差し引くステップと、
を含む、請求項４に記載のリソースの割り当て方法。
【請求項7】
グローバル利用可能クォータの現在残りのクォータが前記バーストより小さいかを判断するステップと、グローバル利用可能クォータの現在残りのクォータが前記バーストより小さいと判断されたことに応じて、前記バーストに対応するクォータを前記グローバル利用可能クォータの現在残りのクォータに更新するステップと、
を更に含む、請求項３ないし６のいずれか１項に記載のリソースの割り当て方法。
【請求項8】
コンピュータにより実行される、リソースの割り当て方法であって、クライアントから送信された、リソースカテゴリ情報及び前記リソースカテゴリ情報にマッチする総需要クォータを含むリクエストを受信するステップと、
前記リクエストにおけるリソースカテゴリ情報にマッチする総需要クォータに対し、前記リクエストにおけるリソースカテゴリ情報にマッチするグローバル利用可能クォータ及び予め指定された総バーストを取得することと、前記グローバル利用可能クォータがプリセット値を上回るかを判断することと、前記グローバル利用可能クォータがプリセット値を上回ると判断されたことに応じて、前記グローバル利用可能クォータと前記総バーストとを合計して、クォータ総量とすることと、前記総需要クォータが前記クォータ総量以下であるかを判断することと、前記総需要クォータが前記クォータ総量以下であると判断されたことに応じて、前記リソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たすと決定することとを、含む決定ステップを実行するステップと、
前記リクエストにおける各リソースカテゴリ情報の対応する総需要クォータに対し前記決定ステップを実行することにより、各リソースカテゴリ情報の対応する総需要クォータがそれぞれリソースの割当条件を満たすかを判断するステップと、
それぞれ満たすと判断されたことに応じて、前記リクエストが受け付けられたことを表す指示情報を生成し、請求項１～７のいずれか一項に記載の方法を用いて、前記リクエストされた各リソースカテゴリに対してリソースの割り当て操作を実行するステップと、
を含むことを特徴とするリソースの割り当て方法。
【請求項9】
更に、前記リクエストのいずれかのリソースカテゴリ情報の対応する総需要クォータがリソースの割り当て条件を満たしていないことに応じて、前記リクエストのインターセプトを示す指示情報を生成するステップと、を含む請求項８に記載のリソースの割り当て方法。
【請求項10】
リソースの割り当て装置であって、クライアントから送信されたリクエストからターゲットサブサーバにマッチするリソースカテゴリ及び前記リソースカテゴリに対応する需要クォータを抽出するように構成される情報抽出ユニットと、
前記リクエストに含まれるターゲットサブサーバ数を、前記リクエストを受信するサブサーバグループのサブサーバ数として決定するように構成されている第１の処理ユニットと、
前記リソースカテゴリにマッチするグローバル利用可能クォータ及び予め指定された総バーストを取得するように構成される第２の処理ユニットと、
前記総バースト及び前記サブサーバ数に基づいて、前記ターゲットサブサーバにおける、前記リソースカテゴリにマッチするバーストを決定するように構成されるバースト決定ユニットと、
前記需要クォータと前記バーストとの比較結果に基づいて、前記リクエストに対し、前記需要クォータに対応するリソース量でリソースを割り当てる操作を実行するように構成されるリソースの割り当て操作処理ユニットと、
を含むことを特徴とするリソースの割り当て装置。
【請求項11】
前記リソースの割り当て操作処理ユニットは、更に、前記需要クォータが前記バースト以下であることに応じて、前記バーストに対応するリソース量から、前記リクエストに対して、前記需要クォータに対応するリソース量を割り当てるように構成される、ことを特徴とする請求項１０に記載のリソースの割り当て装置。
【請求項12】
前記リソースの割り当て操作処理ユニットには、更に前記ターゲットサブサーバから送信された、前記需要クォータを割り当てた後の残りのバーストを定期的に受信するように構成される受信モジュールと、
前記ターゲットサブサーバにおける前記残りのバーストに対応するリソース量へ補充するために、前記グローバル利用可能クォータに対応するリソース量から、前記需要クォータに対応するリソース量を割当するように構成される第１のリソース割り当てモジュールと、
を含むことを特徴とする請求項１１に記載のリソースの割り当て装置。
【請求項13】
前記リソースの割り当て操作処理ユニットは、前記需要クォータが前記バーストを上回ることに応じて、前記ターゲットサブサーバから、前記リクエストに対して、前記需要クォータに対応するリソース量を割り当てるように構成される第２のリソース割り当てモジュールと、
前記需要クォータを前記ターゲットサブサーバに記録するように構成される記録モジュールと、
を含むことを特徴とする請求項１０に記載のリソースの割り当て装置。
【請求項14】
前記ターゲットサブサーバから送信された、前記記録された需要クォータを受信するように構成される第１の情報受信ユニットと、クライアントより送信された再度リクエストを受信するように構成される第１のリクエスト受信ユニットと、
前記再度リクエストを受信したことに応じて、前記グローバル利用可能クォータに対応するリソース量から、前記記録された需要クォータに対応するリソース量を差引くように構成される第３の処理ユニットと、
をさらに含む、請求項１３に記載のリソースの割り当て装置。
【請求項15】
前記装置は、記録周期を計時するように構成される計時ユニットと、
前記ターゲットサブサーバから送信された、前記記録された需要クォータを受信するように構成される第２の情報受信ユニットと、
前記記録周期が予め設定された時間の長さに達したことに応じて、前記グローバル利用可能クォータに対応するリソース量から、前記需要クォータに対応するリソース量を差引くように構成される第４の処理ユニットと、
を更に含む、請求項１３に記載のリソースの割り当て装置。
【請求項16】
前記装置は、更にグローバル利用可能クォータの現在残りのクォータが前記バーストより小さいかを判断するように構成される比較ユニットと、
グローバル利用可能クォータの現在残りのクォータが前記バーストより小さいと判断されたことに応じて、前記バーストに対応するクォータをグローバル利用可能クォータの現在残りのクォータに更新するように構成されるクォータ更新ユニットと、
を含む、請求項１２～１５のいずれか一項に記載のリソースの割り当て装置。
【請求項17】
リソースの割り当て装置であって、クライアントから送信されたリクエストを受信するように配置される第２のリクエスト受信ユニットであって、前記リクエストは、リソースカテゴリ情報及び前記リソースカテゴリ情報にマッチする総需要クォータを含む第２のリクエスト受信ユニットと、
前記リクエストにおけるリソースカテゴリ情報にマッチする総需要クォータに対し、前記リクエストにおけるリソースカテゴリ情報にマッチするグローバル利用可能クォータ及び予め指定された総バーストを取得することと、前記グローバル利用可能クォータがプリセット値を上回るかを判断することと、前記グローバル利用可能クォータがプリセット値を上回ると判断されたことに応じて、前記グローバル利用可能クォータと前記総バーストとを合計して、クォータ総量とすることと、前記総需要クォータが前記クォータ総量以下であるかを判断することと、前記総需要クォータが前記クォータ総量以下であると判断されたことに応じて、前記リソースカテゴリ情報に対応する総需要クォータがリソース割り当て条件を満たすと決定することと、を含む決定ステップを実行するように構成される需要クォータ決定ユニットと、
前記リクエストの各リソースカテゴリ情報の対応する総需要クォータに対し、前記決定ステップを実行して、各リソースカテゴリ情報の対応する総需要クォータがそれぞれリソースの割り当て条件を満たすかを判定するように構成される決定ステップ実行ユニットと、
それぞれリソースの割り当て条件を満たすと判断されたことに応じて、前記リクエストが受け付けられたことを示す指示情報を生成し、且つ、請求項１～７のいずれ１項に記載の方法を利用し、前記リクエストの各リソースカテゴリに対し、それぞれリソースの割り当て操作を実行するように構成される第５の処理ユニットと、
を含むことを特徴とするリソースの割り当て装置。
【請求項18】
前記リクエストのいずれかのリソースカテゴリ情報の対応する総需要クォータがリソースの割り当て条件を満たしていないことに応じて、前記リクエストのインターセプトを示す指示情報を生成するように構成される指示情報生成ユニット、をさらに含む、請求項１７に記載のリソースの割り当て装置。
【請求項19】
電子設備であって、１つ又は複数のプロセッサと、
１つ又は複数のプログラムが記憶されている記憶装置と、を含み、
前記１つ又は複数のプログラムが前記１つ又は複数のプロセッサに実行されると、請求項１～９のいずれか１項に記載の方法を前記１つ又は複数のプロセッサに実行させることを特徴とする電子設備。
【請求項20】
コンピュータプログラムが記憶されているコンピュータ可読媒体であって、前記コンピュータプログラムがプロセッサによって実行されると、請求項１～９のいずれかに記載の方法を実現するコンピュータ可読媒体。
【請求項21】
コンピュータプログラムであって、プロセッサによって実行されると、請求項１～９のいずれかに記載の方法を実現するコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示の実施例はコンピュータ技術分野に関し、具体的にリソースの割り当て方法、装置、電子設備、コンピュータ可読媒体およびコンピュータプログラムに関する。
【背景技術】
【0002】
コンピュータ技術分野では、クォータとは、ノード上において、リソースの過剰消費を防止するために各エンティティによるリソースの消費を追跡、制御するとともに、リソースの割り当ての統計と報告を行うためのメカニズムである。当該リソースには、例えば、ディスクスペース、メモリ、ＣＰＵなどが含まれる。エンティティには、例えば、個人ユーザ、組織、プロセスなどが含まれる。
【0003】
従来技術では、リソースの割り当てのクォータを判定する方式は、通常、スタンドアロンのクォータ管理とグローバルクォータ控除メカニズムとがある。スタンドアロンのクォータ管理では、ローカルで利用可能なクォータ量を継続的に差し引き、ローカルで利用可能なクォータが足りない場合、リクエストを直接拒否する。即ち、ローカルで利用可能なクォータを初期化し、そして、リクエストを受信すると、需要クォータを差し引き、その後、現在のローカルで利用可能なクォータが０より大きいかを判断する。グローバルクォータ控除メカニズムは、分散システムで利用されるメカニズムであって、リクエストを受信すると、グローバルストレージ（一般的には集中キャッシュ）のクォータを差し引き、その後、利用可能なクォータがあるかどうかを判断し、残りのクォータが足りている場合、リクエストを受け付ける一方、足りない場合は、リクエストを拒否する。
【発明の概要】
【0004】
本開示の実施例はリソースの割り当て方法、装置、電子設備、コンピュータ可読媒体およびコンピュータプログラムを提案する。
【0005】
本開示の実施形態によるリソース割当方法と装置において、クライアントから送信されたリクエストから、ターゲットサブサーバにマッチするリソースカテゴリと、当該リソースカテゴリに対応する需要クォータを抽出する。次に、当該リクエストを受信したサブサーバグループにおけるサブサーバ数を決定し、そして、リソースカテゴリにマッチするグローバル利用可能クォータ及び総バーストを決定する。その後、当該需要クォータとサブサーバ数に基づいて、ターゲットサブサーバのうち、当該リソースカテゴリにマッチするバーストを決定する。最後に、当該需要クォータとバーストとの比較結果に基づいて、当該リクエストに対して、当該需要クォータに対応するリソース量でリソースを割り当てる操作を実行する。ターゲットサブサーバのバーストは、総バーストとサブサーバ数に基づいて決定されるので、これらのバーストは、ターゲットサブサーバのローカル利用可能クォータとして理解できる。その後、需要クォータとバーストの比較結果に基づいて、リクエストに対して、需要クォータに対応するリソース量で、リソースを割り当てる操作を実行することにより、分散型環境において、リソースクォータを合理的に割り当て、サーバの資源を合理的に利用する。また、ターゲットサブサーバに対してローカル利用可能クォータを割り当てる。リソースクォータを合理的に配置することにより、グローバル利用可能クォータに対するリクエスト回数を減少させ、サーバによるリクエストの処理速度を上げることができる。
【図面の簡単な説明】
【0006】
以下の図面を参照しながら非限定的な実施例を詳しく記述することによって、本開示の他の特徴、目的および利点は、より明らかになる。
【図1】本開示の一実施例が適用される例示的なシステムアーキテクチャー図である。
【図2】本開示に係るリソースの割り当て方法の一実施例のフローチャートである
【図3】本開示の実施例に係るリソースの割り当て方法の一適用シナリオの模式図である。
【図4】本開示の実施例に係るリソースの割り当て方法の別の適用シナリオの模式図である。
【図5】本開示の実施例に係るリソースの割り当て方法の更なる適用シナリオの模式図である。
【図7】本開示に係るリソース割り当て方法の別実施例のフローチャートである。
【図11】本開示の実施例を実施する電子設備の模式的構成図である。
【発明を実施するための形態】
【0007】
以下、図面及び実施例を参照しながら本開示をより詳細に説明する。ここで記述される具体的な実施例は、関連発明を説明するためのものに過ぎず、当該発明を限定するものではないと理解すべきである。なお、説明の便宜上、図面に、かかる発明に関連する部分のみが示されている。
【0008】
なお、矛盾しない限り、本開示の実施例や実施例における特徴を相互に組み合せてもよい。以下、図面及び実施例を参照しながら本開示を詳細に説明する。
【0009】
図１は本開示のリソースの割り当て方法又はリソースの割り当て装置を適用できる実施例の例示的なシステムアーキテクチャー１００を示す。
【0010】
図１に示されるように、システムアーキテクチャー１００は、端末装置１０１、１０２、１０３、ネットワーク１０４及びサーバ１０５を含んでもよい。ネットワーク１０４は、端末装置１０１、１０２、１０３とサーバ１０５との間に通信リンクを提供する媒体として用いられている。ネットワーク１０４は有線、無線通信リンク、又は光ファイバーケーブル等の各種接続タイプを含んでもよい。
【0011】
端末装置１０１、１０２、１０３はネットワーク１０４を介してサーバ１０５とインタラクションして、メッセージなどを送受信する。端末装置１０１、１０２、１０３に、例えばショッピングアプリケーション、検索アプリケーション、インスタントメッセージングツール、メールボックスクライアント、ソーシャルソフトウェアプラットフォームソフトウェア、テキスト編集アプリケーション、ブラウザアプリケーション、読書アプリケーション等の様々な通信クライアントアプリケーションがインストールすることができる。
【0012】
端末装置１０１、１０２、１０３はハードウェアでもよく、ソフトウェアでもよい。端末装置１０１、１０２、１０３がハードウェアである場合に、ディスプレイを備えるものであって、サーバにリクエストを送信可能な各種の電子機器であっても良く、スマートフォン、タブレットＰＣ、ｅ－Ｂｏｏｋリーダー、ＭＰ３プレーヤー （Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ Ａｕｄｉｏ Ｌａｙｅｒ ＩＩＩ、ムービング・ピクチャー・エクスパーツ・グループオーディオレイヤーＩＩＩ）、ＭＰ４プレーヤー（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ Ａｕｄｉｏ ＬａｙｅｒＩＶ、ムービング・ピクチャー・エクスパーツ・グループオーディオレイヤーＩＶ）、ラップトップ型コンピュータ及びデスクトップコンピュータなどを含むが、それらに限定されない。端末設備１０１、１０２、１０３がソフトウェアである場合に、前記挙げた電子機器にインストールすることができ、複数のソフトウェア又はソフトウェアモジュール（例えば、分散型サービス提供用）、或いは単一のソフトウェア又はソフトウェアモジュールとして実装することが可能である。ここでは具体的な限定をしない。
【0013】
サーバ１０５は各種のサービスを提供するサーバ、例えば端末装置１０１、１０２、１０３よって送信されたリクエストを受信するバックグラウンドサーバであり得る。当該バックグランドサーバはクライアントによって送信されたリクエストに対しリソースの割り当て処理等を行うことができる。
【0014】
なお、サービスエンドやクライアントはハードウェアでもよく、ソフトウェアでもよい。サービスエンドやクライアントがハードウェアである場合に、複数のサーバから成る分散型サーバクラスタとして実施されても良く、また、単一のサーバとして実施されてもよい。サービスエンドやクライアントがソフトウェアである場合に、複数のソフトウェア又はソフトウェアモジュール（例えば、分散型サービス提供用）として実施されてもよく、単一のソフトウェア又はソフトウェアモジュールとして実施されてもよい。ここでは具体的な限定をしない。
【0015】
なお、本開示の実施例によるリソースの割り当て方法は、通常サーサーバ１０５により実行される。それに応じて、リソースの割り当て装置は、通常サーバ１０５に設置されている。
【0016】
なお、図１で示す端末装置、ネットワーク及びサーバの数は例示的なものに過ぎない。必要に応じて、端末装置、ネットワーク及びサーバの数が任意であってもよい。
【0017】
続いて、本開示に係るリソースの割り当て方法の一実施例のフロー２００を示す図２を参照する。前記リソースの割り当て方法は、ステップ２０１～ステップ２０５を含む。
【0018】
ステップ２０１において、クライアントより送信されたリクエストから、ターゲットサブサーバにマッチするリソースカテゴリ及び当該リソースカテゴリに対応する需要クォータを抽出する。
【0019】
本実施例では、リソースの割り当て方法を実行する主体は（図１で示されたサーバ１０５）、クライアントより送信されたリクエストからターゲットサブサーバにマッチするリソースカテゴリ及び当該リソースカテゴリに対応する需要クォータを抽出することができる。
【0020】
ここで、リソースは、例えば、ディスクスペース、メモリ、ＣＰＵでも可能である。ここで言うリソースカテゴリは、例えばディスクスペースのようなリソースの一種を指す。当該リソースカテゴリに対応する需要クォータは、例えば、リソースカテゴリとしてディスクスペースに対応する、１のサブサーバでの需要クォータ２ＭＢである。即ち、当該リクエストには、当該サブサーバにおいてディスクスペースのリソースクォータが２ＭＢ必要です。分散型環境において、あるリクエストに対し、複数のサブサーバが当該リクエストを受信するとともに、協力して実行する必要があるかもしれない。ターゲットサブサーバは、これらのサブサーバのうち、サーバが当該リソースの割り当て方法を実行するサブサーバであると理解できる。上記の例が、本実施形態のリソースの割り当て方法をより良く説明するためのものであり、本実施形態に対する限定としてはならない。
【0021】
ステップ２０２において、当該リクエストを受信したサブサーバグループにおけるサブサーバ数を決定する。
【0022】
本実施例では、上記の実行主体は、当該リクエストを受信したサブサーバグループにおけるサブサーバ数を決定することができる。ここで、サブサーバグループは、分散型環境において、当該リクエストを受信した複数のサブサーバから成るサブサーバグループであると理解できる。
【0023】
例として、クライアントは、ドキュメントをダウンロードするリクエストをサーバに送信する。サブサーバグループにおけるサブサーバはともに当該リクエストを受信する。例えば、当該リク エストは、第１のサブサーバのメモリリソースが２ＧＢ、第２のサーバのメモリリソースが５Ｇ Ｂ、第３のサーバのモリリソースが３ＧＢ必要である（説明するために挙げられた例に過ぎず、これらに限定しない）ことを想定する。サーバは当該サブサーバにおいて当該リクエストを受信するサブサーバ数が３であるという情報を獲得することができる。
【0024】
ステップ２０３において、当該リソースカテゴリにマッチするグローバル利用可能クォータ及び総バーストを決定する。
【0025】
本実施例では、上記実行主体は、当該リソースカテゴリにマッチするグローバル利用可能クォータ及び総バーストを決定することもできる。ここで、グローバル利用可能クォータ（ｑｕｏｔａ）は、当該リソースカテゴリのリソースのために指定された利用可能クォータ、即ち、通常の状況において利用可能なリソース量であると理解できる。総バースト（ｂｕｒｓｔ）は、当該リソースカテゴリのリソースに対し指定される利用可能な容量、つまりリソースの許容される超過額の最大限として理解できる。
【0026】
例として、サーバはリクエスト中のメモリリソースに対し、当該リソースのグローバル利用可能クォータ（ｑｕｏｔａ）を１００ＧＢ、総バースト（ｂｕｒｓｔ）を２０ＧＢと指定することができる。
【0027】
ステップ２０４において、総バーストとサブサーバ数に基づいて、ターゲットサブサーバにおける当該リソースカテゴリに対応するバーストを決定する。
【0028】
本実施例では、上記実行主体は、総バースト及びサブサーバ数を取得した後、ターゲットサブサーバにおける当該リソースカテゴリに対応するバーストを決定することができる。例えば、当該リソースカテゴリの総バーストは２０（ここでは、説明のために例として挙げた数字に過ぎず、リソースの種類についての限定を構成しない）、サブサーバ数は、例えば３として決定される。
【0029】
例として、サーバは、総バースト２０をサブサーバ数３で割って、ターゲットサブサーバにおけるリソースカテゴリにマッチするバーストを整数の６を得る。別の例として、サーバは総バースト２０に対し割当を行う。例えば、第１のサバサーバに対し、当該リソースカテゴリにマッチするバースト１０を割り当て、第２のサブサーバに対し、当該リソースカテゴリにマッチするバースト５を割り当て、第３のサブサーバに対し、当該リソースカテゴリにマッチするバースト５を割り当てる。ここの第１のサブサーバがターゲットサブサーバであるとすると、当該リソースカテゴリにマッチするバーストは１０である。
【0030】
ステップ２０５において、当該需要クォータとバーストの比較結果に基づいて、当該リクエストに対し、当該需要クォータに対応するリソース量でリソースを割り当てる操作を実行する。
【0031】
本実施例では、上記実行主体は、当該ターゲットサブサーバにおける当該リソースカテゴリにマッチするバーストを取得した後、当該リクエストにおける当該リソースカテゴリに対応する需要クォータを当該バーストと比較し、比較結果を得る。当該比較結果に応じて、当該リクエストに対し、当該需要クォータに対応するリソース量でリソースを割り当てる操作を実行する。これにより、グローバル利用可能クォータとサブサーバのローカル利用可能クォータとを組み合わせて使用することで、グローバル利用可能クォータへのリクエスト回数を減少させる。
【0032】
例として、本実施例のいくつかの選択可能な実施形態において、当該需要クォータが当該バースト以下であることに応じて、上記実行主体は、バーストに対応するリソース量から、当該リクエストに対して、当該需要クォータに対応するリソース量を割り当てる。例えば、当該ターゲットサブサーバについて、バーストは６であり、当該リソースカテゴリに対応する需要クォータは３である場合、上記実行主体は、ターゲットサブサーバにおける当該バーストから、直接当該需要クォータ３を割り当てることができる。即ち、ターゲットサブサーバは、当該リソースクォータリクエストに応答するために、サーバにおけるグローバル利用可能クォータを請求することなく、ローカル利用可能クォータから、リソースを割り当てることができる。それによって、リクエストに素早く応答し、プロセッサのリクエスト処理速度を速めることができる。
【0033】
バーストに対応するリソース量から、当該リクエストに対して、当該需要クォータに対応するリソース量を割り当てた後、本実施例のいくつかの選択なの宇な実施形態において、上記実行主体は、ターゲットサブサーバによって送信された、当該リクエストを割り当てた後の残りのバーストを定期的受信することもできる。その後、ターゲットサブサーバにおける残りのバーストに対応するリソース量へ補充するために、サーバは、グローバル利用可能クォータに対応するリソース量から、当該需要クォータに対応するリソース量を割り当てることができる。例えば、ターゲットサブサーバにおける、リソースカテゴリのリソースに対応する最初のバーストは６であり、即ち、ローカル利用可能クォータは６である。一方で、リクエストにおける、当該リソースカテゴリに対応する需要クォータは３である。ターゲットサブサーバのローカル利用可能クォータから３を差し引いた後、残りのバーストは６－３＝３である。ターゲットサブサーバは、定期的に残りのバーストをサーバに報告する。ターゲットサブサーバのバーストを依然として初期値６にするように、ターゲットサブサーバへ補充するために、サーバは、グローバル利用可能なクォータから、需要クォータ３に対応するリソース量を割り当てることができる。
【0034】
図３で示されている応用シナリオを例とすると、三つのサブサーバのローカルクォータはいずれも６（バーストは３０３）であり、初期段階において、リクエストを受信していないため、ローカルカウンタ３０４は０である。この場合、グローバル利用可能クォータ３０２が１００であると仮定すると、現在利用可能クォータ総量３０１は１００＋３×６＝１１８となる。
【0035】
次に、周期内にリクエストを一回受信すると、当該リソースについて、三つのサブサーバはそれぞれ対応する需要クォータが３、２、４である。この場合、まず、当該需要クォータをローカルカウントする。即ち、三つのサブサーバについて、ローカルカウント３０４はそれぞれ３、２、４である。
【0036】
需要クォータ３、２と４はいずれもバーストの６より小さいので、ローカル利用可能クォータ（バースト３０３）から当該需要クォータに対応するリソースクォータを直接に差し引いてもよい。差し引いた後、三つのサブサーバのローカル利用可能クォータは、それぞれ６－３＝３、６－２＝４、６－４＝２となる。
【0037】
その後、５ｓでローカルカウントをサーバに報告する。サーバはグローバル利用可能クォータ１００からクォータ３、２、４を差し引いて３のサブサーバに補充する。即ち、初期バーストの６になるように、サブサーバのバースト３０３へ補充する。この場合に、グローバル利用可能クォータの残り量は１００－３－２－４＝９１となる。
【0038】
別の例として、本実施形態いくつかの選択可能な実施形態では、当該需要クォータがバーストを上回ることに応じて、上記実行主体は、当該ターゲットサブサーバから、当該リクエストに対して、当該需要クォータに対応するリソース量を割り当てることができる。その後、サーバは、当該需要クォータをターゲットサブサーバに記録する。具体的には、リクエストされる需要クォータがローカル利用可能クォータ（バースト）より大きい場合、クライアントのユーザの使用体験を保証するために、サーバは、まずターゲットサブサーバから、当該需要クォータに対応するリソース量を割り当てることができる。その後、サーバは、当該リクエストにおける当該リソースの需要クォータをターゲットサブサーバに記録し、すなわち、ローカルカウントに記録することができる。
【0039】
次に、例として、ターゲットサブサーバは、記録されたローカルカウンタをサーバにアップロードすることができる。サーバは、当該記録された需要クォータを受信する。その後、サーバは、クライアントから送信された再度リクエストを受信すると、グローバル利用可能クォータに対応するリソース量から、当該記録の需要クォータに対応するリソース量を差し引くことができる。別の例として、サーバは、需要クォータをローカルに記録した後、記録周期を計時する。その後、サーバは、ターゲットサブサーバから送信された、記録された需要クォータを受信した後、記録期間が予め設定された時間に達したかを判断する。当該記録期間が予め設定された時間に達したことに応じて、サーバは、グローバル利用可能クォータに対応するリソース量から需要クォータに対応するリソース量を差し引くことができる。
【0040】
図４で示されている応用シナリオにおいて、三つのサブサーバのローカル利用可能クォータはいずれも６（バースト４０３）である。初期段階において、第１のサブサーバのローカルカウンタ４０４は５（前回のリクエストで第１のサブサーバを使用したリソースクォータ量は５）である。第２及び第３のサブサーバのローカルカウンタはいずれも０である。グローバル利用可能クォータ４０２が１００であると仮定すると、現在利用可能なクォータ総量４０１は１００＋３×６＝１１８となる。
【0041】
次に、受信したリクエストのうち、第１のサブサーバの需要クォータは１５であり、他の二つのサブサーバの需要クォータは０である。この場合、第１のサブサーバは、ローカルカウント５をグローバル利用可能クォータ４０２に報告して差し引く。すると、サーバでは、当該リソースに対応するグローバル利用可能クォータの残りは１００－５＝９５となる。
【0042】
その後、サーバは当該リクエストの需要クォータ１５をターゲットサブサーバのローカルカウンタに記録する。即ち、三つのサブサーバのローカルカウント３０４は、それぞれ１５、０と０である。なお、クライアントのユーザの権益に影響を及ぼさないように、需要クォータ１５に対しローカルカウントをすると同時に、ターゲットサブサーバから、ユーザに使用される当該リソースクォータを先に差し引く。
【0043】
その後、再度リクエストを受信すると、サーバはグローバル利用可能クォータ４０２から前回のローカルカウント１５を差し引くことができる。その時点で、グローバル利用可能クォータの残量は９５－１５＝８０となる。次に、再度リクエストされた需要クォータ３をローカルカウントに記録し、対応するリソース割り当てポリシーを用い、リソース割り当てを行う。
【0044】
本実施形態による上記二つの実施形態として、第１の実施形態では、ローカル利用可能クォータ値を継続的に更新し、ローカル利用可能クォータを優先的に選択して、グローバル利用可能クォータへのリクエスト量を減らし、リクエストを処理するサーバのパフォーマンスを確保する。第２の実施形態では、ローカル利用可能クォータが需要クォータに満たさない場合でも、ユーザのリクエストに対する需要クォータ提供に影響しないとともに、グローバル利用なクォータを適時に同期させることができ、サーバ処理リクエストの柔軟性を向上させる。
【0045】
本実施形態のいくつかの選択可能な実施形態において、ソース割当量の過剰浪費を避けるために、上記実行主体は、グローバル利用可能クォータの現在の残量がバーストを下回るかを判断することができる。下回ると判断したことに応じて、当該バーストに対応するクォータをグローバル利用可能クォータの現在の残量に更新する。
【0046】
具体的には、現在の大多数のリソースの割り当て方法の最後の残量が無駄になってしまう。そこで、ユーザの利用可能なリソースが合理的に利用されるとともに、過剰浪費が発生しないように、当該選択可能な実施形態において、上記実行主体は、各サブサーバにおける当該リソースの許容の超過額であるバーストを総バースト／サブサーバ数に設定することができる。
【0047】
例えば、図５に示されるアプリケーションシナリオでは、各サブサーバのバースト５０３は６であると想定すると、データ同期が数回請求された後、グローバル利用可能クォータ５０２は１０となる。この時点で、利用可能なクォータの総量５０１は１０＋３×６＝２８となる。
【0048】
今回のリクエストでは、三つのサブサーバの対応する需要クォータ（ローカルカウント５０４）は、それぞれ３、１、２である。次に、５ｓ後にローカルカウントをグローバルにアップロードし、当該需要クォータに対応するクォータ値をグローバル利用可能クォータ５０２から差し引き、三つのサブサーバのクォータ値へ補充した後、グローバル利用可能クォータ５０２の残りのクォータは１０－３－１－２＝４となる。
【0049】
この時、グローバル利用可能クォータ５０２の残りのクォータは４であり、三つのサブサーバのバースト６より小さいため、上記実行主体は、サブサーバのバースト５０３を４に更新することができる。このように、最終にリクエストされたリソースの需要クォータの超過額の限度は４×３＝１２である。これにより、割当リソースを合理的に利用し、リソースクォータを過度に無駄しないようにするとともに、サーバのリクエスト処理性能にも影響しないようにする。
【0050】
続いて図６を参照する。図６は、本開示の図２の実施形態にかかるリソースの割り当て方法の適用シナリオの概略図である。図６の適用シナリオでは、サーバ６０１は、クライアント６０２によって送信されたリクエスト６０３（ドキュメント）の中から、ターゲットサブサーバ６０４にマッチするリソースカテゴリ６０５（メモリリソース）と、当該リソースカテゴリ６０５に対応する需要クォータ６０６（５ＧＢ）を抽出する。
【0051】
その後、サーバ６０１は、リクエストを受信したサブサーバグループのサブサーバ数６０７が３であり、メモリリソースにマッチするグローバル利用可能クォータ６０８が１００ＧＢであり、総バースト６０９は２０ＧＢであると決定する。サーバ６０１は、２０ＧＢを三つのサブサーバに均等に分ける。よって、ターゲットサブサーバのバースト６１０は６ＧＢである。
【0052】
それから、サーバ６０１は、需要クォータ５ＧＢをバースト６ＧＢと比較し、比較結果に基づいてリソース割り当て６１１を実行する。例えば、サーバ６０１は、当該需要クォータ５ＧＢが当該バーストの６ＧＢより小さいと判断すると、クライアントの当該リクエストに対し、当該リクエストのメモリリソース需要クォータ５ＧＢに対応するリソース量を、当該ターゲットサブサーバのローカル利用可能クォータ（バースト６１０）に対応するリソース量から割り当てることができる。
【0053】
現在、従来技術の一つとして、通常、すべてのリクエストに対し、グローバルクォータから差し引き、グローバルクォータへのリクエスト量を増加させ、その結果として、サーバの処理速度が遅くなってしまう。これに対し、本開示の上記実施形態による方法は、ターゲットサブサーバのバーストが総バースト及びサブサーバ数に基づいて決定されるもので、これらのバーストは、ターゲットサブサーバのローカル利用可能クォータとして理解できる。そして、需要クォータとバーストの比較結果に基づいて、リクエストに対して需要クォータに対応するリソース量でリソースを割り当てる操作を行う。分散型環境において、リソースクォータを合理的に割当、サーバのリソースを合理的に利用することができる。また、ターゲットサブサーバに対してローカル利用可能クォータを割り当てるとともに、リソースクォータを合理的に配置することにより、グローバル利用可能クォータへのリクエスト回数を減らし、サーバのリクエスト処理の高速化を実現する。
【0054】
更に図７を参照する、リソースの割り当て方法の更なる実施例のプロセス７００が示されている。サーバに適用される当該リソースの割り当て方法のプロセス７００は、次のステップを含む。
【0055】
ステップ７０１において、クライアントが送信されたリクエストを受信する。
【0056】
本実施形態では、リソースの割り当て方法を実行する主体（例えば図１に示すサーバ１０５）は、クライアントから送信されたリクエストを受信することができる。当該リクエストには、リソースカテゴリ情報及び当該リソースカテゴリ情報にマッチする総需要クォータを含む。ここで言うリソースカテゴリ情報にはメモリが含まれてもよい。総需要クォータは、当該リクエストを受信するサーバ数を問わず、特定のリソースがリクエストされるリソースクォータを指す。
【0057】
ステップ７０２において、リクエスト中のリソースカテゴリ情報にマッチングする総需要クォータに対して決定ステップを実行する。
【0058】
本実施形態では、上記実行主体は、リクエストにおけるリソースカテゴリ情報にマッチングする総需要クォータに対して決定ステップ８００を実行する。具体的には、図８に示すように、決定ステップ８００は下記のステップを含んでもよい。
【0059】
ステップ８０１において、リクエストにおけるリソースカテゴリ情報にマッチするグローバル利用可能クォータ及び総バーストを決定する。
【0060】
本実施形態では、上記実行主体は、クライアントから送信されたリクエストを受信すると、当該リクエストにおけるリソースカテゴリ情報にマッチングするグローバル利用可能クォータ及び総バーストを決定することができる。
【0061】
なお、各リソース、例えばメモリリソースについて、サーバは、当該リソースのグローバルリソースクォータ及び許容の超過額限度を予め割り当てておく。ここで言うグローバルリソースクォータは、グローバル利用可能クォータとして理解できる。また、許容の超過額限度は総バーストとして理解できる。
【0062】
ステップ８０２において、グローバル利用可能クォータがプリセット値を上回るかを判定する。
【0063】
本実施形態では、上述した実行主体は当該リソースカテゴリ情報にマッチするグローバル利用可能クォータ及び総バーストを決定した後、当該グローバル利用可能クォータをプリセット値と比較し、グローバル利用可能クォータがプリセット値を上回るかを判定する。例として、ここのプリセット値を０とする場合、サーバは当該グローバル利用可能クォータが０より大きいかどうかを判断できる。
【0064】
ステップ８０３において、グローバル利用可能クォータがプリセット値を上回ることに応じて、当該グローバル利用可能クォータと総バーストを合計して、クォータ総量を得る。
【0065】
本実施形態では、上記実行主体は、グローバル利用可能クォータがプリセット値より大きいと判定した後、グローバル利用可能クォータと総バーストを合計してクォータ総量を得ることができる。例えば、当該リクエストは、メモリリソースのクォータが８０ＧＢ、メモリリソースのグローバル利用可能クォータが１００ＧＢ、総バーストが２０ＧＢ必要であると仮定すると、サーバがメモリリソースのグローバル利用可能クォータ１００ＧＢと総バースト２０ＧＢを合計して、メモリリソースのクォータ総量の１２０ＧＢを得る。
【0066】
ステップ８０４において、当該総需要クォータが当該クォータ総量以下であるかを判断する。
【0067】
本実施形態では、上記実行主体は、当該カテゴリのリソースのクォータ総量を取得した後、当該リソースの需要クォータをクォータ総量と比較して、当該需要クォータがクォータ総量以下であるかを判定することができる。
【0068】
例えばメモリリソースのクォータ総量が１２０ＧＢ、需要クォータが８０ＧＢであるとすると、サーバは需要クォータの８０ＧＢをクォータ総量の１２０ＧＢと比較し、その結果として、需要クォータがクォータ総量より小さいと判明できる。
【0069】
ステップ８０５において、需要クォータがクォータ総量以下である判定に応じて、当該リソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たしていると判定できる。
【0070】
本実施形態では、需要クォータがクォータ総量以下である場合に、上記実行主体は、当該リソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たしていると判定できる。
【0071】
即ち、グローバル利用可能クォータがプリセット値を上回り、且つ、需要クォータがクォータ総量以下である場合こそ、当該リソースカテゴリ情報に対応する需要クォータがリソースの割り当て条件を満たす。その他の場合は、リソースカテゴリ情報に対応する需要クォータがリソースの割り当て条件を満たしていないことを意味する。
【0072】
ステップ７０３において、当該リクエストにおける各リソースカテゴリ情報に対応する総需要クォータに対し上記決定ステップを実行して、各リソースカテゴリ情報に対応する総需要クォータがそれぞれリソースの割り当て条件を満たしているかを判定する。
【0073】
本実施形態では、リクエストには、例えばメモリリソース、磁気ディスク空間など複数のリソースカテゴリ情報が含まれるかもしれないため、上記実行主体は、リクエスにおける各リソースカテゴリ情報に対応する総需要クォータに対して、上記決定ステップ８００を実行することができる。
【0074】
なお、各リソースカテゴリ情報にマッチする総需要クォータが異なっている可能性があるため、各総需要クォータについて、それぞれ上記の決定ステップ８００を実行し、各総需要クォータが、それぞれリソースの割り当て条件を満たしているかを判断することが必要とされる。
【0075】
ステップ７０４において、各総需要クォータがそれぞれリソースの割り当て条件を満たしていることに応じて、当該リクエストを受け付けることを示す指示情報を生成し、図２に示される実施例にかかるリソースの割り当て方法を用いて、当該リクエストの各リソースカテゴリに対し、それぞれリソースの割り当て操作を実行する。
【0076】
本実施形態では、上記決定ステップ８００により、各リソースカテゴリ情報に対応する各総需要クォータがそれぞれリソースの割り当て条件を満たしていると判断した場合、上記実行主体は、当該リクエストを受け付けることを示す指示情報を生成することができる。ここで言う指示情報は、例えばＴｒｕｅである。即ち、サーバは、リクエストの受け付けを許可できる。次に、上記の実行主体は、図２に示す実施例にかかるリソースの割り当て方法を用いて、各当該リクエストの各リソースカテゴリに対してリソースの割り当て操作を実行する。ここで、リソースの割り当て操作は、各ターゲットサブサーバに対して行われる。
【0077】
本実施形態におけるいくつかの選択可能な実施形態では、当該リクエストにおけるいずれかのリソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たしていない場合、上記実行主体は、当該リクエストのインターセプトを示す指示情報を生成することができる。ここで言う当該リクエストのインターセプトを示す指示情報は、例えばＦａｌｓｅであるとすることができる。よりよく説明するために、表１に示すシナリオを参照する。
【表1】
【0078】
図７から分かるように、図２に対応する実施形態と比較して、本実施形態におけるリソースの割り当て方法のフロー７００は、クライアントから送信されたリクエストにおける各リソースカテゴリ情報にマッチする総需要クォータに対し、決定ステップ８００を実行し、そして、各リソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たす場合に、当該リクエストの受け付けを示す指示情報を生成し、それから、図２に示す実施例にかかるリソースの割り当て方法を用いて、リクエストされた各リソースカテゴリに対し、それぞれリソースの割り当て操作を実行する。従って、本実施例において記述するソリューションは、グローバル利用可能クォータ及びクォータ総量値を導入することにより、リクエストにおける各リソースカテゴリ情報に対応する総需要クォータを判断し、条件が満たされる場合に当該リソースの割り当て操作を実行する。それによって、サーバのリソースを合理的に利用でき、クライアントのアクセス性能を確保しながら、サーバへのリクエスト回数を低減でき、サーバによるリクエストの処理速度を高める。
【0079】
更に図９を参照すると、上述した各図に示す方法の実施形態として、本開示は、リソースの割当てる装置の実施例を提供する。当該装置実施例が図２に示す方法実施例と対応するものであり、種々の電子機器に適用可能である。
【0080】
図９に示すように、本実施例によるリソースの割り当て装置９００は、情報抽出ユニット９０１、第１の処理ユニット９０２、第２の処理ユニット９０３、バースト決定ユニット９０４及びリソースの割り当て操作処理ユニット９０５を含む。そのうち、情報抽出ユニット９０１は、クライアントから送信されたリクエストから、ターゲットサブサーバにマッチするリソースカテゴリ及び当該リソースカテゴリに対応する需要クォータを抽出するように構成されている。第１の処理ユニット９０２は、当該リクエストにおけるサブサーバグループのサブサーバ数を受信するに構成されている。第２の処理ユニット９０３は、当該リソースカテゴリにマッチするグローバル利用可能クォータ及び総バーストを判定するように構成されている。バースト決定ユニット９０４は、当該総バースト及びサブサーバ数に基づいて、ターゲットサブサーバにおける当該リソースカテゴリにマッチするバーストを決定するように構成されている。リソースの割り当て操作処理ユニット９０５は、当該需要クォータとバーストとの比較結果に基づいて、リクエストに対し、当該需要クォータに対応するリソース量でリソースを割り当てる操作を実行するように構成される。
【0081】
本実施形態において、リソースの割り当て装置９００における、情報抽出ユニット９０１、第１の処理ユニット９０２、第２の処理ユニット９０３、バースト決定ユニット９０４及びリソースの割り当て操作処理ユニット９０５の具体的な処理及びそれらの処理による技術的効果については、図２にかかる実施例におけるステップ２０１、ステップ２０２、ステップ２０３、ステップ２０４及びステップ２０５の関連説明を参照することができる。ここで説明を繰り返さない。
【0082】
本実施形態のいくつかの選択可能な実装方法では、上記リソースの割り当て操作処理ユニット９０５は、更に、需要クォータがバースト以下であることに応じて、バーストの対応するリソース量から、リクエストに対して、需要クォータに対応するリソース量を割り当てるように構成されてもよい。
【0083】
本実施形態のいくつかの選択可能な実施形態では、上記リソースの割り当て操作処理部９０５は、受信モジュール、第１のリソース割り当てモジュール（図示せず）を含んでもよい。そのうち、受信モジュールは、ターゲットサブサーバから送信された、需要クォータの割当後の残りのバーストを定期的に受信するように構成され、第１リソースの割り当てモジュールは、ターゲットサブサーバにおける残りのバーストに対応するリソース量へ補充するために、グローバル利用可能クォータに対応するリソース量の中から需要割当に対応するリソース量を割り当るように構成される。
【0084】
実施形態のいくつかの選択可能な実施形態では、上記のリソースの割り当て操作処理ユニット９０５は、第２リソースの割り当てモジュール及び記録モジュール（図示せず）を含んでもよい。第２のリソース割り当てモジュールは、需要クォータがバーストを上回ることに応じて、ターゲットサーバから、リクエストに対し、需要クォータに対応するリソース量を割当るように構成され、記録モジュールは、需要クォータをターゲットサブサーバに記録するように構成される。
【0085】
本実施形態のいくつかの選択可能な実施形態では、当該リソースの割り当て装置９００は、第１の情報受信ユニット、第１のリクエストユニット及び第３の処理ユニット（図示せず）をさらに含んでもよい。そのうち、第１情報受信ユニットは、ターゲットサブサーバから送信された、記録された需要割当を受信するように構成され、第１のリクエスト受信ユニットは、クライアントから送信された再リクエストを受信するように構成され、第３の処理ユニットは、再度のリクエストを受信したことに応じて、グローバル利用可能クォータに対応するリソース量から、記録された需要クォータに対応するリソース量を差引くように構成される。
【0086】
本実施形態のいくつかの選択可能な実装方法では、リソースの割り当て装置９００は、計時ユニット、第２の情報受信ユニット及び第４の処理ユニット（図示せず）を更に含んでもよい。そのうち、計時ユニットは、記録周期の計時を実行するように構成され、第２の情報受信ユニットは、ターゲットサブサーバから送信された、記録された需要割当を受信するように構成され、第４の処理ユニットは、記録周期が予め設定された時間の長さに達した場合に応じて、グローバル利用可能クォータに対応するリソース量から需要クォータに対応するリソース量を差し引くように構成される。
【0087】
本実施形態のいくつかの選択可能な実施形態では、リソースの割り当て装置９００は、比較ユニット及びクォータ量更新ユニット（図示せず）を更に含んでもよい。そのうち、比較ユニットは、グローバルクォータの現在残りのクォータ量がバーストを下回るかを判断するように構成され、クォータ量更新ユニットは、現在残りのクォータ量がバーストを下回ることに応じて、バーストに対応するクォータ量をグローバルクォータの現在残りのクォータ量に更新するように構成される。
【0088】
本開示の上記実施形態による装置において、リソースの割り当て操作処理ユニット９０５は、需要クォータとバーストの比較結果に基づいて、リクエストに対し、需要クォータに対応するリソース量でリソースを割り当てる操作を実行することにより、分散環境下において、リソースの割り当てクォータを合理的に割り当て、サーバのリソースを合理的に利用することができる。そして、ターゲットサブサーバに対してローカル利用可能クォータを割り当てて、リソースのクォータを合理的に配置することにより、グローバル利用可能クォータへのリクエスト回数を減らし、サーバによるリクエスト処理速度の高速化を実現することができる。
【0089】
さらに図１０を参照すると、上記した各図に示された方法の実施形態として、本開示は、リソースの割り当て装置の実施例を提供し、当該装置実施例は、図７に示された方法実施例に対応するものであり、様々な電子機器に適用可能である。
【0090】
図１０に示すように、本実施形態によるリソースの割り当て装置１０００は、第２のリクエスト受信ユニット１００１、需要クォータ決定ユニット１００２、決定ステップ実行ユニット１００３及び第５の処理ユニット１００４を含む。そのうち、第２のリクエスト受信ユニット１００１は、クライアントによって送信されるリクエストを受信するように構成される。当該リクエストにはリソースカテゴリ情報及びリソースカテゴリ情報にマッチする総需要クォータが含まれる。需要クォータ決定ユニット１００２は、リクエストにおけるリソースカテゴリ情報にマッチする総需要クォータに対し、以下の決定ステップを実行するように構成される。即ち、リクエストにおけるリソースカテゴリ情報にマッチするグローバル利用可能クォータ及び総バーストを決定し、グローバル利用可能クォータがプリセット値を上回るかを判定し、グローバル利用可能クォータがプリセット値を上回ると判断されたことに応じて、グローバル利用可能クォータと総バーストとを合計してクォータ総量とし、総需要クォータはクォータ総量の以下であるかを判定する。総需要クォータはクォータ総量以下であると判断されたことに応じて、リソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たしていると判断する。決定ステップ実行ユニット１００３は、リクエストにおける各リソースカテゴリ情報に対応する総需要クォータに対し決定ステップを実行して、各リソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たすかを判断するように構成される。第５の処理ユニット１００４は、それぞれの条件を満たしていると判定されたことに応じて、リクエストが受け付けられたこを示す指示情報を生成し、図２に示す実施例にかかる方法を用いて、リクエストされた各リソースカテゴリに対し、それぞれリソースの割り当て操作を実行するように構成される。
【0091】
本実施形態では、リソースの割り当て装置１０００において、第２のリクエスト受信ユニット１００１、需要クォータ決定ユニット１００２、決定ステップ実行ユニット１００３及び第５の処理ユニット１００４の具体的な処理及びそれによる技術的効果は図２の対応する実施形態におけるステップ７０１、ステップ７０２、ステップ７０３及びステップ７０４の関連説明をそれぞれ参照することができる。ここでは説明を省略する。
【0092】
本実施形態のいくつかの選択可能な実施形態では、上記リソースの割り当て装置１０００には、指示情報生成ユニット（図示せず）をさらに含んでもよい。そのうち、指示情報生成ユニットは、リクエストにおけるいずれかのリソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たしていないことに応じて、リクエストのインターセプトを示す指示情報を生成するように構成される。
【0093】
本開示の前述の実施例による装置においては、グローバル利用可能クォータと総バーストを導入することにより、決定ステップ実行ユニット１００３がリクエストにおける各リソースカテゴリ情報に対応する総需要クォータを判断し、条件が満たされたことに応じて、第５の処理ユニット１００４がそれに対しリソースの割り当て操作を行うことにする。それによって、サーバリソースを合理的に利用でき、クライアントのアクセス性能を確保しながら、サーバへのリクエスト回数を減らし、サーバによるリクエスト処理高速化を実現することができる。
【0094】
ここで図１１を参照する。図１１には本開示の実施例が適用される電子機器（例えば、図１のサーバ）１１００の模式的構成図を示している。図１１に示されるサーバは一例にすぎず、本開示の実施形態の機能及び使用範囲を限定するものではない。
【0095】
図１１に示すように、電子機器１１００は、処理装置（例えば中央処理装置、グラフィックプロセッサなど）１１０１を含んでもよい。電子機器１１０１は読み取り専用メモリ（ＲＯＭ）１１０２に格納されたプログラム又はストレージデバイス１１０８からランダムアクセスメモリ（ＲＡＭ）１１０３のプログラムにロードすることにより、各種の適切な動作および処理を実行可能である。ＲＡＭ１１０３には、また電子機器１１００が動作するために必要な各種プログラム及びデータも記憶されている。処理装置１１０１、ＲＯＭ１１０２及びＲＡＭ１１０３は、バス１１０４を介して互いに接続し、入出力（Ｉ／Ｏ）インターフェース１１０５もバス１１０４に接続されている。
【0096】
一般的に、以下の装置は、Ｉ／Ｏインターフェース１１０５に接続されてもよいが、例えば、タッチパネル、タッチパッド、キーボード、マウス、カメラ、マイクロフォン、加速度計、ジャイロ 等の入力装置１１０６と、液晶ディスプレイ（ＬＣＤ）、スピーカ、バイブレータ等の出力装置 １１０７と、ハードディスク等の記憶装置１１０８と、及び通信装置１１０９とを含む。通信装 置１１０９は、データを交換ように、電子機器１１００が他の装置と無線または有線通信を行うことを許可してもよい。図１１は、種々の装置を有する電子機器１１００を示すが、必ずしも全て示される装置を実施しまたは備えることを要求するものではないことが理解されるべきである。代替的に実施するかまたはより少ない装置を備えることができる。図１１に示される各ブロックは、１つの装置を示してもよいが、必要に応じて複数の装置を示してもよい。
【0097】
特に、本開示の実施例によれば、上記したフローチャートを参照して説明された処理を、コンピュータのソフトウェアプログラムとして実現することができる。例えば、本開示の実施例は、コンピュータで可読媒体にベアラされるコンピュータプログラムを含むコンピュータプログラム製品を含み、該コンピュータプログラムは、フローチャートに示される方法を実行するためのプログラムコードを含む。このような実施例において、該コンピュータプログラムは、通信装置１１０９を介してネットワークからダウンロードされてインストールされ、または記憶装置１１０８からインストールされ、またはＲＯＭ１１０２からインストールされてもよい。該コンピュータプログラムが、処理装置１１０１により実行される場合、本開示の実施例に説明された方法に限定された上記機能が実行される。
【0098】
なお、本開示の実施例に説明されたコンピュータ可読媒体は、コンピュータ可読信号媒体であってもよいが、コンピュータで可読記憶媒体であってもよいが、上記両者の任意の組み合わせであってもよい。コンピュータ可読記憶媒体は、例えば電気、磁気、光、電磁、赤外線、または半導体のシステム、装置またはデバイス、または任意の組み合わせであってもよいがこれらに限定されない。コンピュータ可読記憶媒体のより具体的な例は、一つまたは複数の導線を有する電気的接続、携帯型コンピュータ磁気ディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、消去可能なプログラマブル読み出し専用メモリ（ＣＤ－ＲＯＭ）、光記憶デバイス、磁気記憶デバイス、または上記任意の適切な組み合わせを含むがこれらに限定されない。本発明の実施例において、コンピュータ可読記憶媒体は、プログラムを含みまたは記憶する実体のある記憶媒体であってよく、該プログラムは、命令実行システム、装置またはデバイスにより使用されるかまたはそれを組み合わせて使用されてもよい。しかしながら、本開示の実施例において、コンピュータ可読信号媒体は、ベースバンドにおけるまたはキャリアの部分として伝搬するデータ信号を含んでもよく、ここでコンピュータが可読プログラムコードをベアラする。このような伝搬するデータ信号は、多種の形式を採用してもよいが、電磁信号、光信号、または上記任意の適切な組み合わせを含むがこれらに限定されない。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体以外の任意のコンピュータ可読媒体であってもよく、該コンピュータ可読媒体は、命令実行システム、装置またはデバイスにより使用されるかまたはそれを組み合わせて使用されるためのプログラムを送信、伝搬または伝送してもよい。コンピュータ可読媒体に含まれるプログラムコードは、任意の適切な媒体で伝送されてもよいが、電線、光ケーブル、ＲＦ高周波）等、または上記任意の適切な組み合わせを含むがこれに限定されない。
【0099】
上記コンピュータ可読媒体は、上記電子機器に含まれるものであってもよいが、単独で存在し該電子機器に組み込まれなくてもよい。上記コンピュータ可読媒体は、一つまたは複数のプログラムをベアラし、上記一つまたは複数のプログラムが該電子機器により実行される場合、該サーバは、クライアントから送信されたリクエストから、ターゲットサブサーバにマッチするリソースカテゴリと当該リソースカテゴリに対応するリクエストクォータを抽出し、当該リクエストを受信したサブサーバグループのサブサーバ数を決定し、当該リソースカテゴリにマッチするグローバル利用可能クォータ及び総バーストを決定し、当該総バースト及びターゲットサブサーバ数に基づいて、サブサーバにおける当該リソースカテゴリにマッチするバーストを決定し、当該需要クォータとバーストとの比較結果に基づいて、当該リクエストに対し、需要クォータに対応するリソース量のリソースの割り当て操作を実行する。
【0100】
本発明の実施例の動作を実行するためのコンピュータプログラムコードを一つまたは複数のプログラミング言語またはその組み合わせで書いてもよく、プログラミング言語はオブジェクト指向プログラミング言語であるｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のプログラミング言語を含み、「Ｃ」言語等の一般的なプロセス式のプログラミング言語をさらに含む。プログラムコードは、完全にユーザーコンピュータで実行してもよいが、部分的にユーザーコンピュータで実行してもよいが、独立したソフトウェアパッケージとして実行してもよいが、部分的にユーザーコンピュータで部分的に遠隔コンピュータで実行してもよいが、または完全に遠隔コンピュータまたはサーバで実行してもよい。遠隔コンピュータに係る場合、遠隔コンピュータは、ローカルエリアネットワーク（ＬＡＮ）やワイドエリアネットワーク（ＷＡＮ）を含む任意の種類のネットワークを介してユーザーコンピュータに接続されてもよいが、インターネットを介して外部のコンピュータに接続されてもよい（例えばインターネットサービス事業者を利用してインターネットで接続される）。
【0101】
図面におけるフローチャート及びブロック図は本願の様々な実施例によるシステム、方法及びコンピュータプログラム製品の実現可能なシステムアーキテクチャ、機能及び動作を示す。ここで、フローチャートまたはブロック図における各ブロックは、１つのモジュール、プログラムブロック、またはコードの一部を示してもよく、該モジュール、プログラムブロック、またはコードの一部は、所定の論理機能を実現するための一つまたは複数の実行可能命令を含む。なお、代替の実現において、ブロックに付された機能は、図中に付された順序とは異なる順序で発生してもよい。例えば、２つの連続して示されるブロックは、実質的に並列的に実行されてもよいが、それらが逆の順序で実行されてもよいが、係る機能に依存する場合もある。なお、ブロック図及び／またはフローチャートにおける各ブロック、及びブロック図及び／またはフローチャートにおけるブロックの組み合わせは、所定の機能または動作を実行する専用のハードウェアによるシステムで実現してもよいが、専用ハードウェアとコンピュータ命令との組み合わせで実現してもよい。
【0102】
本開示の実施例に係るユニットは、ソフトウェア又はハードウェアによって実装されることが可能である。記述されたユニットは、プロセッサに設置されてもよく、例えば、情報抽出ユニット、第１の処理ユニット、第２の処理ユニット、バースト決定ユニット、リソースの割り当て動作処理ユニットを含むプロセッサとして記述されてもよい。なお、これらのユニットの名称は、場合によって、そのユニット自体に対する限定を構成するものではなく、例えば、情報抽出ユニットは、「情報処理用のユニット」として記述されることができる。
【0103】
以上の説明は、本願の好適な実施例及び運用技術原理の説明だけである。当業者であれば、本願に係る発明の範囲は、上記技術的特徴の特定の組み合わせで形成される技術的解決手段に限定されるものではないと同時に、上記発明の構想から逸脱せず、上記技術的特徴とその均等の特徴から任意に組み合わせて形成される他の技術的解決手段も含むものである。例えば、上記特徴は、本願において開示される（ただし、特許請求の範囲に記載された）類似した機能を有する技術的特徴を相互に入れ替えて形成されたものである。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】