3

クラウド データベースからのデータ アクセス レイヤーに多くの REST API を使用するトラフィックの多いクライアント Web アプリケーションを実装しています。REST を実装していて提供していないため、クライアントと言いました。

REST API はクライアント側だけでなくサーバー側にも実装されているため、キャッシュの適切なソリューションを見つける必要があります。アプリケーションは Web ファームで実行されているため、memcached のような分散キャッシングに傾倒しています。このキャッシング ソリューションは、アプリケーションと REST API の間のプロキシ レイヤーのようなもので、クライアント側とサーバー側の両方をサポートする必要があります。

たとえば、レコードを更新する呼び出しを行った場合、REST を介して更新し、更新されたレコードをキャッシュに保持して、そのレコードへの次の呼び出しで外部 REST サービスへの余分な呼び出しを必要としないようにします。

REST 呼び出しを可能な限り最小限に抑え、データをできる限り正確に保つ必要がありますが、100% 正確である必要はありません。

このキャッシング プロキシの最適なソリューションは何ですか? ローカル キャッシュを備えたサーバーの 1 つで実行されるスタンドアロン アプリケーションですか、それとも分散キャッシュを使用して現在のソリューションに組み込まれていますか? あなたのアイデア、提案、または懸念は何ですか

ありがとうございました、

4

1 に答える 1

4

あなたは頭に釘を打ちました。データのプロキシとして機能するキャッシュ レイヤーが必要です。

クラウドの概念を少し抽象化したレイヤーを作成することをお勧めします。クライアントは、データがどこから来たのか気にするべきではありません。クラウドや他のすべてのデータと通信するリポジトリ レイヤーを作成します。次に、クライアントが実際に呼び出すサービス層をその上に配置できます。このサービス層の内部には、キャッシュ層などを実装する場所があります。

以前は、環境に応じてMemCached またはMemCached Win32を使用することを常に提案していました。Windows の世界にいる場合、MemCached win32 は非常にうまく機能します。MemCached win32のEnyimクライアントに注目してください。これは、他のすべてのポートの中で最も問題が少ないものです。

ただし、.net の世界にいる場合は、Velocityを試すことができます。MS は、ファームの概念をサポートする必要があるという点で、キャッシング フレームワークに穴があるという手がかりを得ました。前回確認した Velocity はまだベータ版ではありませんが、一見の価値はあります。

私は一般的に、最初からリポジトリとサービス層の概念を使用することをお勧めします...たとえそれが必要でなくても。アプリケーションをどの方向に引き込む必要があるかわからないため、アプリケーションに提供される柔軟性は持つ価値があります。通常、この柔軟性が必要な最大の理由は、スケーリングの必要性です。しかし、通常、スケーリングが必要な場合は、今すぐスケーリングする必要があります。リポジトリ レイヤーとサービス レイヤーでリファクタリングを行うことは、不可能ではありませんが、通常はやや複雑です。

于 2009-08-17T21:52:14.227 に答える