2

さまざまな登録ユーザーの 1 日あたりの特定の数のリクエストに応答する Web サービスを構築しています。各ユーザーには毎日の割り当てがあるため、これらの制約を満たす必要があります。

サーバーを追加し、ラウンドロビン方式で負荷分散することにより、水平方向にスケーリングすることを計画しました。

分散カウンターを持つ分散データベースを 1 つ作成します。このデータベースは、毎日のカウントを報告するためにのみ使用されます。

サーバーは 1 秒あたり 2 ~ 3,000 のリクエストを処理します。そのため、クォータを超えないように、各リクエストを処理するときに使い果たされたクォータの最新のカウントが必要です。

リクエストを処理する際のレイテンシーを低くするために、各サーバーからのプロセス外呼び出しを防止したいと考えています。

私は、すべてのサーバー間でクォータを分割し、サーバーごとのクォータの制約をメモリ内で維持するという観点から考えてきました。しかし、サーバーの障害や再起動にどのように対処すればよいでしょうか?

各サーバーからネットワーク経由で別のデータベースにクエリを実行するなど、アウト プロセスで実行した方がよいでしょうか。私が観察したことは、この場合、レイテンシが大幅に増加することです。

私が正しい方向に進んでいるかどうかアドバイスをお願いします。

4

1 に答える 1

0

クォータのシャーディングは、これを達成するための完全に受け入れられる方法です。多くのオンライン サービスでは、データの分割方法に基づいてクォータが分割されます。たとえば、DynamoDB はハッシュ キーに基づいてクォータを分割すると思います。これは、データを物理的に分割する方法だからです。

考慮すべきもう 1 つの点は、グローバル クォータを超えることはどの程度の罪になるのかということです。課金に支障はありませんか?あなたが依存しているサービスを殺しますか?

私が構築/維持しているサービスでは、サーバー間でトランザクション クォータをシャードし、各サーバーは定期的にサーバーの数の見積もりを更新します。請求は気にしませんが、基礎となるリソースを保護します。そのため、悪いネットワーク イベント中にリソースが処理できるスループットを計算し、それに基づいてクォータを設定しました。


ここで、CAP 定理に基づいた決定を行っていることがわかります。クォータの一貫性、可用性、分断耐性はどの程度ですか? クライアントのニーズを満たすために、次の 3 つの制約のうちどれを緩めることができますか? (この場合、クライアントには依存関係が含まれます)。

于 2013-10-05T19:09:43.683 に答える