25

特にスケーラビリティを対象とした、どのようなデザインパターンまたはテクニックを使用しましたか？

Flyweightパターンなどのパターンは、高いスケーラビリティを促進するため、またはメモリやストレージの制約内で作業する場合に、ファクトリパターンの特殊なバージョンであるように思われます。

他に何を使用しましたか？（データベースの非正規化など）高可用性またはスケーラビリティが主な目標である場合、ルールが変更されると思いますか？

考えられる状況は次のとおりです。

  • デスクトップやラップトップよりもメモリ、処理能力、接続性が制限されているモバイルデバイス
  • 限られたハードウェア（キャッシュ戦略など）のユーザー数が多い
  • 正規化された設計の代わりに効率を高めるためのデータベーススキーマの最適化（例：ストレージのSharePoint列の折り返し）
4

5 に答える 5

45

頭に浮かぶいくつかのパターン：

  • ステートレスアプリケーション
  • 緩い結合
  • 非同期
  • 遅延読み込み
  • キャッシング
  • 並列処理
  • パーティショニング
  • ルーティング

いくつかのリソース：

于 2009-09-17T15:26:41.410 に答える
10

アプリケーションを可能な限りステートレスにします。サーバーファームへの適応が容易になります。

于 2009-09-17T15:19:54.890 に答える
6

何も無料ではありません-それはあなたのビジネス目標を達成するために許容できる妥協点に帰着します。主な変数は次のとおりです。

  • 費用
  • 可用性
  • 一貫性
  • 存続可能性（例、パーティショントレランス）

このテーマについて読むのに最適な論文。

良い指標は、「コスト/ユーザー」曲線を調べて、それを線形進行に維持しようとすることだと思います（ユーザーあたりの許容可能なコストが既知のパラメーターであると仮定します:-)

デザインパターンは役割を果たしますが、最も重要なのは包括的なアーキテクチャです。モジュールレベルでは非常に徹底的だったかもしれませんが、ネットワークレベルの制約を見逃し、結果としてスケーラビリティが低下します。

結局のところ、自分自身に問いかける必要があると思います。タイプXの障害の場合、影響を受ける可能性のある「ユーザー」の数と期間はどれくらいですか。

常にどこかにSPOF（Single Point Of Failure）がありますが、このSPOFがエンドポイント（ユーザーなど）に近づくようにシステムを設計することができます。ただし、多くの場合、SPOFはアプリケーションの制御外です。たとえば、ネットワークPOPは使用できません。

とにかく、私はその主題に何時間も費やすことができました...

于 2009-09-17T15:24:59.033 に答える
2

POSA（Patterns-Oriented Software Architecture）の本は、そのようなパターンの優れた情報源です。

特にPOSA4は分散コンピューティングに関係していますが、すべてのボリュームはスケーラビリティパターンでいっぱいです。

于 2009-09-17T15:48:29.330 に答える
1

ステートレスアプリケーションロジックで私が観察したことは、DBのロックなど、他の多くの要件が導入され、最終的にはスケーラビリティに反することです。

デプロイされたアプリケーションロジックがサーバーファーム全体でステートレスであるとすると、クラスターの2つのノードに同時にヒットするリクエストの場合、1つのリクエストのみが処理されるようにDBロックなどの概念を導入する必要があります。

私は今そのような状況に対処していて、他の誰もがそのようなステートレスな振る舞いにどのように対処しているのか疑問に思っていました。

于 2012-12-05T02:45:45.327 に答える