JP2020173778A

JP2020173778A - リソースの割り当て方法、装置、電子設備、コンピュータ可読媒体およびコンピュータプログラム

Info

Publication number: JP2020173778A
Application number: JP2019227531A
Authority: JP
Inventors: ファンユエンソン; Fangyuan Sun; ジンリンウ; Jinlin Wu
Original assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Current assignee: Beijing Baidu Netcom Science and Technology Co Ltd
Priority date: 2019-04-11
Filing date: 2019-12-17
Publication date: 2020-10-22
Anticipated expiration: 2039-12-17
Also published as: US20200328984A1; KR102324987B1; US11146502B2; CN110032447B; KR20200120476A; JP7127010B2; CN110032447A

Abstract

【課題】リソースを割り当てる方法及び装置を提供する。【解決手段】方法は、クライアントより送信されたリクエストから、ターゲットサブサーバにマッチするリソースカテゴリ及びリソースカテゴリに対応する需要クォータを抽出するステップと、リクエストを受信したサブサーバグループにおけるサブサーバ数を確定するステップと、リソースカテゴリにマッチするグローバル利用可能クォータ及び総バーストを確定するステップと、総バースト及びサブサーバ数に基づいて、ターゲットサブサーバにおけるリソースカテゴリにマッチするバーストを確定するステップと、需要クォータとバーストとの比較結果に基いて、要求に対し、需要クォータに対応するリソース量でリソースを割り当てる操作を実行するステップとを含む。【効果】グローバル利用可能クォータに対する申請回数が低減し、サーバによるリクエスト処理速度が上げられる。【選択図】図２

Description

本開示の実施例はコンピュータ技術分野に関し、具体的にリソースの割り当て方法及び装置に関する。

コンピュータ技術分野では、クォータとは、ノード上において、リソースの過剰消費を防止するために各エンティティによるリソースの消費を追跡、制御するとともに、リソースの割り当ての統計と報告を行うためのメカニズムである。当該リソースには、例えば、ディスクスペース、メモリ、ＣＰＵなどが含まれる。エンティティには、例えば、個人ユーザ、組織、プロセスなどが含まれる。

従来技術では、リソースの割り当てのクォータを判定する方式は、通常、スタンドアロンのクォータ管理とグローバルクォータ控除メカニズムとがある。スタンドアロンのクォータ管理では、ローカルで利用可能なクォータ量を継続的に差し引き、ローカルで利用可能なクォータが足りない場合、リクエストを直接拒否する。即ち、ローカルで利用可能なクォータを初期化し、そして、リクエストを受信すると、需要クォータを差し引き、その後、現在のローカルで利用可能なクォータが０より大きいかを判断する。グローバルクォータ控除メカニズムは、分散システムで利用されるメカニズムであって、リクエストを受信すると、グローバルストレージ（一般的には集中キャッシュ）のクォータを差し引き、その後、利用可能なクォータがあるかどうかを判断し、残りのクォータが足りている場合、リクエストを受け付ける一方、足りない場合は、リクエストを拒否する。

本開示の実施例はリソース割当方法と装置を提案する。

本開示の実施形態によるリソース割当方法と装置において、クライアントから送信されたリクエストから、ターゲットサブサーバにマッチするリソースカテゴリと、当該リソースカテゴリに対応する需要クォータを抽出する。次に、当該リクエストを受信したサブサーバグループにおけるサブサーバ数を確定し、そして、リソースカテゴリにマッチするグローバル利用可能クォータ及び総バーストを確定する。その後、当該需要クォータとサブサーバ数に基づいて、ターゲットサブサーバのうち、当該リソースカテゴリにマッチするバーストを確定する。最後に、当該需要クォータとバーストとの比較結果に基づいて、当該リクエストに対して、当該需要クォータに対応するリソース量でリソースを割り当てる操作を実行する。ターゲットサブサーバのバーストは、総バーストとサブサーバ数に基づいて確定されるので、これらのバーストは、ターゲットサブサーバのローカル利用可能クォータとして理解できる。その後、需要クォータとバーストの比較結果に基づいて、リクエストに対して、需要クォータに対応するリソース量で、リソースを割り当てる操作を実行することにより、分散型環境において、リソースクォータを合理的に割り当て、サーバの資源を合理的に利用する。また、ターゲットサブサーバに対してローカル利用可能クォータを割り当てる。リソースクォータを合理的に配置することにより、グローバル利用可能クォータに対する要求回数を減少させ、サーバによるリクエストの処理速度を上げることができる。

以下の図面を参照しながら非限定的な実施例を詳しく記述することによって、本開示の他の特徴、目的および利点は、より明らかになる。
本開示の一実施例が適用される例示的なシステムアーキテクチャー図である。本開示に係るリソースの割り当て方法の一実施例のフローチャートである本開示の実施例に係るリソースの割り当て方法の一適用シナリオの模式図である。本開示の実施例に係るリソースの割り当て方法の別の適用シナリオの模式図である。本開示の実施例に係るリソースの割り当て方法の更なる適用シナリオの模式図である。本開示の図２に示す実施例に係るリソース割り当て方法の一適用シナリオの模式図である。本開示に係るリソース割り当て方法の別実施例のフローチャートである。本開示の図７に示す実施例における確定ステップのフローチャートである。本開示に係る図２に示す実施例に対応するリソースの割り当て装置の一実施例の模式的構成図である。本開示に係る図７に示す実施例に対応するリソースの割り当て装置の一実施例の模式的構成図である。本開示の実施例を実施する電子設備の模式的構成図である。

以下、図面及び実施例を参照しながら本開示をより詳細に説明する。ここで記述される具体的な実施例は、関連発明を説明するためのものに過ぎず、当該発明を限定するものではないと理解すべきである。なお、説明の便宜上、図面に、かかる発明に関連する部分のみが示されている。

なお、矛盾しない限り、本開示の実施例や実施例における特徴を相互に組み合せてもよい。以下、図面及び実施例を参照しながら本開示を詳細に説明する。

図１は本開示のリソースの割り当て方法又はリソースの割り当て装置を適用できる実施例の例示的なシステムアーキテクチャー１００を示す。

図１に示されるように、システムアーキテクチャー１００は、端末装置１０１、１０２、１０３、ネットワーク１０４及びサーバ１０５を含んでもよい。ネットワーク１０４は、端末装置１０１、１０２、１０３とサーバ１０５との間に通信リンクを提供する媒体として用いられている。ネットワーク１０４は有線、無線通信リンク、又は光ファイバーケーブル等の各種接続タイプを含んでもよい。

端末装置１０１、１０２、１０３はネットワーク１０４を介してサーバ１０５とインタラクションして、メッセージなどを送受信する。端末装置１０１、１０２、１０３に、例えばショッピングアプリケーション、検索アプリケーション、インスタントメッセージングツール、メールボックスクライアント、ソーシャルソフトウェアプラットフォームソフトウェア、テキスト編集アプリケーション、ブラウザアプリケーション、読書アプリケーション等の様々な通信クライアントアプリケーションがインストールすることができる。

端末装置１０１、１０２、１０３はハードウェアでもよく、ソフトウェアでもよい。端末装置１０１、１０２、１０３がハードウェアである場合に、ディスプレイを備えるものであって、サーバにリクエストを送信可能な各種の電子機器であっても良く、スマートフォン、タブレットＰＣ、ｅ−Ｂｏｏｋリーダー、ＭＰ３プレーヤー（ＭｏｖｉｎｇＰｉｃｔｕｒｅＥｘｐｅｒｔｓＧｒｏｕｐＡｕｄｉｏＬａｙｅｒＩＩＩ、ムービング・ピクチャー・エクスパーツ・グループオーディオレイヤーＩＩＩ）、ＭＰ４プレーヤー（ＭｏｖｉｎｇＰｉｃｔｕｒｅＥｘｐｅｒｔｓＧｒｏｕｐＡｕｄｉｏＬａｙｅｒＩＶ、ムービング・ピクチャー・エクスパーツ・グループオーディオレイヤーＩＶ）、ラップトップ型コンピュータ及びデスクトップコンピュータなどを含むが、それらに限定されない。端末設備１０１、１０２、１０３がソフトウェアである場合に、前記挙げた電子機器にインストールすることができ、複数のソフトウェア又はソフトウェアモジュール（例えば、分散型サービス提供用）、或いは単一のソフトウェア又はソフトウェアモジュールとして実装することが可能である。ここでは具体的な限定をしない。

サーバ１０５は各種のサービスを提供するサーバ、例えば端末装置１０１、１０２、１０３よって送信されたリクエストを受信するバックグラウンドサーバであり得る。当該バックグランドサーバはクライアントによって送信されたリクエストに対しリソースの割り当て処理等を行うことができる。

なお、サービスエンドやクライアントはハードウェアでもよく、ソフトウェアでもよい。サービスエンドやクライアントがハードウェアである場合に、複数のサーバから成る分散型サーバクラスタとして実施されても良く、また、単一のサーバとして実施されてもよい。サービスエンドやクライアントがソフトウェアである場合に、複数のソフトウェア又はソフトウェアモジュール（例えば、分散型サービス提供用）として実施されてもよく、単一のソフトウェア又はソフトウェアモジュールとして実施されてもよい。ここでは具体的な限定をしない。

なお、本開示の実施例によるリソースの割り当て方法は、通常サーサーバ１０５により実行される。それに応じて、リソースの割り当て装置は、通常サーバ１０５に設置されている。

なお、図１で示す端末装置、ネットワーク及びサーバの数は例示的なものに過ぎない。必要に応じて、端末装置、ネットワーク及びサーバの数が任意であってもよい。

続いて、本開示に係るリソースの割り当て方法の一実施例のフロー２００を示す図２を参照する。前記リソースの割り当て方法は、ステップ２０１〜ステップ２０５を含む。

ステップ２０１において、クライアントより送信されたリクエストから、ターゲットサブサーバにマッチするリソースカテゴリ及び当該リソースカテゴリに対応する需要クォータを抽出する。

本実施例では、リソースの割り当て方法を実行する主体は（図１で示されたサーバ１０５）、クライアントより送信されたリクエストからターゲットサブサーバにマッチするリソースカテゴリ及び当該リソースカテゴリに対応する需要クォータを抽出すことができる。

ここで、リソースは、例えば、ディスクスペース、メモリ、ＣＰＵでも可能である。ここで言うリソースカテゴリは、例えばディスクスペースのようなリソースの一種を指す。当該リソースカテゴリに対応する需要クォータは、例えば、リソースカテゴリとしてディスクスペースに対応する、１のサブサーバでの需要クォータ２ＭＢである。即ち、当該リクエストには、当該サブサーバにおいてディスクスペースのリソースクォータが２ＭＢ必要です。分散型環境において、あるリクエストに対し、複数のサブサーバが当該リクエストを受信するとともに、協力して実行する必要があるかもしれない。ターゲットサブサーバは、これらのサブサーバのうち、サーバが当該リソースの割り当て方法を実行するサブサーバであると理解できる。上記の例が、本実施形態のリソースの割り当て方法をより良く説明するためのものであり、本実施形態に対する限定としてはならない。

ステップ２０２において、当該リクエストを受信したサブサーバグループにおけるサブサーバ数を確定する。

本実施例では、上記の実行主体は、当該リクエストを受信したサブサーバグループにおけるサブサーバ数を確定することができる。ここで、サブサーバグループは、分散型環境において、当該リクエストを受信した複数のサブサーバから成るサブサーバグループであると理解できる。

例として、クライアントは、ドキュメントをダウンロードするリクエストをサーバに送信する。サブサーバグループにおけるサブサーバはともに当該リクエストを受信する。例えば、当該リクエストは、第１のサブサーバのメモリリソースが２ＧＢ、第２のサーバのメモリリソースが５ＧＢ、第３のサーバのモリリソースが３ＧＢ必要である（説明するために挙げられた例に過ぎず、これらに限定しない）ことを想定する。サーバは当該サブサーバにおいて当該リクエストを受信するサブサーバ数が３であるという情報を獲得することができる。

ステップ２０３において、当該リソースカテゴリにマッチするグローバル利用可能クォータ及び総バーストを確定する。

本実施例では、上記実行主体は、当該リソースカテゴリにマッチするグローバル利用可能クォータ及び総バーストを確定することもできる。ここで、グローバル利用可能クォータ（ｑｕｏｔａ）は、当該リソースカテゴリのリソースのために指定された利用可能クォータ、即ち、通常の状況において利用可能なリソース量であると理解できる。総バースト（ｂｕｒｓｔ）は、当該リソースカテゴリのリソースに対し指定される利用可能な容量、つまりリソースの許容される超過額の最大限として理解できる。

例として、サーバはリクエスト中のメモリリソースに対し、当該リソースのグローバル利用可能クォータ（ｑｕｏｔａ）を１００ＧＢ、総バースト（ｂｕｒｓｔ）を２０ＧＢと指定することができる。

ステップ２０４において、総バーストとサブサーバ数に基づいて、ターゲットサブサーバにおける当該リソースカテゴリに対応するバーストを確定する。

本実施例では、上記実行主体は、総バースト及びサブサーバ数を取得した後、ターゲットサブサーバにおける当該リソースカテゴリに対応するバーストを確定することができる。例えば、当該リソースカテゴリの総バーストは２０（ここでは、説明のために例として挙げた数字に過ぎず、リソースの種類についての限定を構成しない）、サブサーバ数は、例えば３として確定される。

例として、サーバは、総バースト２０をサブサーバ数３で割って、ターゲットサブサーバにおけるリソースカテゴリにマッチするバーストを整数の６を得る。別の例として、サーバは総バースト２０に対し割当を行う。例えば、第１のサバサーバに対し、当該リソースカテゴリにマッチするバースト１０を割り当て、第２のサブサーバに対し、当該リソースカテゴリにマッチするバースト５を割り当て、第３のサブサーバに対し、当該リソースカテゴリにマッチするバースト５を割り当てる。ここの第１のサブサーバがターゲットサブサーバであるとすると、当該リソースカテゴリにマッチするバーストは１０である。

ステップ２０５において、当該需要クォータとバーストの比較結果に基づいて、当該リクエストに対し、当該需要クォータに対応するリソース量でリソースを割り当てる操作を実行する。

本実施例では、上記実行主体は、当該ターゲットサブサーバにおける当該リソースカテゴリにマッチするバーストを取得した後、当該リクエストにおける当該リソースカテゴリに対応する需要クォータを当該バーストと比較し、比較結果を得る。当該比較結果に応じて、当該リクエストに対し、当該需要クォータに対応するリソース量でリソースを割り当てる操作を実行する。これにより、グローバル利用可能クォータとサブサーバのローカル利用可能クォータとを組み合わせて使用することで、グローバル利用可能クォータへのリクエスト回数を減少させる。

例として、本実施例のいくつかの選択可能な実施形態において、当該需要クォータが当該バースト以下であることに応じて、上記実行主体は、バーストに対応するリソース量から、当該リクエストに対して、当該需要クォータに対応するリソース量を割り当てる。例えば、当該ターゲットサブサーバについて、バーストは６であり、当該リソースカテゴリに対応する需要クォータは３である場合、上記実行主体は、ターゲットサブサーバにおける当該バーストから、直接当該需要クォータ３を割り当てることができる。即ち、ターゲットサブサーバは、当該リソースクォータリクエストに応答するために、サーバにおけるグローバル利用可能クォータを請求することなく、ローカル利用可能クォータから、リソースを割り当てることができる。それによって、リクエストに素早く応答し、プロセッサの要求処理速度を速めることができる。

バーストに対応するリソース量から、当該リクエストに対して、当該需要クォータに対応するリソース量を割り当てた後、本実施例のいくつかの選択なの宇な実施形態において、上記実行主体は、ターゲットサブサーバによって送信された、当該リクエストを割り当てた後の残りのバーストを定期的受信することもできる。その後、ターゲットサブサーバにおける残りのバーストに対応するリソース量へ補充するために、サーバは、グローバル利用可能クォータに対応するリソース量から、当該需要クォータに対応するリソース量を割り当てることができる。例えば、ターゲットサブサーバにおける、リソースカテゴリのリソースに対応する最初のバーストは６であり、即ち、ローカル利用可能クォータは６である。一方で、リクエストにおける、当該リソースカテゴリに対応する需要クォータは３である。ターゲットサブサーバのローカル利用可能クォータから３を差し引いた後、残りのバーストは６−３＝３である。ターゲットサブサーバは、定期的に残りのバーストをサーバに報告する。ターゲットサブサーバのバーストを依然として初期値６にするように、ターゲットサブサーバへ補充するために、サーバは、グローバル利用可能なクォータから、需要クォータ３に対応するリソース量を割り当てることができる。

図３で示されている応用シナリオを例とすると、三つのサブサーバのローカルクォータはいずれも６（バーストは３０３）であり、初期段階において、リクエストを受信していないため、ローカルカウンタ３０４は０である。この場合、グローバル利用可能クォータ３０２が１００であると仮定すると、現在利用可能クォータ総量３０１は１００＋３×６＝１１８となる。

次に、周期内にリクエストを一回受信すると、当該リソースについて、三つのサブサーバはそれぞれ対応する需要クォータが３、２、４である。この場合、まず、当該需要クォータをローカルカウントする。即ち、三つのサブサーバについて、ローカルカウント３０４はそれぞれ３、２、４である。

需要クォータ３、２と４はいずれもバーストの６より小さいので、ローカル利用可能クォータ（バースト３０３）から当該需要クォータに対応するリソースクォータを直接に差し引いてもよい。差し引いた後、三つのサブサーバのローカル利用可能クォータは、それぞれ６-３＝３、６-２＝４、６-４＝２となる。

その後、５ｓでローカルカウントをサーバに報告する。サーバはグローバル利用可能クォータ１００からクォータ３、２、４を差し引いて３のサブサーバに補充する。即ち、初期バーストの６になるように、サブサーバのバースト３０３へ補充する。この場合に、グローバル利用可能クォータの残り量は１００-３-２-４＝９１となる。

別の例として、本実施形態いくつかの選択可能な実施形態では、当該需要クォータがバーストを上回ることに応じて、上記実行主体は、当該ターゲットサブサーバから、当該リクエストに対して、当該需要クォータに対応するリソース量を割り当てることができる。その後、サーバは、当該需要クォータをターゲットサブサーバに記録する。具体的には、要求される需要クォータがローカル利用可能クォータ（バースト）より大きい場合、クライアントのユーザの使用体験を保証するために、サーバは、まずターゲットサブサーバから、当該需要クォータに対応するリソース量を割り当てることができる。その後、サーバは、当該リクエストにおける当該リソースの需要クォータをターゲットサブサーバに記録し、すなわち、ローカルカウントに記録することができる。

次に、例として、ターゲットサブサーバは、記録されたローカルカウンタをサーバにアップロードすることができる。サーバは、当該記録された需要クォータを受信する。その後、サーバは、クライアントから送信された再度リクエストを受信すると、グローバル利用可能クォータに対応するリソース量から、当該記録の需要クォータに対応するリソース量を差し引くことができる。別の例として、サーバは、需要クォータをローカルに記録した後、記録周期を計時する。その後、サーバは、ターゲットサブサーバから送信された、記録された需要クォータを受信した後、記録期間が予め設定された時間に達したかを判断する。当該記録期間が予め設定された時間に達したことに応じて、サーバは、グローバル利用可能クォータに対応するリソース量から需要クォータに対応するリソース量を差し引くことができる。

図４で示されている応用シナリオにおいて、三つのサブサーバのローカル利用可能クォータはいずれも６（バースト４０３）である。初期段階において、第１のサブサーバのローカルカウンタ４０４は５（前回のリクエストで第１のサブサーバを使用したリソースクォータ量は５）である。第２及び第３のサブサーバのローカルカウンタはいずれも０である。グローバル利用可能クォータ４０２が１００であると仮定すると、現在利用可能なクォータ総量４０１は１００＋３×６＝１１８となる。

次に、受信した要求のうち、第１のサブサーバの需要クォータは１５であり、他の二つのサブサーバの需要クォータは０である。この場合、第１のサブサーバは、ローカルカウント５をグローバル利用可能クォータ４０２に報告して差し引く。すると、サーバでは、当該リソースに対応するグローバル利用可能クォータの残りは１００-５＝９５となる。

その後、サーバは当該リクエストの需要クォータ１５をターゲットサブサーバのローカルカウンタに記録する。即ち、三つのサブサーバのローカルカウント３０４は、それぞれ１５、０と０である。なお、クライアントのユーザの権益に影響を及ぼさないように、需要クォータ１５に対しローカルカウントをすると同時に、ターゲットサブサーバから、ユーザに使用される当該リソースクォータを先に差し引く。

その後、再度リクエストを受信すると、サーバはグローバル利用可能クォータ４０２から前回のローカルカウント１５を差し引くことができる。その時点で、グローバル利用可能クォータの残量は９５-１５＝８０となる。次に、再度リクエストされた需要クォータ３をローカルカウントに記録し、対応するリソース割り当てポリシーを用い、リソース割り当てを行う。

本実施形態による上記二つの実施形態として、第１の実施形態では、ローカル利用可能クォータ値を継続的に更新し、ローカル利用可能クォータを優先的に選択して、グローバル利用可能クォータへのリクエスト量を減らし、リクエストを処理するサーバのパフォーマンスを確保する。第２の実施形態では、ローカル利用可能クォータが需要クォータに満たさない場合でも、ユーザのリクエストに対する需要クォータ提供に影響しないとともに、グローバル利用なクォータを適時に同期させることができ、サーバ処理要求の柔軟性を向上させる。

本実施形態のいくつかの選択可能な実施形態において、ソース割当量の過剰浪費を避けるために、上記実行主体は、グローバル利用可能クォータの現在の残量がバーストを下回るかを判断することができる。下回ると判断したことに応じて、当該バーストに対応するクォータをグローバル利用可能クォータの現在の残量に更新する。

具体的には、現在の大多数のリソースの割り当て方法の最後の残量が無駄になってしまう。そこで、ユーザの利用可能なリソースが合理的に利用されるとともに、過剰浪費が発生しないように、当該選択可能な実施形態において、上記実行主体は、各サブサーバにおける当該リソースの許容の超過額であるバーストを総バースト／サブサーバ数に設定することができる。

例えば、図５に示されるアプリケーションシナリオでは、各サブサーバのバースト５０３は６であると想定すると、データ同期が数回請求された後、グローバル利用可能クォータ５０２は１０となる。この時点で、利用可能なクォータの総量５０１は１０+３×６=２８となる。

今回のリクエストでは、三つのサブサーバの対応する需要クォータ（ローカルカウント５０４）は、それぞれ３、１、２である。次に、５s後にローカルカウントをグローバルにアップロードし、当該需要クォータに対応するクォータ値をグローバル利用可能クォータ５０２から差し引き、三つのサブサーバのクォータ値へ補充した後、グローバル利用可能クォータ５０２の残りのクォータは１０-３-１-２＝４となる。

この時、グローバル利用可能クォータ５０２の残りのクォータは４であり、三つのサブサーバのバースト６より小さいため、上記実行主体は、サブサーバのバースト５０３を４に更新することができる。このように、最終にリクエストされたリソースの需要クォータの超過額の限度は４×３＝１２である。これにより、割当リソースを合理的に利用し、リソースクォータを過度に無駄しないようにするとともに、サーバのリクエスト処理性能にも影響しないようにする。

続いて図６を参照する。図６は、本開示の図２の実施形態にかかるリソースの割り当て方法の適用シナリオの概略図である。図６の適用シナリオでは、サーバ６０１は、クライアント６０２によって送信されたリクエスト６０３（ドキュメント）の中から、ターゲットサブサーバ６０４にマッチするリソースカテゴリ６０５（メモリリソース）と、当該リソースカテゴリ６０５に対応する需要クォータ６０６（５ＧＢ）を抽出する。

その後、サーバ６０１は、リクエストを受信したサブサーバグループのサブサーバ数６０７が３であり、メモリリソースにマッチするグローバル利用可能クォータ６０８が１００ＧＢであり、総バースト６０９は２０ＧＢであると確定する。サーバ６０１は、２０ＧＢを三つのサブサーバに均等に分ける。よって、ターゲットサブサーバのバースト６１０は６ＧＢである。

それから、サーバ６０１は、需要クォータ５ＧＢをバースト６ＧＢと比較し、比較結果に基づいてリソース割り当て６１１を実行する。例えば、サーバ６０１は、当該需要クォータ５ＧＢが当該バーストの６ＧＢより小さいと判断すると、クライアントの当該リクエストに対し、当該リクエストのメモリリソース需要クォータ５ＧＢに対応するリソース量を、当該ターゲットサブサーバのローカル利用可能クォータ（バースト６１０）に対応するリソース量から割り当てることができる。

現在、従来技術の一つとして、通常、すべてのリクエストに対し、グローバルクォータから差し引き、グローバルクォータへのリクエスト量を増加させ、その結果として、サーバの処理速度が遅くなってしまう。これに対し、本開示の上記実施形態による方法は、ターゲットサブサーバのバーストが総バースト及びサブサーバ数に基づいて確定されるもので、これらのバーストは、ターゲットサブサーバのローカル利用可能クォータとして理解できる。そして、需要クォータとバーストの比較結果に基づいて、リクエストに対して需要クォータに対応するリソース量でリソースを割り当てる操作を行う。分散型環境において、リソースクォータを合理的に割当、サーバのリソースを合理的に利用することができる。また、ターゲットサブサーバに対してローカル利用可能クォータを割り当てるとともに、リソースクォータを合理的に配置することにより、グローバル利用可能クォータへのリクエスト回数を減らし、サーバのリクエスト処理の高速化を実現する。

更に図７を参照する、リソースの割り当て方法の更なる実施例のプロセス７００が示されている。サーバに適用される当該リソースの割り当て方法のプロセス７００は、次のステップを含む。

ステップ７０１において、クライアントが送信されたリクエストを受信する。

本実施形態では、リソースの割り当て方法を実行する主体（例えば図１に示すサーバ１０５）は、クライアントから送信されたリクエストを受信することができる。当該リクエストには、リソースカテゴリ情報及び当該リソースカテゴリ情報にマッチする総需要クォータを含む。ここで言うリソースカテゴリ情報にはメモリが含まれてもよい。総需要クォータは、当該要求を受信するサーバ数を問わず、特定のリソースがリクエストされるリソースクォータを指す。

ステップ７０２において、リクエスト中のリソースカテゴリ情報にマッチングする総需要クォータに対して確定ステップを実行する。

本実施形態では、上記実行主体は、リクエストにおけるリソースカテゴリ情報にマッチングする総需要クォータに対して確定ステップ８００を実行する。具体的には、図８に示すように、確定ステップ８００は下記のステップを含んでもよい。

ステップ８０１において、リクエストにおけるリソースカテゴリ情報にマッチするグローバル利用可能クォータ及び総バーストを確定する。

本実施形態では、上記実行主体は、クライアントから送信されたリクエストを受信すると、当該リクエストにおけるリソースカテゴリ情報にマッチングするグローバル利用可能クォータ及び総バーストを確定することができる。

なお、各リソース、例えばメモリリソースについて、サーバは、当該リソースのグローバルリソースクォータ及び許容の超過額限度を予め割り当てておく。ここで言うグローバルリソースクォータは、グローバル利用可能クォータとして理解できる。また、許容の超過額限度は総バーストとして理解できる。

ステップ８０２において、グローバル利用可能クォータがプリセット値を上回るかを判定する。

本実施形態では、上述した実行主体は当該リソースカテゴリ情報にマッチするグローバル利用可能クォータ及び総バーストを確定した後、当該グローバル利用可能クォータをプリセット値と比較し、グローバル利用可能クォータがプリセット値を上回るかを判定する。例として、ここのプリセット値を０とする場合、サーバは当該グローバル利用可能クォータが０より大きいかどうかを判断できる。

ステップ８０３において、グローバル利用可能クォータがプリセット値を上回ることに応じて、当該グローバル利用可能クォータと総バーストを合計して、総クォータを得る。

本実施形態では、上記実行主体は、グローバル利用可能クォータがプリセット値より大きいと判定した後、グローバル利用可能クォータと総バーストを合計して総クォータを得ることができる。例えば、当該リクエストは、メモリリソースのクォータが８０ＧＢ、メモリリソースのグローバル利用可能クォータが１００ＧＢ、総バーストが２０ＧＢ必要であると仮定すると、サーバがメモリリソースのグローバル利用可能クォータ１００ＧＢと総バースト２０ＧＢを合計して、メモリリソースの総クォータの１２０ＧＢを得る。

ステップ８０４において、当該総需要クォータが当該総クォータ以下であるかを確定する。

本実施形態では、上記実行主体は、当該カテゴリのリソースの総クォータを取得した後、当該リソースの需要クォータを総クォータと比較して、当該需要クォータが総クォータ以下であるかを判定することができる。

例えばメモリリソースの総クォータが１２０ＧＢ、需要クォータが８０ＧＢであるとすると、サーバは需要クォータの８０ＧＢを総クォータの１２０ＧＢと比較し、その結果として、需要クォータが総クォータより小さいと判明できる。

ステップ８０５において、需要クォータが総クォータ以下である判定に応じて、当該リソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たしていると判定できる。

本実施形態では、需要クォータが総クォータ以下である場合に、上記実行主体は、当該リソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たしていると判定できる。

即ち、グローバル利用可能クォータがプリセット値を上回り、且つ、需要クォータが総クォータ以下である場合こそ、当該リソースカテゴリ情報に対応する需要クォータがリソースの割り当て条件を満たす。その他の場合は、リソースカテゴリ情報に対応する需要クォータがリソースの割り当て条件を満たしていないことを意味する。

ステップ７０３において、当該リクエストにおける各リソースカテゴリ情報に対応する総需要クォータに対し上記確定ステップを実行して、各リソースカテゴリ情報に対応する総需要クォータがそれぞれリソースの割り当て条件を満たしているかを判定する。

本実施形態では、リクエストには、例えばメモリリソース、磁気ディスク空間など複数のリソースカテゴリ情報が含まれるかもしれないため、上記実行主体は、リクエスにおける各リソースカテゴリ情報に対応する総需要クォータに対して、上記確定ステップ８００を実行することができる。

なお、各リソースカテゴリ情報にマッチする総需要クォータが異なっている可能性があるため、各総需要クォータについて、それぞれ上記の確定ステップ８００を実行し、各総需要クォータが、それぞれリソースの割り当て条件を満たしているかを判断することが必要とされる。

ステップ７０４において、各総需要クォータがそれぞれリソースの割り当て条件を満たしていることに応じて、当該リクエストを受け付けることを示す指示情報を生成し、図２に示される実施例にかかるリソースの割り当て方法を用いて、当該リクエストの各リソースカテゴリに対し、それぞれリソースの割り当て操作を実行する。

本実施形態では、上記確定ステップ８００により、各リソースカテゴリ情報に対応する各総需要クォータがそれぞれリソースの割り当て条件を満たしていると判断した場合、上記実行主体は、当該リクエストを受け付けることを示す指示情報を生成することができる。ここで言う指示情報は、例えばＴｒｕｅである。即ち、サーバは、リクエストの受け付けを許可できる。次に、上記の実行主体は、図２に示す実施例にかかるリソースの割り当て方法を用いて、各当該要求の各リソースカテゴリに対してリソースの割り当て操作を実行する。ここで、リソースの割り当て操作は、各ターゲットサブサーバに対して行われる。

本実施形態におけるいくつかの選択可能な実施形態では、当該リクエストにおけるいずれかのリソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たしていない場合、上記実行主体は、当該リクエストのインターセプトを示す指示情報を生成することができる。ここで言う当該リクエストのインターセプトを示す指示情報は、例えばＦａｌｓｅであるとすることができる。よりよく説明するために、表１に示すシナリオを参照する。

図７から分かるように、図２に対応する実施形態と比較して、本実施形態におけるリソースの割り当て方法のフロー７００は、クライアントから送信されたリクエストにおける各リソースカテゴリ情報にマッチする総需要クォータに対し、確定ステップ８００を実行し、そして、各リソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たす場合に、当該リクエストの受け付けを示す指示情報を生成し、それから、図２に示す実施例にかかるリソースの割り当て方法を用いて、リクエストされた各リソースカテゴリに対し、それぞれリソースの割り当て操作を実行する。従って、本実施例において記述するソリューションは、グローバル利用可能クォータ及び総クォータ値を導入することにより、リクエストにおける各リソースカテゴリ情報に対応する総需要クォータを判断し、条件が満たされる場合に当該リソースの割り当て操作を実行する。それによって、サーバのリソースを合理的に利用でき、クライアントのアクセス性能を確保しながら、サーバへのリクエスト回数を低減でき、サーバによるリクエストの処理速度を高める。

更に図９を参照すると、上述した各図に示す方法の実施形態として、本開示は、リソースの割当てる装置の実施例を提供する。当該装置実施例が図２に示す方法実施例と対応するものであり、種々の電子機器に適用可能である。

図９に示すように、本実施例によるリソースの割り当て装置９００は、情報抽出ユニット９０１、第１の処理ユニット９０２、第２の処理ユニット９０３、バースト確定ユニット９０４及びリソースの割り当て操作処理ユニット９０５を含む。そのうち、情報抽出ユニット９０１は、クライアントから送信されたリクエストから、ターゲットサブサーバにマッチするリソースカテゴリ及び当該リソースカテゴリに対応する需要クォータを抽出するように構成されている。第１処理ユニット９０２は、当該リクエストにおけるサブサーバグループのサブサーバ数を受信するに構成されている。第２処理ユニット９０３は、当該リソースカテゴリにマッチするグローバル利用可能クォータ及び総バーストを判定するように構成されている。バースト確定ユニット９０４は、当該総バースト及びサブサーバ数に基づいて、ターゲットサブサーバにおける当該リソースカテゴリにマッチするバーストを確定するように構成されている。リソースの割り当て操作処理ユニット９０５は、当該需要クォータとバーストとの比較結果に基づいて、リクエストに対し、当該需要クォータに対応するリソース量でリソースを割り当てる操作を実行するように構成される。

本実施形態において、リソースの割り当て装置９００における、情報抽出ユニット９０１、第１処理ユニット９０２、第２処理ユニット９０３、バースト確定ユニット９０４及びリソースの割り当て操作処理ユニット９０５の具体的な処理及びそれらの処理による技術的効果については、図２にかかる実施例におけるステップ２０１、ステップ２０２、ステップ２０３、ステップ２０４及びステップ２０５の関連説明を参照することができる。ここで説明を繰り返さない。

本実施形態のいくつかの選択可能な実装方法では、上記リソースの割り当て操作処理ユニット９０５は、更に、需要クォータがバースト以下であることに応じて、バーストの対応するリソース量から、リクエストに対して、需要クォータに対応するリソース量を割り当てるように構成されてもよい。

本実施形態のいくつかの選択可能な実施形態では、上記リソースの割り当て操作処理部９０５は、受信モジュール、第１のリソース割り当てモジュール（図示せず）を含んでもよい。そのうち、受信モジュールは、ターゲットサブサーバから送信された、需要クォータの割当後の残りのバーストを定期的に受信するように構成され、第１リソースの割り当てモジュールは、ターゲットサブサーバにおける残りのバーストに対応するリソース量へ補充するために、グローバル利用可能クォータに対応するリソース量の中から需要割当に対応するリソース量を割り当るように構成される。

実施形態のいくつかの選択可能な実施形態では、上記のリソースの割り当て操作処理ユニット９０５は、第２リソースの割り当てモジュール及び記録モジュール（図示せず）を含んでもよい。第２のリソース割り当てモジュールは、需要クォータがバーストを上回ることに応じて、ターゲットサーバから、リクエストに対し、需要クォータに対応するリソース量を割当るように構成され、記録モジュールは、需要クォータをターゲットサブサーバに記録するように構成される。

本実施形態のいくつかの選択可能な実施形態では、当該リソースの割り当て装置９００は、第１の情報受信ユニット、第１の要求ユニット及び第３の処理ユニット（図示せず）をさらに含んでもよい。そのうち、第１情報受信ユニットは、ターゲットサブサーバから送信された、記録された需要割当を受信するように構成され、第１の要求受信ユニットは、クライアントから送信された再要求を受信するように構成され、第３の処理ユニットは、再度のリクエストを受信したことに応じて、グローバル利用可能クォータに対応するリソース量から、記録された需要クォータに対応するリソース量を差引くように構成される。

本実施形態のいくつかの選択可能な実装方法では、リソースの割り当て装置９００は、計時ユニット、第２の情報受信ユニット及び第４の処理ユニット（図示せず）を更に含んでもよい。そのうち、計時ユニットは、記録周期の計時を実行するように構成され、第２の情報受信ユニットは、ターゲットサブサーバから送信された、記録された需要割当を受信するように構成され、第４の処理ユニットは、記録周期が予め設定された時間の長さに達した場合に応じて、グローバル利用可能クォータに対応するリソース量から需要クォータに対応するリソース量を差し引くように構成される。

本実施形態のいくつかの選択可能な実施形態では、リソースの割り当て装置９００は、比較ユニット及びクォータ量更新ユニット（図示せず）を更に含んでもよい。そのうち、比較ユニットは、グローバルクォータの現在残りのクォータ量がバーストを下回るかを判断するように構成され、クォータ量更新ユニットは、現在残りのクォータ量がバーストを下回ることに応じて、バーストに対応するクォータ量をグローバルクォータの現在残りのクォータ量に更新するように構成される。

本開示の上記実施形態による装置において、リソースの割り当て操作処理ユニット９０５は、需要クォータとバーストの比較結果に基づいて、リクエストに対し、需要クォータに対応するリソース量でリソースを割り当てる操作を実行することにより、分散環境下において、リソースの割り当てクォータを合理的に割り当て、サーバのリソースを合理的に利用することができる。そして、ターゲットサブサーバに対してローカル利用可能クォータを割り当てて、リソースのクォータを合理的に配置することにより、グローバル利用可能クォータへのリクエスト回数を減らし、サーバによるリクエスト処理速度の高速化を実現することができる。

さらに図１０を参照すると、上記した各図に示された方法の実施形態として、本開示は、リソースの割り当て装置の実施例を提供し、当該装置実施例は、図７に示された方法実施例に対応するものであり、様々な電子機器に適用可能である。

図１０に示すように、本実施形態によるリソースの割り当て装置１０００は、第２の要求受信ユニット１００１、需要クォータ確定ユニット１００２、確定ステップ実行ユニット１００３及び第５処理ユニット１００４を含む。そのうち、第２要求受信ユニット１００１は、クライアントによって送信されるリクエストを受信するように構成される。当該リクエストにはリソースカテゴリ情報及びリソースカテゴリ情報にマッチする総需要クォータが含まれる。需要クォータ確定ユニット１００２は、リクエストにおけるリソースカテゴリ情報にマッチする総需要クォータに対し、以下の確定ステップを実行するように構成される。即ち、リクエストにおけるリソースカテゴリ情報にマッチするグローバル利用可能クォータ及び総バーストを確定し、グローバル利用可能クォータがプリセット値を上回るかを判定し、グローバル利用可能クォータがプリセット値を上回ると判断されたことに応じて、グローバル利用可能クォータと総バーストとを合計して総クォータとし、総需要クォータは総クォータの以下であるかを判定する。総需要クォータは総クォータ以下であると判断されたことに応じて、リソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たしていると判断する。確定ステップ実行ユニット１００３は、リクエストにおける各リソースカテゴリ情報に対応する総需要クォータに対し確定ステップを実行して、各リソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たすかを判断するように構成される。第５処理ユニット１００４は、それぞれの条件を満たしていると判定されたことに応じて、リクエストが受け付けられたこを示す指示情報を生成し、図２に示す実施例にかかる方法を用いて、リクエストされた各リソースカテゴリに対し、それぞれリソースの割り当て操作を実行するように構成される。

本実施形態では、リソースの割り当て装置１０００において、第２要求受信ユニット１００１、需要クォータユニット１００２、確定ステップ実行ユニット１００３及び第５処理ユニット１００４の具体的な処理及びそれによる技術的効果は図２の対応する実施形態におけるステップ７０１、ステップ７０２、ステップ７０３及びステップ７０４の関連説明をそれぞれ参照することができる。ここでは説明を省略する。

本実施形態のいくつかの選択可能な実施形態では、上記リソースの割り当て装置１０００には、指示情報生成ユニット（図示せず）をさらに含んでもよい。そのうち、指示情報生成ユニットは、リクエストにおけるいずれかのリソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たしていないことに応じて、リクエストのインターセプトを示す指示情報を生成するように構成される。

本開示の前述の実施例による装置においては、グローバル利用可能クォータと総バーストを導入することにより、確定ステップ実行ユニット１００３がリクエストにおける各リソースカテゴリ情報に対応する総需要クォータを判断し、条件が満たされたことに応じて、第５処理ユニット１００４がそれに対しリソースの割り当て操作を行うことにする。それによって、サーバリソースを合理的に利用でき、クライアントのアクセス性能を確保しながら、サーバへのリクエスト回数を減らし、サーバによるリクエスト処理高速化を実現することができる。

ここで図１１を参照する。図１１には本開示の実施例が適用される電子機器（例えば、図１のサーバ）１１００の模式的構成図を示している。図１１に示されるサーバは一例にすぎず、本開示の実施形態の機能及び使用範囲を限定するものではない。

図１１に示すように、電子機器１１００は、処理装置（例えば中央処理装置、グラフィックプロセッサなど）１１０１を含んでもよい。電子機器１１０１は読み取り専用メモリ（ＲＯＭ）１１０２に格納されたプログラム又はストレージデバイス１１０８からランダムアクセスメモリ（ＲＡＭ）１１０３のプログラムにロードすることにより、各種の適切な動作および処理を実行可能である。ＲＡＭ１１０３には、また電子機器１１００が動作するために必要な各種プログラム及びデータも記憶されている。処理装置１１０１、ＲＯＭ１１０２及びＲＡＭ１１０３は、バス１１０４を介して互いに接続し、入出力（Ｉ／Ｏ）インターフェース１１０５もバス１１０４に接続されている。

一般的に、以下の装置は、Ｉ/Ｏインターフェース１１０５に接続されてもよいが、例えば、タッチパネル、タッチパッド、キーボード、マウス、カメラ、マイクロフォン、加速度計、ジャイロ等の入力装置１１０６と、液晶ディスプレイ（ＬＣＤ）、スピーカ、バイブレータ等の出力装置１１０７と、ハードディスク等の記憶装置１１０８と、及び通信装置１１０９とを含む。通信装置１１０９は、データを交換ように、電子機器１１００が他の装置と無線または有線通信を行うことを許可してもよい。図１１は、種々の装置を有する電子機器１１００を示すが、必ずしも全て示される装置を実施しまたは備えることを要求するものではないことが理解されるべきである。代替的に実施するかまたはより少ない装置を備えることができる。図１１に示される各ブロックは、１つの装置を示してもよいが、必要に応じて複数の装置を示してもよい。

特に、本開示の実施例によれば、上記したフローチャートを参照して説明された処理を、コンピュータのソフトウェアプログラムとして実現することができる。例えば、本開示の実施例は、コンピュータで可読媒体にベアラされるコンピュータプログラムを含むコンピュータプログラム製品を含み、該コンピュータプログラムは、フローチャートに示される方法を実行するためのプログラムコードを含む。このような実施例において、該コンピュータプログラムは、通信装置１１０９を介してネットワークからダウンロードされてインストールされ、または記憶装置１１０８からインストールされ、またはＲＯＭ１１０２からインストールされてもよい。該コンピュータプログラムが、処理装置１１０１により実行される場合、本開示の実施例に説明された方法に限定された上記機能が実行される。

なお、本開示の実施例に説明されたコンピュータ可読媒体は、コンピュータ可読信号媒体であってもよいが、コンピュータで可読記憶媒体であってもよいが、上記両者の任意の組み合わせであってもよい。コンピュータ可読記憶媒体は、例えば電気、磁気、光、電磁、赤外線、または半導体のシステム、装置またはデバイス、または任意の組み合わせであってもよいがこれらに限定されない。コンピュータ可読記憶媒体のより具体的な例は、一つまたは複数の導線を有する電気的接続、携帯型コンピュータ磁気ディスク、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、消去可能なプログラマブル読み出し専用メモリ（ＣＤ-ＲＯＭ）、光記憶デバイス、磁気記憶デバイス、または上記任意の適切な組み合わせを含むがこれらに限定されない。本発明の実施例において、コンピュータ可読記憶媒体は、プログラムを含みまたは記憶する実体のある記憶媒体であってよく、該プログラムは、命令実行システム、装置またはデバイスにより使用されるかまたはそれを組み合わせて使用されてもよい。しかしながら、本開示の実施例において、コンピュータ可読信号媒体は、ベースバンドにおけるまたはキャリアの部分として伝搬するデータ信号を含んでもよく、ここでコンピュータが可読プログラムコードをベアラする。このような伝搬するデータ信号は、多種の形式を採用してもよいが、電磁信号、光信号、または上記任意の適切な組み合わせを含むがこれらに限定されない。コンピュータ可読信号媒体は、コンピュータ可読記憶媒体以外の任意のコンピュータ可読媒体であってもよく、該コンピュータ可読媒体は、命令実行システム、装置またはデバイスにより使用されるかまたはそれを組み合わせて使用されるためのプログラムを送信、伝搬または伝送してもよい。コンピュータ可読媒体に含まれるプログラムコードは、任意の適切な媒体で伝送されてもよいが、電線、光ケーブル、ＲＦ高周波）等、または上記任意の適切な組み合わせを含むがこれに限定されない。

上記コンピュータ可読媒体は、上記電子機器に含まれるものであってもよいが、単独で存在し該電子機器に組み込まれなくてもよい。上記コンピュータ可読媒体は、一つまたは複数のプログラムをベアラし、上記一つまたは複数のプログラムが該電子機器により実行される場合、該サーバは、クライアントから送信されたリクエストから、ターゲットサブサーバにマッチするリソースカテゴリと当該リソースカテゴリに対応する要求クォータを抽出し、当該リクエストを受信したサブサーバグループのサブサーバ数を確定し、当該リソースカテゴリにマッチするグローバル利用可能クォータ及び総バーストを確定し、当該総バースト及びターゲットサブサーバ数に基づいて、サブサーバにおける当該リソースカテゴリにマッチするバーストを確定し、当該需要クォータとバーストとの比較結果に基づいて、当該リクエストに対し、需要クォータに対応するリソース量のリソースの割り当て操作を実行する。

本発明の実施例の動作を実行するためのコンピュータプログラムコードを一つまたは複数のプログラミング言語またはその組み合わせで書いてもよく、プログラミング言語はオブジェクト指向プログラミング言語であるｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のプログラミング言語を含み、「Ｃ」言語等の一般的なプロセス式のプログラミング言語をさらに含む。プログラムコードは、完全にユーザーコンピュータで実行してもよいが、部分的にユーザーコンピュータで実行してもよいが、独立したソフトウェアパッケージとして実行してもよいが、部分的にユーザーコンピュータで部分的に遠隔コンピュータで実行してもよいが、または完全に遠隔コンピュータまたはサーバで実行してもよい。遠隔コンピュータに係る場合、遠隔コンピュータは、ローカルエリアネットワーク（ＬＡＮ）やワイドエリアネットワーク（ＷＡＮ）を含む任意の種類のネットワークを介してユーザコンピュータに接続されてもよいが、インターネットを介して外部のコンピュータに接続されてもよい（例えばインターネットサービス事業者を利用してインターネットで接続される）。

図面におけるフローチャート及びブロック図は本願の様々な実施例によるシステム、方法及びコンピュータプログラム製品の実現可能なシステムアーキテクチャ、機能及び動作を示す。ここで、フローチャートまたはブロック図における各ブロックは、１つのモジュール、プログラムブロック、またはコードの一部を示してもよく、該モジュール、プログラムブロック、またはコードの一部は、所定の論理機能を実現するための一つまたは複数の実行可能命令を含む。なお、代替の実現において、ブロックに付された機能は、図中に付された順序とは異なる順序で発生してもよい。例えば、２つの連続して示されるブロックは、実質的に並列的に実行されてもよいが、それらが逆の順序で実行されてもよいが、係る機能に依存する場合もある。なお、ブロック図及び/またはフローチャートにおける各ブロック、及びブロック図及び/またはフローチャートにおけるブロックの組み合わせは、所定の機能または動作を実行する専用のハードウェアによるシステムで実現してもよいが、専用ハードウェアとコンピュータ命令との組み合わせで実現してもよい。

本開示の実施例に係るユニットは、ソフトウェア又はハードウェアによって実装されることが可能である。記述されたユニットは、プロセッサに設置されてもよく、例えば、情報抽出ユニット、第１の処理ユニット、第２の処理ユニット、バースト確定ユニット、リソースの割り当て動作処理ユニットを含むプロセッサとして記述されてもよい。なお、これらのユニットの名称は、場合によって、そのユニット自体に対する限定を構成するものではなく、例えば、情報抽出ユニットは、「情報処理用のユニット」として記述されることができる。

以上の説明は、本願の好適な実施例及び運用技術原理の説明だけである。当業者であれば、本願に係る発明の範囲は、上記技術的特徴の特定の組み合わせで形成される技術的解決手段に限定されるものではないと同時に、上記発明の構想から逸脱せず、上記技術的特徴とその均等の特徴から任意に組み合わせて形成される他の技術的解決手段も含むものである。例えば、上記特徴は、本願において開示される（ただし、特許請求の範囲に記載された）類似した機能を有する技術的特徴を相互に入れ替えて形成されたものである。

本開示の実施例はコンピュータ技術分野に関し、具体的にリソースの割り当て方法、装置、電子設備、コンピュータ可読媒体およびコンピュータプログラムに関する。

本開示の実施例はリソースの割り当て方法、装置、電子設備、コンピュータ可読媒体およびコンピュータプログラムを提案する。

Claims

リソースの割り当て方法であって、
クライアントから送信されたリクエストから、ターゲットサブサーバにマッチするリソースカテゴリ及び前記リソースカテゴリに対応する需要クォータを抽出するステップと、
前記リクエストを受信したサブサーバグループのサブサーバ数を確定するステップと、
前記リソースカテゴリにマッチするグローバル利用可能クォータ及び総バーストを確定するステップと、
前記総バースト及びサブサーバ数に基づいて、前記ターゲットサブサーバにおける、前記リソースカテゴリにマッチするバーストを確定するステップと、
前記需要クォータとバーストとの比較結果に基づいて、前記リクエストに対し、前記需要クォータに対応するリソース量でリソースを割り当てる操作を実行するステップと、
を含むことを特徴とするリソースの割り当て方法。
前記需要クォータとバーストとの比較結果に基づいて、前記リクエストに対し、前記需要クォータに対応するリソース量でリソースを割る当てる操作を実行するステップは、
前記需要クォータが前記バースト以下であることに応じて、前記バーストに対応するリソース量から、前記リクエストに対して、前記需要クォータに対応するリソース量を割り当てるステップを含む、請求項１に記載のリソースの割り当て方法。
前記バーストに対応するリソース量から、前記リクエストに対して、前記需要クォータに対応するリソース量を割り当てるステップの後に、更に
前記ターゲットサブサーバから送信された、前記需要クォータが割り当てられた後の残りのバーストを定時的に受信するステップと、
前記ターゲットサブサーバにおける残りのバーストに対応するリソース量へ補充するために、前記グローバル利用可能クォータに対応するリソース量から前記需要クォータに対応するリソース量を割り当てるステップと、
を含む、請求項２に記載のリソースの割り当て方法。
前記需要クォータと前記バーストとの比較結果に基づいて、前記リクエストに対し、前記需要クォータに対応するリソース量でリソースを割り当てる操作を実行するステップは、
前記需要クォータが前記バーストを上回ることに応じて、前記のターゲットサブサーバから、前記リクエストに対して、前記需要クォータに対応するリソース量を割り当てるステップと、
前記需要クォータを前記ターゲットサブサーバに記録するステップと、
を含む、請求項１に記載のリソースの割り当て方法。
前記需要クォータを前記ターゲットサブサーバに記録するステップの後に、更に
前記ターゲットサブサーバから送信された、記録された需要クォータを受信するステップと、
クライアントから送信された再度のリクエストを受信するステップと、
前記再度のリクエストを受信したことに応じて、前記グローバル利用可能クォータに対応するリソース量から、前記記録された需要クォータに対応するリソース量を差引くステップと、
を含む、請求項４に記載のリソースの割り当て方法。
前記需要クォータを前記ターゲットサブサーバに記録するステップの後に、更に
記録周期を計時するステップと、
前記ターゲットサブサーバから送信された、記録された需要クォータを受信するステップと、
記録周期が予め設定された時間の長さに達したことに応じて、前記グローバル利用可能クォータに対応するリソース量から、前記需要クォータに対応するリソース量を差し引くステップと、
を含む、請求項４に記載のリソースの割り当て方法。
グローバル利用可能クォータの現在残りのクォータが前記バーストより小さいかを判断するステップと、
グローバル利用可能クォータの現在残りのクォータが前記バーストより小さいと判断されたことに応じて、バーストに対応するクォータを前記グローバル利用可能クォータの現在残りのクォータに更新するステップと、
を更に含む、請求項３ないし６のいずれか１項に記載のリソースの割り当て方法。
リソースの割り当て方法であって、
クライアントから送信された、リソースカテゴリ情報及び前記リソースカテゴリ情報にマッチする総需要クォータを含むリクエストを受信するステップと、
前記リクエストにおけるリソースカテゴリ情報にマッチする総需要クォータに対し、
前記リクエストにおけるリソースカテゴリ情報にマッチするグローバル利用可能クォータ及び総バーストを確定することと、前記グローバル利用可能クォータがプリセット値を上回るかを判断することと、前記グローバル利用可能クォータがプリセット値を上回ると判断されたことに応じて、前記グローバル利用可能クォータと前記総バーストとを合計して、クォータ総量とすることと、前記総需要クォータが前記総クォータ以下であるかを判断することと、前記総需要クォータが前記総クォータ以下であると判断されたことに応じて、前記リソースカテゴリ情報に対応する総需要クォータがリソースの割り当て条件を満たすと確定することとを、含む確定ステップを実行するステップと、
前記リクエストにおける各リソースカテゴリ情報の対応する総需要クォータに対し前記確定ステップを実行することにより、各リソースカテゴリ情報の対応する総需要クォータがそれぞれリソースの割当条件を満たすかを判断するステップと、
それぞれ満たすと判断されたことに応じて、前記要求が受け付けられたことを表す指示情報を生成し、請求項１〜７のいずれか一項に記載の方法を用いて、前記要求された各リソースカテゴリに対してリソースの割り当て操作を実行するステップと、
を含むことを特徴とするリソースの割り当て方法。
更に、前記要求のいずれかのリソースカテゴリ情報の対応する総需要クォータがリソースの割り当て条件を満たしていないことに応じて、前記要求のインターセプトを示す指示情報を生成するステップと、を含む
請求項８に記載のリソースの割り当て方法。
リソースの割り当て装置であって、
クライアントから送信されたリクエストからターゲットサブサーバにマッチするリソースカテゴリ及び前記リソースカテゴリに対応する需要クォータを抽出するように構成される情報抽出ユニットと、
前記要求を受信したサブサーバグループのサブサーバ数を確定するように構成されている第１の処理ユニットと、
前記リソースカテゴリにマッチするグローバル利用可能クォータ及び総バーストを確定するように構成される第２の処理ユニットと、
前記総バースト及び前記サブサーバ数に基づいて、前記ターゲットサブサーバにおける、前記リソースカテゴリにマッチするバーストを確定するように構成されるバースト確定ユニットと、
前記需要クォータと前記バーストとの比較結果に基づいて、前記リクエストに対し、前記需要クォータに対応するリソース量でリソースを割り当てる操作を実行するように構成されるリソースの割り当て操作処理ユニットと、
を含むことを特徴とするリソースの割り当て装置。
前記リソースの割り当て操作処理ユニットは、更に、
前記需要クォータが前記バースト以下であることに応じて、前記バーストに対応するリソース量から、前記リクエストに対して、前記需要クォータに対応するリソース量を割り当てるように構成される、ことを特徴とする請求項１０に記載のリソースの割り当て装置。
前記リソースの割り当て操作処理ユニットには、更に
前記ターゲットサブサーバから送信された、前記需要クォータを割り当てた後の残りのバーストを定期的に受信するように構成される受信モジュールと、
前記ターゲットサブサーバにおける前記残りのバーストに対応するリソース量へ補充するために、前記グローバル利用可能クォータに対応するリソース量から、前記需要クォータに対応するリソース量を割当するように構成される第１のリソース割り当てモジュールと、
を含むことを特徴とする請求項１１に記載のリソースの割り当て装置。
前記リソースの割り当て操作処理ユニットは、
前記需要クォータが前記バーストを上回ることに応じて、前記ターゲットサブサーバから、前記リクエストに対して、前記需要クォータに対応するリソース量を割り当てるように構成される第２のリソース割り当てモジュールと、
前記需要クォータを前記ターゲットサブサーバに記録するように構成される記録モジュールと、
を含むことを特徴とする請求項１０に記載のリソースの割り当て装置。
前記ターゲットサブサーバから送信された、記録された需要クォータを受信するように構成される第１の情報受信ユニットと、
クライアントより送信された再度リクエストを受信するように構成される第１のリクエスト受信ユニットと、
前記再度リクエストを受信したことに応じて、前記グローバル利用可能クォータに対応するリソース量から、前記記録された需要クォータに対応するリソース量を差引くように構成される第３の処理ユニットと、
をさらに含む、請求項１３に記載のリソースの割り当て装置。
前記装置は、
記録周期を計時するように構成される計時ユニットと、
前記ターゲットサブサーバから送信された、記録された需要クォータを受信するように構成される第２の情報受信ユニットと、
記録周期が予め設定された時間の長さに達したことに応じて、グローバル利用可能クォータに対応するリソース量から、前記需要クォータに対応するリソース量を差引くように構成される第４の処理ユニットと、
を更に含む、請求項１３に記載のリソースの割り当て装置。
前記装置は、更に
グローバル利用可能クォータの現在残りのクォータが前記バーストより小さいかを判断するように構成される比較ユニットと、
グローバル利用可能クォータの現在残りのクォータが前記バーストより小さいと判断されたことに応じて、バーストに対応するクォータをグローバル利用可能クォータの現在残りのクォータに更新するように構成されるクォータ更新ユニットと、
を含む、請求項１２〜１５のいずれか一項に記載のリソースの割り当て装置。
リソースの割り当て装置であって、
クライアントから送信されたリクエストを受信するように配置される第２のリクエスト受信ユニットであって、前記リクエストは、リソースカテゴリ情報及び前記リソースカテゴリ情報にマッチする総需要クォータを含む第２のリクエスト受信ユニットと、
前記リクエストにおけるリソースカテゴリ情報にマッチする総需要クォータに対し、
前記リクエストにおけるリソースカテゴリ情報にマッチするグローバル利用可能クォータ及び総バーストを確定することと、前記グローバル利用可能クォータがプリセット値を上回るかを判断することと、前記グローバル利用可能クォータがプリセット値を上回ると判断されたことに応じて、前記グローバル利用可能クォータと前記総バーストとを合計して、総クォータとすることと、前記総需要クォータが前記総クォータ以下であるかを判断することと、前記総需要クォータが前記総クォータ以下であると判断されたことに応じて、前記リソースカテゴリ情報に対応する総需要クォータがリソース割り当て条件を満たすと確定することと、を含む確定ステップを実行するように構成される需要クォータ確定ユニットと、
前記リクエストの各リソースカテゴリ情報の対応する総需要クォータに対し、前記確定ステップを実行して、各リソースカテゴリ情報の対応する総需要クォータがそれぞれリソースの割り当て条件に満たすかを判定するように構成される確定ステップ実行ユニットと、
それぞれリソースの割り当て条件に満たすと判断されたことに応じて、前記要求が受け付けられたことを示す指示情報を生成し、且つ、請求項１〜７のいずれ１項に記載方法を利用し、前記リクエストの各リソースカテゴリに対し、それぞれリソースの割り当て操作を実行するように構成される第５の処理ユニットと、
を含むことを特徴とするリソースの割り当て装置。
前記リクエストのいずれかのリソースカテゴリ情報の対応する総需要クォータがリソースの割り当て条件を満たしていないことに応じて、前記リクエストのインターセプトを示す指示情報を生成するように構成される指示情報生成ユニット、をさらに含む、
請求項１７に記載のリソースの割り当て装置。
電子設備であって、
１つ又は複数のプロセッサと、
１つ又は複数のプログラムが記憶されている記憶装置と、を含み、
前記１つ又は多数のプログラムが前記１つ又は多数のプロセッサに実行されると、請求項１〜９のいずれか１項に記載の方法又は請求項１０又は１１に記載の方法を前記１つ又は複数のプロセッサに実行させることを特徴とする電子設備。
コンピュータプログラムが記憶されているコンピュータ可読媒体であって、
プロセッサによって実行されると、請求項１〜９のいずれかに記載の方法又は請求項１０又は１１に記載の方法を実現するコンピュータ可読媒体。