分散キャッシングは、高性能の.NETWebアプリケーションの重要かつ不可欠な部分として認識されています。 これは、展開された中間層サービスまたはWebコンポーネントからの迅速な応答時間を必要とするエンドユーザーアプリケーションにも当てはまります。 これらの理由から、Microsoftは AppFabric、インメモリ分散キャッシュ。を使用するアプリケーションのパフォーマンスとスケーラビリティを向上させます。 .NET Framework.
AppFabric キャッシングは主に、ASP.NETセッション状態データを格納し、基本的なオブジェクトキャッシング機能を提供するために使用されてきました。 ただし、キャッシングはN層システムの不可欠な部分ですが、Microsoftは次のようにブログに書いています。 AppFabric サポート終了 11年20月XNUMX日現在17 すべてのバージョン。 これは、採用している.NETスタックにとって良いインセンティブです。 AppFabric より優れた、サポートされている分散キャッシュに移動します。
では、エンディングは何をサポートしますか 実際に意味する？ その意味は：
したがって、それはあなたが使用することを意味します AppFabric ご自身の責任で。 マイクロソフトは、事故やバグについて責任を負いません。 このため、迅速な解決策がないバグが原因で、ビジネスオペレーションがダウンタイムを維持できるかどうかを評価する必要があります。
そのような質問はあなたを代替案に向かわせるかもしれません。 代替案の準備ができている場合は、現在の設定から.NET分散キャッシュへのシームレスな移行を最小限のコード変更で提供するため、バグはまったく発生しません。 この代替分散キャッシュは、シームレスな移行をサポートするだけでなく、より高速で多くの機能を提供します。 AppFabric.
NCache 代替手段としての強力な選択です。 マイクロソフトは実際に推奨 NCache 彼らの中で 発表 エンディング AppFabric サポート。 NCache .NETコミュニティ内で広く使用されており、.NET分散キャッシングのマーケットリーダーであるため、この推奨事項を獲得しました。 10年連続. NCache 次のような幅広い機能とともに、卓越したパフォーマンスを提供します。
の他の利点 NCache 使いやすさ（一流のアナリスト企業によって最も使いやすい分散キャッシュとして評価されています）を含む、専用のGUIツールによる強力な管理および監視機能と、実質的にゼロのコストでオープンソース（GitHub上）として利用可能移行の前後。 オープンソースバージョンとエンタープライズバージョンは、公式サポート付きで、オンプレミスとクラウド（Amazon Web ServicesとAzure）で利用できます。
一方、 Redis 優れたインメモリキャッシュであり、 Redis コミュニティは次のように述べています Redis の可用性にもかかわらず、Windowsに対応していません Redis Windowsポート。 Redis 完全にスケーラブルではなく、高可用性機能も提供していません。 Redis'ツールセットの監視と管理はCLIのみです。 NCache に比べて多くの利点を提供します Redis このように ビデオリンク （そしてこのスライドシェア スマートガイド） 含む。
あらゆる運用環境のニーズを満たすために、 NCache から.NETアプリケーションを移行するXNUMXつの方法を提供します AppFabric 〜へ NCache; それぞれの方法には独自の利点があります。
XNUMXつの移行方法は次のとおりです。
NCache AppFabric ラッパーはよりスムーズでシームレスな移行を提供しますが、直接API呼び出しを介して移行すると、より詳細な制御が可能になり、次のすべての機能を利用できるようになります。 NCache.
からの最も簡単で迅速な移行を探している組織向け AppFabric、このラッパーはこれまでで最も簡単な移行を提供します。 .NETアプリケーションで必要な変更はXNUMXつだけです。 NCache 考えられるバグをまったく導入せずに準拠します。 これらの変更は次のとおりです。
<appSettings>
<add key="region1" value="myPartitionedCache"/>
<add key="Expirable" value="True"/>
<add key="TTL" value="5"/>
</appSettings>using Microsoft.ApplicationServer.Caching.Client;
using Microsoft.ApplicationServer.Caching.core;
と：
using Alachisoft.NCache.Data.Caching;以上です！ .NETアプリケーション内で他のコードを変更する必要はありません。
使い方 NCache Open Source から移行できます AppFabric どちらの製品も無料なので、無料です。 NCache Open Source Enterpriseエディションと比較して機能のセットが制限されていますが、コアキャッシュのパフォーマンスが低下することはありません。
移行を容易にするために、別のバージョンの AppFabric ラッパーが提供されます NCache オープンソースAPIと互換性のあるOSS。 での機能が少ない NCache Open Source NCache Open Source ラッパーは、次のような不足している機能を回避します。
NCache Open Source のラッパー AppFabric すべてのオブジェクトを別のクラス内にカプセル化することにより、アイテムのバージョン管理を維持するという課題を克服します。 これは、変更されたラッパーにMetaDataCapsuleという名前の新しいクラスを導入することによって行われます。
namespace Alachisoft.NCache.Data.Caching.Util
{
[Serializable]
class MetaDataCapsule
{
private object value;
public ItemVersion CacheItemVersion { get; set; }
public string Group { get; set; }
public object Value { get { return this.value; } }
private MetaDataCapsule(object value, ItemVersion version, string group)
{
this.CacheItemVersion = version;
this.Group = group;
this.value = value;
}
public static MetaDataCapsule Encapsulate(object value, string region)
{
return new MetaDataCapsule(value, 1, region);
}
}
}これは、オブジェクトのアイテムバージョンを維持し、必要に応じて他の有用な情報を運ぶのに役立ちます。 クラスはネットワーク上を移動する必要があるため、Serializableとしてマークされます。
異なるまたは類似のアプリケーションのすべての複数のインスタンス全体でアイテムバージョンとオブジェクトの一貫性を確保するために、分散ロックが使用されます。 分散ロックはの機能です NCache これにより、データの一貫性を損なうことなく、また競合状態を回避することなく、複数のアプリケーションが同じリソースにアクセスして変更できるようになります。
LockHandle lockhandle = null;
MetaDataCapsule oldMetadata;
bool lockAcquired = GetLock(_key, ref lockhandle, out oldMetadata);
if(!lockAcquired)
{
_NCache.Unlock(key);
throw new DataCacheException("Unable to acqurie lock to update Item Version");
}
//Return in case of version provided
if (oldVersion != null && oldMetadata.CacheItemVersion == oldVersion._itemVersion)
{
_NCache.Unlock(key);
return null;
}
if (lockAcquired)
(_item.Value as MetaDataCapsule).CacheItemVersion = ++metadata.CacheItemVersion;
_NCache.Insert(_key, _item, lockhandle, true);要約すると、すべてのPut操作で：
上記のシナリオでロックすると、別のアプリケーションが同じキーを変更しようとした場合に、他のアプリケーションがアイテムを更新または削除できないようになります。
上記のコードには、GetLockという名前のメソッドがあり、実装は次のとおりです。
// <summary>
// Tries to acqurie lock and return LockHandle and MetaDataCapsule object.
// If LockHandle is provided uses that instead.
// <para>Default Lock Timeout (default 5 seconds), Retry Count (default 3)
// and retry interval (default 100 ms) is set when Cache Handler is instantiated.
// </para>
// </summary>
// <param name="key">Formatted Key i.e compile from formatter</param>
// <param name="lockHandle">Either provide a lock or keep it null to acquire a new lock
// </param>
// <param name="metadata">The returned object for internal use</param>
// <returns>true if lock was acquired</returns>
internal bool GetLock(string key, ref LockHandle lockHandle,
out MetaDataCapsule metadata)
{
//Item is locked
int count = _retries;
while (count != 0)
{
//If lock was provided attempt to acquire the lock from the given handle
if (lockHandle == null)
{
lockHandle = new LockHandle();
}
object obj = _NCache.Get(key, _defaultLockTime, ref lockHandle, true);
//obj is null of the lock was not acquired
if (obj == null)
{
count--;
Thread.Sleep(_retryTimeOut);
}
else
{
metadata = obj as MetaDataCapsule;
return true;
}
}
lockHandle = null;
metadata = null;
return false;
}GetLockメソッドは、ロックをXNUMX回取得しようとします。 失敗した場合は「null」を返し、呼び出し元のメソッドにこの例外を処理させます。 したがって、分散ロックの助けを借りて、 AppFabric のラッパー NCache Open Source 例外ケースを含め、クライアントアプリケーションによって挿入されたキャッシュアイテムのバージョンを維持します。
オープンソースエディションには一部のエンタープライズ機能がないため、次の関数は「廃止」とマークされ、「コンパイルエラーをスロー」とマークされて、コードの変更を確実にし、予期しない事態を回避します。
したがって、アプリケーションがこれらの機能に大きく依存している場合は、 NCache Enterprise バージョンは、よりスムーズでシームレスでバグのない移行を可能にするための最良のオプションかもしれません。
多くを最大限に活用したい開発者向け NCache Enterprise 機能、あなたは直接呼び出すことを好むかもしれません NCache ラッパーを使用する代わりにAPI。 から「unwrapメソッド」を使用することもできます AppFabric 直接操作するラッパー NCache 同様に。
いずれにせよ、移行は1段階で行うことをお勧めします。 フェーズXNUMXでは、引き続き AppFabric 機能がありますが、キャッシュを次のように置き換えます NCache。 フェーズ2では、追加の新しい実装 NCache で利用できなかった機能 AppFabric.
このフェーズでは、あなたの焦点はただ置き換えることです AppFabric。 したがって、これらXNUMXつの分散キャッシュがどのように動作するかを理解することが重要です（以下および 参照セクション 最後に）。 述べたように、 AppFabric 特定のマシンのリージョンにデータを保存します。 一方、地域データを複製するには NCache すべてのキャッシュを作成できます AppFabric 地域、またはあなたが作成することができます NCache 開催するグループ AppFabric 地域データ。
NCache グループ/サブグループは、キャッシュされたアイテムをグループ化するさまざまな方法を提供します。 リージョンは名前付きキャッシュ内に存在するため、 NCache グループを使用してこの動作を再現します。 唯一の違いは AppFabric キーは、名前付きキャッシュ全体ではなく、リージョン内でのみ一意である必要があります。 一方、 NCache、キーはキャッシュ全体で一意である必要があり、どのグループに属しているかは関係ありません。 リージョン名の前にすべてのキーを付けると、この障害をすばやく克服できます。
例：
In AppFabric、基本的な追加操作は次のようになります。
// AppFabric API
regionCache.Add(stringKey, stringValue);そして、中 NCache 基本的なコマンドも同じですが、コマンドでリージョン名をグループとして指定できる点が異なります。
// NCache API
cacheInstance.Add(regionName + ":" + stringKey, stringValue, regionName);
// Where regionName is as Group
ここでは、キャッシュキー間の一意性を実現するために、すべてのキーの前にリージョン名が付けられています。 グループは、検索操作を実行するときにSQLクエリを使用して検索を高速化するため、またはデータ検索を容易にするために、キーに割り当てられます。
キャッシュされたアイテムをグループ化するもうXNUMXつの方法は、リージョン間の相関関係を完全に削除し、リージョンごとに個別のキャッシュを使用することです。 同じ結果を得るには、すべてのリージョンに個別のキャッシュが割り当てられ、キャッシュに対応するリージョン名のマップを保存できます。
// NCache API
cacheInstance = map.get(regionName);
cacheInstance.Add(stringKey, stringValue);この例では、キャッシュが NCache 同じクラスターに存在する場合でも、相互に排他的です。
アプリケーションが多くのリージョン（たとえば15を超える）を処理する必要がある場合は、クラスターごとに15のキャッシュが推奨される最大キャッシュ数であるため、リージョンをグループとして使用することをお勧めします（クラスターは論理的に無限の数のキャッシュをホストできます）。 。
次のフェーズでは、次の機能を利用できます。 NCache 提供する AppFabric & Redis 足らない。 次のような機能：
データベースの同期は、優れた分散キャッシュにとって非常に重要な機能です。 キャッシュされるほとんどのデータはリレーショナルデータベースからのものであるため、他のアプリケーションまたはユーザーがデータを変更し、キャッシュされたデータが古くなる可能性がある状況が常にあります。
アプリケーションは多くの場合、このデータのサブセットをフェッチする必要があり、SQLのようなクエリ言語で分散キャッシュを検索し、基準の一部としてオブジェクト属性を指定できる場合は、分散キャッシュがはるかに便利になります。
多くの人は、分散キャッシュを「サイドのキャッシュ」として使用し、データベースから直接データをフェッチしてキャッシュに入れます。 もうXNUMXつのアプローチは、アプリケーションがキャッシュにデータを要求するだけの「キャッシュスルー」です。 また、データが存在しない場合、分散キャッシュはデータソースからデータを取得します。 同じことがライトスルーにも当てはまります。
これに伴い、 NCache また、インメモリデータでビッグデータ分析を可能にするMapReduceをサポートし、ほぼリアルタイムで結果を生成します。
クライアントキャッシュは、クライアントマシン上の単なるローカルInProc / OutProcキャッシュですが、分散キャッシュクラスターとの接続と同期を維持します。 このように、アプリケーションのパフォーマンスは、データの整合性を損なうことなく、この「近さ」から実際に恩恵を受けます。
WANレプリケーションは、ディザスタリカバリの目的または地域のトラフィックの負荷分散のために複数のデータセンターに導入されている多くのアプリケーションにとって重要な機能です。
WANレプリケーションの背後にある考え方は、WANの遅延が大きいために、地理的な場所ごとにキャッシュの速度を低下させてはならないということです。 NCache これらすべてを処理するためのブリッジトポロジを提供します。
Microsoftのサポート AppFabric このホワイトペーパーでは、.NETアプリケーションを移行するための2017つの方法を紹介します。 AppFabric 〜へ NCache、およびこの変更を行うことの利点。 NCache は、AzureおよびAmazon Web Servicesのオープンソースとして、また NCache Webサイト。 フルサポートもご利用いただけます。
無料で使用する NCache AppFabric どちらかのラッパー NCache Open Source or NCache Enterpriseは、最も簡単で、コーディングがなく、バグのない移行方法を提供します。 直接呼び出すことによる移行 NCache APIはより多くのデータ制御を提供し、すべてを可能にします NCache 特徴。 このホワイトペーパーでは、すべての移行方法について説明しています。
評価と製品のニーズを満たすために、これらの追加リソースを確認してください。
地域 in AppFabric XNUMX台のサーバーマシンにバインドされているキャッシュのインスタンスに格納されているキーと値のペアの論理コンテナです。 このため、リージョン内のデータを配布することはできません。 このアーキテクチャ構造は、より高速なフェッチを可能にすると主張しています。 ただし、分散キャッシュと比較すると、全体的なパフォーマンスが大幅に低下します。
NCache コアの分散キャッシュです。 内部のすべてのデータ NCache が配布され、バックアップコピーが別の物理マシンで維持されている場合 パーティションレプリカ （PR）トポロジーが使用されます。 PRは、データ損失をゼロにするために、ワールドクラスの超高速パフォーマンスとフェイルオーバーレプリカを提供します。
したがって、 AppFabric で個別のキャッシュとして構成されている NCache データフェッチ機能を損なうことなく。 The AppFabric ラッパーはこの複雑さを引き継ぎ、指定されたキャッシュ名にすべてのリージョンデータを自動的に保存します。 唯一の要件は、 NCache すでに存在している必要があります。 キャッシュを作成するには NCache マネージャー、GUIベースのクラスター管理ツール。 キャッシュが作成されると、データは AppFabric リージョンは指定された場所に配布されます NCache クラスター。 データが実際に分散されているにもかかわらず、SQLクエリを含む高度な検索を実行する能力に妥協はありません（SQLクエリは AppFabric まったく）。
間のその他の顕著な違い NCache & AppFabric 両方の製品を構成する方法です。 AppFabric 実行時にアプリケーションによって構成され（キャッシュの作成も）、対照的に NCache キャッシュが開始される前に構成されます。 たとえば、キャッシュトポロジは実行時に変更できませんが、キャッシュのデフォルトの有効期限などの他の構成は後で変更でき、それらはホットアプライ可能と呼ばれます。 それでも NCache .NETアプリケーション（キャッシュの作成を含む）を使用して管理できますが、 NCache Manager-キャッシュクラスターを管理するための専用の単一ツール。 CLIからキャッシュを作成、構成、および保守することもできます。
一方、 NCache AppFabric-wrapperは、.NETアプリケーションをに移行する最も簡単な方法を提供します NCache、これも可能な限り最小限のコード変更で、一部の開発者は依然としてすべての機能を利用することを好みます NCache 提供する必要があります。 それは直接呼び出すところです NCache APIが役立ちます。 からUnwrapメソッドを呼び出すことにより、両方のメソッドを使用するオプションもあります。 AppFabric ラッパー。
AppFabric クラスターは完全に動的ではありません。 依存性 「リードホスト多数決」 つまり、リードホストがXNUMXつでもダウンした場合、クラスターは非常に簡単にダウンする可能性があります。 これらのリードホストノードも「マスター」および「スレーブ」アーキテクチャに似ているため、完全にピアツーピアではありません。
NCache 一方、 非常に動的 また、キャッシュやアプリケーションを中断することなく、実行時にキャッシュサーバーを追加または削除できます。 データは、中断やパフォーマンスの低下なしに、実行時に自動的に再調整されます（状態転送と呼ばれます）。 NCache クライアントは、サーバーの状態に関係なく、キャッシュサーバーとの通信を継続します。 クラスターは、データバランシングが進行中の場合でも、クライアント操作の実行を保証します。
これは、 NCache、クラスター内に「マスター」ノードまたは「スレーブ」ノードはありません。 最上位のノードである「プライマリコーディネーター」ノードがあります。 そして、それがダウンした場合、次に上位のノードが自動的にプライマリコーディネーターになります。 これはすべて、クライアントの操作を中断することなく行われます。