使い方 NCache as AppFabric Alternative

録画されたウェビナー
ロン・フセイン、ザック・カーン著

AppFabric は寿命に達しており、ここからどこに行くかを考えている場合は、このウェビナーを視聴する必要があります。 このウェビナーでは、.NETアプリケーションをから移行するさまざまな方法を紹介します。 AppFabric 〜へ NCache.

NCache 非常に高速でスケーラブルな .NET/.NET Core 分散キャッシュ システムであり、次のラッパーを提供します。 AppFabric に移行できるようになります NCache アプリケーションのコード変更は最小限またはまったく必要ありません。 あなたの Appfabric アプリケーションで使用される API が動作し始める NCache シームレスに。 さらに、によって提供される他の多くの API や機能の使用を開始できます。 NCache にはない高度なキャッシュ機能用 AppFabric.

このウェビナーの内容は次のとおりです。

• の概要 AppFabric そしてその寿命の終わりの問題
• なぜ NCache に最適なオプションと代替手段です AppFabric
• へのさまざまな移行方法 NCache
  • ノーコード変更ラッパーを介して
  • 直接を通じて NCache API呼び出し
  高度な分散キャッシング機能 NCache オファー
• 移行の実例とデモンストレーション

今日のトピックは次のとおりです。 NCache として AppFabric 別？" 今日のウェビナーでは無数のトピックが取り上げられます。 特に概要については、 AppFabric そしてその終末期の問題。 また、その理由についても、 NCache ～の最良の代替品は AppFabric および当社が提供する高度な分散キャッシュ機能は、以下の代わりに使用できます。 AppFabric を提供し、実際の例とデモンストレーションを行う方法について説明します。 から移行する AppFabric 〜へ NCache?

なお、これはライブウェビナーなので、いつでも質問タブを使用して質問や疑問、懸念事項を入力していただければ、対応させていただきます。 そして、ウェビナーの最後には、別の Q&A セッションも用意されています。そのため、最後まで残したい質問がある場合は、それについてもお答えします。 わかりました、早速、ロン、あなたが発言権を持っています。

それで、今日のトピックは非常に具体的なものです。 ご存知のとおり、カバーされます AppFabric サポート終了の問題があり、Microsoft 自体がこのテクノロジから移行することを推奨しているためです。 したがって、使用している場合は、 AppFabric アプリケーション、それがまだアプリケーション アーキテクチャの一部である場合は、いくつかのオプションを提示します。 NCache そこから移行することができます。その移行がどれほどスムーズであるかを説明します。 からの移行がいかに簡単か AppFabric そして使えるようになる NCache そのままで、いくつかの拡張機能を使用できるようになります。 NCache which AppFabric 完全に欠けています。 それで、 AppFabric 非常に限定された商品です。 以前は非常にうまく機能していましたが、サポートが終了したため、バックアップされていません。 もう更新されていません。 したがって、そこから移行する時期が来ています。

そこで、今日はその詳細をすべて説明します。 使用に関するさまざまなオプションは何ですか NCache、App Fabric の代替製品としての説明、App Fabric からの移行がいかに簡単か、使い始めた場合にどのようなメリットが得られるかについて説明します。 NCache。 そこで、いくつかの技術的な詳細について説明します。

の概要 AppFabric

それで、話しましょう AppFabric 一般に。 ほとんどの方がすでにご存知かと思いますが、 AppFabric そしてそのアーキテクチャ。 あなたの環境で使用されている場合は、実際の経験が必要です。 AppFabric。 これは、インメモリ .NET 分散キャッシュ システムです。 これは主に、Windows Server の一部として提供される無料の分散キャッシュとして使用されます。 これは主に、データベースへのアクセスを節約するためにキャッシュを必要とする Web アプリケーション、中間層サービス、その他の .NET アプリケーションに使用されます。 Microsoft によってリリースおよびサポートされました。 2010 年に 1.0 がリリースされ、1.1 年に 2015 がリリースされました。これが最後のバージョンでした。 AppFabric。 キャッシュ API、その使用方法 AppFabric? 主に .NET アプリケーションになります。 AppFabric データ クラスを公開してからラッパーを公開し、API を公開します。 AppFabric あの図書館を通して。 いくつかのプロバイダーを使用することもできます。 AppFabric 持っていました。 ASP.NET セッション状態プロバイダーと ASP.NET 出力キャッシュ プロバイダー。 したがって、これらはコード変更なしのオプションであり、データ キャッシュを使用したくない場合や、Web 固有のキャッシュに重点を置いている場合に使用できる、コードを変更せずに利用できる XNUMX つの機能でした。

AppFabric アーキテクチャ図

アーキテクチャの内訳は次のとおりです。 非常に簡単です。キャッシュ サーバーを用意することです。キャッシュ サーバーは、以下に関してキャッシュ ホストと呼ばれます。 AppFabric。 これにより、キャッシュ クラスターを構築できます。 いくつかの制限はありますが、多数決の概念がありました。 少なくとも 3 つのサーバーが必要で、いずれかのサーバーがダウンすると多数決に違反します。 そのため、高可用性とデータの信頼性が損なわれる可能性があるため、リード ホストの概念も存在しました。

ただし、ここでの考え方は、キャッシュをホストするキャッシュ サーバーがあるということです。 キャッシュ用のリポジトリを作成すると、アプリケーションはこのキャッシュ リポジトリに接続でき、複数のサーバーによってバックアップされ、キャッシュ操作を実行できるようになります。

以前は PowerShell ベースのキャッシュ管理ツールがありました。 キャッシュ構成とクラスター構成は通常、ファイル システムまたはデータベースの保存場所にありました。 つまり、それは内部の別の依存関係でした AppFabric。 ここでは、キャッシュが有効なアプリケーション サーバーまたはキャッシュ クライアントが、環境内で実際にキャッシュをホストするこのキャッシュ サーバーに接続する方法について概要を説明します。

AppFabric もう寿命です。 最初の発表は 2016 年 2016 月に行われました。そこで Microsoft は、このテクノロジはサポートされなくなるため、このテクノロジから移行することを推奨し始めました。 彼らは、20 年 XNUMX 月にこの製品のサポート ライフ サイクルの終了を発表し、その後 XNUMX 年以内にメインストリーム サポートを終了しました。 それでXNUMX17 限りにおいて、彼らの主流のサポートは終了しました。 AppFabricMicrosoft からの公式サポートが懸念され、次に延長サポートが懸念されます。 彼らは数年前からサポートを延長してきましたが、現在の最終期限は 2022 年になる予定です。

つまり、基本的にはこれであり、これが Microsoft が提供する最後の拡張機能になる可能性があると予想されます。 したがって、このテクノロジーから移行することを強く推奨しています。 オープンソースではありません。 したがって、それをバックアップするコミュニティもありません。 あなたもご存知のとおり、オンライン リソースは、私がこのウェビナーを準備していたときに AppFabric Microsoft ポータルからのヘルプ ドキュメントは、使い始めると非常にわかりにくくなります。

したがって、支援リソースを得るのは非常に困難です。 公式サポートはもうありません。 限定的な延長サポートが利用可能です。 これ以上のバグ修正は提供されません。 機能セットにこれ以上の機能拡張は追加されません。 次のような新しいプラットフォームを使用している場合は、 .NET Core、プラットフォームの互換性、セキュリティアップデートはこれに含まれません。 つまり、実質的に人生の終わりです。 これは旧式の製品であり、これが Microsoft が製品から移行して代替製品を使用することを推奨している理由です。そのため、このウェビナーも開催しています。 NCache、交換オプションとして。

主要ベンダーである Microsoft が App Fabric から移行することを推奨しているため、App Fabric を主に使用するのは非常に危険です。 実稼働デプロイメントは、サポートがない、バグ修正がない、機能拡張がない、互換性やセキュリティ更新がないため、今話しているようにリスクにさらされています。 帰っちゃうの。 何かがダウンした場合のコストは非常に高くなります。それは、ミッションクリティカルなアプリケーションで使用している可能性があり、そのアプリケーションが AppFabric そして、問題が発生したり、ダウンしたりした場合、どこに行けばよいのかわかりません。 したがって、ビジネスに影響を与える可能性があり、全体的なユーザー エクスペリエンスにも影響を与える可能性があります。

したがって、移行を実行することをお勧めします。 具体的には、非常に簡単な移行オプションが利用できる場合、 NCache オファーします。 したがって、このプロジェクトを優先的に完了することを強くお勧めします。実際、このウェビナーでは、このウェビナーの終わりに近づくにつれて、既存の AppFabric アプリケーションから移行するためのステップバイステップのガイドを示します。 移動します AppFabric 〜へ NCache。 そのアプリケーションは完全に使用を停止することができます AppFabric そして使用を開始 NCache それがいかに簡単かを教えてやろう。 これは XNUMX つのステップからなるプロセスであり、このウェビナー内で説明します。これにより、使用を開始する方法についての非常に良いアイデアが得られるはずです。 NCache 代替案として。 ここまでで何か質問はありますか？

以上、ほんの一部の紹介でした。 方法についての詳細 AppFabric 存在したのか？ 何が問題であり、実際にそこから移行する方法は何ですか?

NCache 移行オプションとして

そう、 NCache 移行オプションです。 それはとても自然な選択です。 NCache は 100% ネイティブの .NET 製品であり、15 年以上市場に出回っており、市場での完全な実績があり、多くの注目を集め、実際にカスタム展開が行われています。 NCache 当社にはさまざまな業界のあらゆる場所に顧客がいます。

• 移行に関して得られる最初のメリットは、 AppFabric 〜へ NCache つまり、Windows プラットフォームを入手できるということです。 それで、 AppFabric Windows ベースの製品であるため、 NCache もネイティブの Windows ベースの製品です。 そのため、.NET ベースのキャッシュ サーバーがあるため、Windows にネイティブに展開できます。 使用している場合 AppFabric、2012 または 2016 のボックスを使用している可能性があります。 したがって、同じオペレーティング システムのセットを使用しても、引き続きインストールできます。 NCache 同じボックスにあります。 したがって、別のテクノロジーから移行するために、一致させる必要がある特定のハードウェア要件やオペレーティング システム要件はありません。 したがって、これは環境内にすでに存在しているものと非常に互換性があります。
• これは、最も古い、最も安定した .NET 分散キャッシュです。 当社はこの分野の市場リーダーです。 当社には巨大な顧客ベースがあり、 NCache .NET アプリケーションで。 以来、 AppFabric これも.NET APIに基づいています。 したがって、どこから使い始めるかは非常に自然な選択となります。 NCache API を使用するか、コード変更のないオプションであるラッパー アプローチを使用して、 AppFabric そして使用を開始 NCache。 完全にサポートされています。 右。 これが、前のスライドで取り上げた主なポイントです。 AppFabric 人生の終わりです。 どのコミュニティからもサポートされていません。 オープンソースではありません。 公式サポートはありません。 延長サポートは利用可能ですが、最終的には廃止される可能性があります。 つまり、あなたは危険にさらされています。
• NCache、クライアントの観点からだけでなく、サーバーからも完全にサポートされたソフトウェアを入手できます。 パフォーマンスの問題、セキュリティの問題、バグなど、新しい機能が必要な場合は、弊社までご連絡ください。協力させていただきます。
• はるかに強力で機能も豊富です。

ここでは、考慮すべき最も一般的な要因をいくつか列挙しました。 NCache として、代替として。 主な理由は、.NET と Windows のサポートによるものです。 次に、業界内または .NET アプリケーション内で実績があり、完全にサポートされています。 公式の定期サポート オプションと 24 時間 7 日のサポート オプションが当社のチームから利用可能です。 また、拡張できるさまざまな機能についても説明します。 したがって、既存のキャッシュのユースケースを拡張できます。 私たちを訪れる顧客は、次のようなユースケースを持っています。 AppFabric しかし彼らが採用するとき NCache 彼らはユースケースを拡張して、でのみ利用できる高度な機能を使い始めたいと考えています。 NCache & AppFabric それらの機能が完全に欠けています。 したがって、それは考慮すべきもう一つの要素です NCache 移行オプションです。

NCache 企業への導入

NCache 通常、大規模な企業での導入方法は次のとおりです。 NCache のように見える。 ここでも、キャッシュ クラスターをホストする一連のサーバーが存在します。 AppFabric、多数決やリードホストの概念を持つ必要はありません。 これは、100% ピアツーピア アーキテクチャのキャッシュ クラスターです。 TCP/IP ベースのクラスタリング プロトコルを使用します。 サーバーのチーム上にキャッシュ クラスターを作成すると、これらのサーバーは、それに接続されているクライアント アプリケーションからのリクエスト処理能力に貢献します。 したがって、これらはASP.NETまたはASPである可能性があります.NET Core ウェブアプリ。 新しいスタックにもあります。 .NET または .NET Core Webサービスまたは .NET Core サーバーアプリケーション。

したがって、一般に、どの .NET でも、 .NET Core または Java アプリケーションでも接続できます NCache を利用します NCache キャッシング。 とてもシンプルです。

2から始めることもできます NCache 高可用性とデータ信頼性の機能を得るには、キャッシュ クラスターを構築するサーバーは最低 2 台です。 サーバーは 2 台でも動作しますが、少なくとも XNUMX 台のサーバーを使用することを強くお勧めします。 NCache 高可用性とデータ信頼性を活用するサーバー。 そして、とても柔軟です。 これにより、必要な数のキャッシュを作成できます。 サイズ、メモリが増加する可能性があり、さらに、 NCache.

このセクションについては、定期的な記事で非常に詳細に説明しています。 NCache 建築ウェビナー ただし、これは紹介スライドのようなものです。そのため、以下に関して具体的な質問がある場合はお知らせください。 NCache 配備

NCache アプリケーションを別のボックスに入れて、別の専用サーバーにデプロイできます。 NCache 別の箱に入っているか、 NCache アプリケーションも同じボックスにあります。 つまり、Windows Serverボックスホスティング NCache クライアント ボックスや Web サーバー ボックスとしても機能します。 アプリケーションが同じマシンにデプロイされているだけです。 NCache も走っています。 したがって、これも可能です。または、別の層のキャッシュ サーバーを用意し、アプリケーションを別のボックスに配置することもできます。 したがって、私たちは非常に柔軟です。

で利用可能です Microsoft Azure、AWS およびパブリック クラウドまたはプライベート クラウドでも同様です。 それだけが必要なのです .NET Framework の前提条件として NCache 必要なのはそれだけです。 先ほども言いましたが、非常に柔軟性があり、非常に使いやすい製品です。 App Fabric と比較すると、App Fabric からの自然な移行となります。 AppFabric 〜へ NCache 採用する予定がある場合。

移行オプション

そこで、次に移行オプションについて説明し、これを実現するための実践的な例を示します。

アプリのデータキャッシュ

データ キャッシュについては、.NET API があり、セッションと出力キャッシュ機能があると説明しましたが、 AppFabricしたがって、これは全体的なユースケースである必要があります AppFabric。 現在、ライブ アプリケーションを実行している場合、データ キャッシュが最も一般的なユース ケースである可能性が高く、App Fabric の使用中にアプリケーションで使用したことがあるはずです。

• 使い方 AppFabric ラッパー

  それでは、次を使用してアプリケーションを移行する方法について説明します。 AppFabric そしてあなたは使い始める NCache 代わりとして。 したがって、選択肢は XNUMX つあります。 私たちはラッパーを設計し、アプリケーション コードを変更することなく実装しました。 コードを変更する必要はありません。 使い始めることができます NCache の代わりとして AppFabric。 私たちのものを使うだけでいいのです NuGet そして名前空間を更新します。 それで、私たちがやったことは、ラッパーを実装したということです AppFabric API なので、アプリケーションを作成するたびに AppFabric API 呼び出し。ラッパー実装がその呼び出しを受け取り、呼び出しを開始する舞台裏 NCache これは、既存のアプリケーションを実際に管理する方法を示す、非常にシンプルで使いやすいオプションです。 私はこれを並行して実行するつもりです、そしてあなたのすべて AppFabric API は次のように動作し始めます。 NCache シームレスに。 コードを変更する必要はありません。 ライブラリと名前空間を変更するだけで、仕事は完了します。

• 直接作る NCache API呼び出し

  XNUMX 番目のオプションは、直接 NCache API 電話。 その中で、コードを変更して導入します。 NCache API は自分自身を呼び出します。 交換を開始できます AppFabric API を使用することも、既存の API の拡張を開始することもできます。 AppFabric API と拡張機能の使用も開始します。

これら XNUMX つのアプローチを並べて使用することもできます。 たとえば、すでに持っているもの AppFabric、ラッパーを使用して基本をカバーし、拡張機能を使用できます。 機能を使用。 欠けている機能 AppFabric、ネイティブ API を通じて使用を開始できます。

NCache ラッパーアプローチ

そこで、これら XNUMX つの側面について説明します。 NCache サンプルアプリケーションの助けを借りて。 したがって、これがラッパーアプローチです。

実際に始める前に、環境をセットアップしてその方法を説明しましょう。 NCache 設定方法とセットアップの簡単さ NCache クラスター環境。 そのために、デモ環境にログオンします。

環境のセットアップとキャッシュクラスターの作成

これは我々の ウェブ管理ツール。 これには環境内のどこからでもアクセスできます。 それはクライアント ボックスやアプリケーション ボックスである可能性があります。 それはあなたの現在かもしれません AppFabric サーバーボックス。 インストールするだけです NCache XNUMX つまたは XNUMX つのボックスに、その後 XNUMX 回 NCache インストールが完了すると、Web 管理プロセスを開始して、キャッシュ クラスターを構成できます。

ので、私は持っています NCache ここでは XNUMX つのボックスにインストールされており、キャッシュ クラスター サーバーとして使用します。 したがって、クラスター化キャッシュにアクセスするだけで済みます。 ちなみに、クラスター化キャッシュ、ローカル キャッシュ、クラスター化キャッシュを作成できます。 IP アドレス自体からアクセスできます。

そこで、「新規」をクリックして、たとえば「democache」という名前を付けます。 何でも名前を付けることができます。 NCache はバイナリおよび JSON シリアル化に基づいているため、これらの形式のいずれかを選択できます。 ここでは「バイナリ」を選択し、「次へ」を選択します。

ご存知のように、 NCache たくさんあります キャッシングトポロジ ぜひご確認ください。 NCache アーキテクチャ ウェビナーでは、これらすべてのトポロジーを詳細に説明します。

そう、 レプリカトポロジのパーティション化, これについて簡単に概要を説明しなければならない場合、それはバックアップされたパーティションに基づいています。 これがレプリカのパーティション トポロジです。 各サーバーには、クライアントが接続されるデータのパーティションがあります。 したがって、サーバー 1 と 2 はアクティブなパーティションをホストします。 項目番号 1、2 はサーバー 1 にあり、項目番号 3 と 4 はサーバー 2 にあり、サーバー 1 には 2 にバックアップがあり、サーバー 2 にはサーバー 1 にバックアップがあるバックアップ パーティションもあります。

そのため、サーバーがダウンした場合でもバックアップが有効になり、データが失われることはありません。 したがって、各サーバーはキャッシュ クラスター内の他のサーバー上にバックアップされ、このセットアップでは必要な数のサーバーを持つことができます。同様に、他のトポロジもあります。これらについては、「 建築ウェビナー。 したがって、Replica の Partitioned を選択することにします。 すべてをシンプルにしてください。

アクティブなパーティションと他のサーバー上のそのバックアップの間のレプリケーションのモードは、同期または非同期です。 高速なため、Async を使用することにします。 同期は信頼性が高くなりますが、非同期も非常に高速です。

そして、ここでキャッシュ クラスターをホストするサーバーを指定します。 つまり、ボックス 107 と 108 が XNUMX つあります。

サーバー ノードとエビクション間の通信用のキャッシュ、TCP/IP ベースのパラメータをオンにできるかどうかを確認してみましょう。 ここでキャッシュ サイズを指定したためです。 この画面では、キャッシュのサイズも指定します。 したがって、キャッシュがいっぱいになった場合にエビクションを実行することを選択することもできます。 したがって、その場合、キャッシュは古い項目をいくつか削除し、新しい項目のためのスペースを空けることができます。

使用している場合 NCache セッション キャッシュの場合、からの移行として AppFabric 〜へ NCache, AppFabric セッションストアモジュール NCache セッション ストア モジュールでは、エビクションをオフにすることをお勧めします。これはユーザー データであり、機密データでもあるためです。オブジェクト キャッシュ API を使用している場合でも、データを失う余裕がある場合にのみエビクションをオンにできます。いっぱいになります。 したがって、この問題を軽減するために、いつでもより大きなキャッシュ サイズを指定することもできます。 終了時にこのキャッシュを開始します。 サービスの起動時にこのキャッシュを自動的に開始します。 したがって、サーバーが再起動するたびに、サーバーは自動的にキャッシュ クラスターに再参加するため、ダウンタイムやデータ損失は発生しません。 クラスターは、すべてのメンバーが稼働していれば完全に機能するため、再起動時に自動的に再参加します。 手動で行うべきではありません。それだけです。

キャッシュ クラスターを構成するのはとても簡単です。 ご覧のとおり、107 と 108 があり、democache は完全に稼働しています。

キャッシュ統計の監視

ここでいくつかの統計をお見せします。 これらは Windows パフォーマンス カウンターです。 したがって、Windows パフォーマンス モニターを介した Windows 統合監視システムを使用するのは、これも非常に自然な選択です。

また、独自の監視ツールも利用できます。これは、Windows パフォーマンス カウンターといくつかの監視パラメーターを利用しています。 NCache 応用。 クライアント接続の数、使用率、キャッシュ ホスト内の統計など。 したがって、クラスター、リクエスト/秒、平均マイクロ秒/キャッシュを表示して、レイテンシ、追加、フェッチ、更新、削除/秒のキャッシュ サイズ、CPU グラフ、メモリ グラフ、キャッシュ内の合計データ数、CPU 時間を表示しました。によって費やされました NCache、ここにシステムメモリ、そして接続されているクライアントプロセスも含まれます。

したがって、これは非常に精巧であり、その上にクライアント ダッシュボード、サーバーとクライアントのレポート ビューがあり、独自のダッシュボードを追加することもできます。 たとえば、新しいダッシュボードを作成する場合は、「Api Logs」という名前を付ける必要があります。そのまま作成して、ここからカウンターをドラッグ アンド ドロップできます。

たとえば、クラスター操作や XNUMX 秒あたりの追加数を確認できます。 したがって、特に監視するために必要なカウンターを追加するだけです NCache 集まる。 したがって、現時点ではクライアント アプリケーションが実行されていないので、すぐにクライアント アプリケーションを実行します。そのために、test-stress democache とだけ言うつもりです。 そのため、このアプリケーションを初めて実行すると、しばらく時間がかかります。 このボックスの PowerShell ウィンドウはわずかに遅れますが、これが実行されるとすぐに、キャッシュ上でダミーのアクティビティがシミュレートされ、XNUMX 秒あたりのリクエスト数が表示されることがわかります。

これをここに持ってくると、キャッシュ操作あたりの平均マイクロ秒が 100 操作あたり 5 マイクロ秒弱で、4 秒あたりの追加、フェッチ、更新がかなり混合して発生しているとします。 キャッシュ サイズは増加しており、数メガバイトになっています。 平均すると、オブジェクトのサイズはわずか XNUMX キロバイトです。 CPU は XNUMX% 未満、現時点では XNUMX% です。 メモリは追加するもので、すべてのカウンターのセットがアクティビティを示していることがわかります。

ここにもクライアント プロセスが表示されており、クライアント ダッシュボードを表示すると、これらすべてのレポートも表示されます。

したがって、これはセットアップがいかに簡単かを説明するためのものです。 これはテストの XNUMX つですので、すでに持っている場合は、 AppFabric サーバー、あなたがする必要があるのは、 ダウンロード NCache 当社の Web サイトからソフトウェアをダウンロードする場合は、同じサーバーにインストールしてください。 高可用性とデータの信頼性を確保するには、XNUMX 台のサーバーが推奨される最小要件です。 テスト目的で XNUMX 台のサーバーから開始することもできますが、運用環境では少なくとも XNUMX 台のサーバーを使用することをお勧めします。それが完了したら、アプリケーションに移動して同じキャッシュ クラスターの使用を開始できます。

そして、インストール後、明らかにキャッシュ クラスターも作成する必要があります。これは先ほど実行したものです。その後、アプリケーションの使用を開始し、アプリケーションにアクセスして使用を開始できます。 NCache 移行オプションとして、サンプル アプリケーションを使用して説明します。

サンプルの実行 AppFabric 申し込み

そこで、このサンプルアプリケーションを用意しました。 実際のところ、これはサンプル アプリケーションと同じであり、ネイティブ AppFabric コンソール UI と、これから変換した XNUMX 番目のもの NCache AppFabric コンソールUI。 したがって、これら XNUMX つを開くと、これらはまったく同じアプリケーションですが、互換性を持たせるために小さな変更が加えられています。 NCache。 それでは、これらの変更について説明します。 これの別のコピーがありますので、それを説明します。 これをスタートアップ プロジェクトとして設定しました。これを実行する予定です。ところで、これを実行する前に、 AppFabric ここでもサーバーが稼働しています。 それで、私たちは、 AppFabric サーバ。 現在の統計をお見せすると、いくつかあります。これを再起動させてください。これが再起動されている間に、ここに戻ってきます。これは典型的なものを使用しています。 AppFabricご存知のとおり、データ キャッシュ呼び出しです。 ここから、Program.cs を見せてみましょう。

質問はありますか？ あなたのやり方でXNUMXつ投げたかったのです。 はい。 スライド XNUMX に戻って、出席者の XNUMX 人が、キャッシュ クラスターは Windows と Linux で実行されていると述べましたが、サーバーは Linux でホストできるのか、また、ホストできる場合、ダッシュボード機能はどのように機能するのか、と述べました。

とても良い質問です。 これは ウェブベースの管理ツール、ASPで実装されています.NET Coreそうです、Linux 環境でも利用できるすべてのツールが含まれています。 それで、もしあなたの場合、 NCache サーバーは Linux でホストされています。 まず、Linux の一部である Web 管理に引き続きアクセスできます。 環境内の任意の Windows ボックスまたはブラウザからアクセスできます。また、Linux 監視については、Linux には PerfMon カウンターがまだありません。

　 .NET Core はまだ進化しているため、PerfMon カウンターはまだ存在しません。 そこで、Linux 環境用のカスタム カウンターを用意しました。 Linux サーバー監視についても、ほぼ同様のビューが得られます。 NCache。 したがって、唯一の違いは、Windows ではなく Linux ボックスであることと、 .NET Core これらの Linux ボックスにインストールします。

したがって、ビューは同じになります。 限界を克服するために、私たちは別の道を選んだだけです .NET Core。 PerfMon カウンターは存在しないため、その特定の使用例に合わせてカスタム監視を実装しました。 それがあなたの質問の答えになることを願っています。

それでは、これをクリアして現在のステータスを示しましょう。 したがって、これは同じ名前の「デモキャッシュ」です。同じ名前のキャッシュを次のように使用することもできます。 NCache 同じように。 キャッシュの名前を変更する必要さえありません。 それが私たちがこれを設計した方法です。 そうですね、では、このキャッシュの統計をお見せしましょう。 したがって、現時点では何もありません AppFabric キャッシュクラスター。 ということで、このアプリケーションを起動してみます。

したがって、ここでの私の目標は、アプリケーションを実行することです AppFabric、それが機能することを示してから、これを移行し、これをに移行します NCache そして使用をやめる AppFabric そして使用を開始 NCache。 ということで、これを実行してみます。

わかった。 これは、私が設計した個人的なテスト ケース、サンプル アプリケーションです。 すべての API、おそらくはすべての API を通過します。 AppFabric。 この時点で多くの API が実行されているのが見られるのはそのためです。 それで、これを実行します AppFabric 次に、同じサンプルを実行します。ちなみに、通知テストも行われます。 それで、これが行われている間、ここにドッキングしてから、これをここに持ってきてください。 実際に、ここでこのサンプルを開いてみましょう。 さて、基本的には同じサンプル アプリケーションですが、悪いです。 わかった。 それで、これは、ご存知のとおり、 AppFabric このサンプルにはいくつかの追加が加えられているので、統計を示します。 アイテム数は 48、リージョン数は 60、リクエスト数は 154 になります。

したがって、たくさんのパラメータがあり、キャッシュ内のキーを表示すると、キャッシュ内のいくつかの統計を見ることができます。 ということで、いくつかのアイテムが入っています。 XNUMX つはプライマリで、現時点ではサーバーが XNUMX つしかありませんが、キャッシュにもリージョンが追加されています。

これは完全に動作するサンプル アプリケーションなので、同じサンプルを実行してから、作成方法と、変更を加えた方法を示します。 それで、私はこのサンプルに行きます。これは、私たちが実行した最初のサンプルのコピーです。 AppFabric 装備するために変更を加えました NCache。 新しいインスタンスを開始すると、ここで実行されるはずです。 同じサンプルが次のように実行されていることがわかります。 NCache すべての変更については後ほどお見せします。

したがって、並べて比較することは、サンプル XNUMX から何を期待しているかを理解するのに非常に役立ちます。 AppFabric そして私たちが得ているもの NCache はまったく同じになるので、これを実現するためにコードを変更する必要はありません。 これまでに行ったすべての手順を説明します。 ということで、ほぼ完成です。 それでは、一番上まで来させていただきます。 ちなみにまだ走ってます。 つまり、黄色のマーカーは基本的に私たちが実行しているタスクであることがわかります。それが完了すると緑色で表示され、サーバー側でエラーが発生した場合は濃い赤色で表示されます。 、クライアント側の解析側の場合は、右に明るい赤、次に暗い赤になります。 そこで、色分けしたビューを示しました。 したがって、エラー コードや発生した可能性のある例外を含め、すべての出力がまったく同じであることがわかります。 したがって、ここから開始して、キー値を追加し、存在しないキーを追加すると、同じ出力になります。 それで、テストにアイテムを追加します。これも同じ出力です。アイテムを取得します。アイテム XNUMX は、ご存知のとおり、これも成功ですが、エラーです。 したがって、並べて表示すると、これは次のものと正確に一致しています。 NCache、 右。

それで、最後にいくつかのイベントを紹介します。 つまり、リージョンも使用しているのですね。 したがって、ここでリージョンを使用すると、同じ出力が表示されます。 NCache 同じように。 したがって、領域のクリア、領域の追加、領域の削除のテストは、実際には想定どおりに実行されます。 これは、私たちがこれを達成できたことを簡単に示したものです。

どのような手順が含まれるのかを説明しましょう。 さて、これでこれを終了します。ところで、すべてのモニタリングが完了しました。これを示す必要がありましたが、実行した手順だけを示しておきます。 これまでに行ったことは、NuGet パッケージを追加したことだけです。これについては、実際にステップごとに説明していきます。 したがって、実際に行う必要があるのは、これが App Fabric コンソール UI であることです。 それで、それは使用しています AppFabric 現時点では。

したがって、最初に行う必要があるのは、NuGet パッケージを追加することです。 NuGet パッケージを管理すると、インストールされている NuGet パッケージを確認したり、参照していくつかのパッケージを確認したりできます。 AppFabric NCache。 これをクリックすると、これをインストールします。 それが私たちの最初のステップです。

したがって、コード変更オプションなしで移行オプション内でここに戻ってきた場合、最初に行う必要があるのは、NuGet パッケージを導入することです。 AppFabricラッパー。NCache 次のステップは、次のステップです。 Microsoft.ApplicationServer.Caching; 名前空間と Alachisoft.NCache.データ.キャッシュ; これはラッパーアセンブリです。 NCache その時点からすべての通話を担当します。

あなたの目の前でこれをやらせてください。 これがサンプルです。これはネイティブです AppFabric サンプル。 NuGet がインストールされています。 それはまだ行われています。

簡単な質問ですが、これについて質問させていただきます。 質問は、タグによるアイテムの取得はラッパーでサポートされているということでした。

はい。 ご存知のように、 AppFabric リージョンがありますね。 したがって、次の範囲内のリージョンを使用している場合、 AppFabricしたがって、タグを使用してから、それをサポートするためにグループを使用しますが、使用したい場合は、 NCache タグ、そうですね。 したがって、キャッシュの使用を拡張したいと考えており、それはウェビナー内のトピックでもあります。その場合は、API を直接使用できます。 したがって、リージョンを通じてすでに持っているものをサポートするには、ラッパーを使用します。タグは舞台裏で使用されます。その後、特に提供されているタグを使用したい場合は、 NCache, NCache API。 したがって、直接使用できます NCache APIも同様です。 それでは、あなたの質問に答えていただければ幸いです。

それでは、これを XNUMX つずつ見ていきます。ここではこのスライドを使用するだけです。 Alachisoft.NCache.データ.キャッシュ; そうです、それがここでのアイデアです。 そこで、これを実行してキャッシュを追加します。 の参照はありません AppFabric しかし、これは持っています。 したがって、必要なのは、この名前空間を含めることだけです Alachisoft.NCache.データ.キャッシュ; 以上です。

したがって、NuGet パッケージはここに大量のリソースを追加しました NCacheご存知のとおり、ラッパーである Data.Caching と、 NCache 定期的な集会、これらすべてが必要なものです。 NuGet が追加しています NCache クライアント リソースをアプリケーションに取り込んでから、XNUMX つずつ実行して、これを置き換え始めます。

ここに戻ってきて、これをコピーして、どこにでも見つけられるようにしましょう AppFabric 参照、たとえばここでは、次のように置き換えます。 NCache それがいかに簡単かわかるように、私はあなたの前でこれをやっています。 それで、私たちは続けます。 ごめんなさい、使い方が悪くて Alachisoft.NCache.データ.キャッシュ; そしてこれを繰り返しましょう。 タイプミスがあったので、それも削除したと思います。 わかった。 ということで、他のテストに移ります。 これで大丈夫です。 領域をクリアしても問題ありませんし、領域を作成しても問題ありません。 したがって、すべての領域テストでは直接参照は使用されませんが、タグ テストが行​​われます。 ということで、このサンプルもGitHubに投稿しておきます。 ちなみに、NuGet はすでに公開されており、最新のサービス パック情報が含まれていますが、これについては に投稿します。 それで、すべて完了できれば幸いです。 これを再構築しましょう。 間違いがある場合は、具体的に対処します。 それで、私はこれで考えます。 わかった。 それでは、正しいラッパーを使用していることを検証してみましょう。

わかった。 これを完了したら、いくつか見逃していると思いますが、これを完了したら、ここに戻ってクライアント側の接続設定を追加する必要があります。 たとえば、私の場合は、ここのボックス 101 です。これは私自身のボックスであり、設定にはキャッシュの名前が必要です。

たとえば、「democache」がありました。 したがって、ここではローカル キャッシュを使用したローカル テストを紹介しますが、いつでもリモート キャッシュを使用することもできます。 たとえば、そのためにここでこのキャッシュを使用できます。 私のボックスをクライアントとして追加しましょう。そうして、これを追加します。私のボックスにはクライアント ノードがあります。たとえば、101 はクライアント マシンです。

わかった。 これですべての設定が完了しました。 したがって、client.nc conf を使用することも、ここからクライアント ボックスとして 107 を指定することもできます。

右。 したがって、これは別のことですが、アプリの構成はキャッシュの名前を指す必要があります。 したがって、ここで何も変更するつもりはありません。 次に、実際のキャッシュを使用してこのサンプルを実行してみましょう。 うまく建てられました。 後はそれを実行するだけです。 完了したらすぐにスタートアッププロジェクトとして作成するつもりです。 プロジェクトを開始して、実行してみましょう。

したがって、基本的には XNUMX つのステップからなるプロセスです。 NuGet を含めることができます。 AppFabric ライブラリ、ApplicationServer.Caching と Alachisoft. NCache.データ.キャッシュ。 アプリケーションを再構築します。 エラーがないことを確認してください。 最新の NuGet パッケージを使用し、選択したサーバーを指すように client.nc conf を更新します。この場合、サーバーから追加される client.nc conf ファイルがあります。 これでクラスターが構成されました。 そのサーバーを指して、今ここに戻ってきたら、これを監視してストレス テスト ツールを閉じさせてください。 右。 したがって、アプリケーション自体から統計を表示する必要があります。

一般に、これがラッパー アプローチから移行して使用する方法のライフ サイクルです。

直接 NCache API呼び出し

直接 API 呼び出しの使用法も示しておきます。 さて、XNUMX 番目のアプローチでも質問がありましたが、これを使用するとどうなるかという質問がありました。 NCache タグまたは NCache 特徴？ そのため、多くの高度な機能を利用できます。 したがって、直接作ることができます NCache API 呼び出し AppFabric 応用。 したがって、そのためには、ヘルプ ドキュメントをガイドとして使用することをお勧めします。これは、直接 API です。 それで、あなたがしなければならないのは、 ICache キャッシュ = CacheManager.GetCache キャッシュハンドルを取得して使用を開始します NCache API を使用する必要があるのは、SDK を使用することだけです。また、これらすべてを手持ちの汎用アプリケーションに追加できるサンプル アプリケーションが用意されています。

したがって、ラッパーアプローチを使用するアプリケーションでもその使用法を拡張でき、使用し始めることができます。 NCache API も後の段階で。

それで、サンプルを開いたら、お見せします NCache サンプル。 Basic Operations は、仕事を完了させる非常に単純なサンプル アプリケーションです。 以上で、基本的な動作サンプルが完成しました。 非常にシンプルなアプローチと基本的な操作を備えているため、追加するだけで済みます。 Alachisoft.NCache。クライアント としょうかん。

したがって、先ほども言いましたが、これを参照として、どこにでも使用できます。 AppFabricたとえば、Bulk Get Tests を開いた場合、この名前空間をここに含めることができます。その中に、実際に必要なフォームに実際に取り込むことができます。 それでは、ご容赦ください。 サンプルでは何も変更したくないので、どこに追加すればよいか調べてみましょう。 そうですね、ただ使っているだけだと思います AppFabric その上にラッパーテスト。 なので、基本的な動作サンプルはこのままでいいと思います。 右。 したがって、これは ICache クラスのキャッシュであり、オブジェクトである Create New Customer を使用できます。次に、実装であるカスタム実装であるキャッシュにオブジェクトを追加と言うことができますが、これが使用方法です。 NCache API。

キャッシュ項目を構築してから呼び出すことができます キャッシュ追加 そしてこれは NCacheご存知のとおり、API Alachisoft キャッシュオブジェクト。 それで、それは Alachisoft.NCache.Client.Iキャッシュ.

したがって、キャッシュハンドルを返し、使用できるようにします NCache その上に API があります。 したがって、先ほど述べたように、ラッパーを介した移行から始めて、その上で拡張 API を使用することができます。その後、利用可能なドキュメント リソースが多数あります。 AppFabric API の外観と仕組み NCache API。 したがって、本当に使用をやめたい場合は、 AppFabric そして使用を開始 NCache API では、最初から開始してこのアプローチを使用することも、ラッパーを使用して簡単に移行し、その上に を使用して拡張するサイドバイサイド アプローチを使用することもできます。 NCache API。

ASP.NET キャッシュ NCache

これはすでに実行済みです。 それで ASP.NETセッションキャッシング、Web 構成の変更を指定できるようにプロバイダーを変更するだけです。 NCache セッションストレージおよび出力として指定することができます NCache 出力キャッシュプロバイダーとして。 この点については、詳細なヘルプ ドキュメントも用意されています。 たとえば、次のように言う場合 NCache セッション キャッシュ。セッション状態プロバイダーを指します。同様に、出力キャッシュも探すことができます。 そうです、これは Web 設定内で変更する必要があるものです。

<configuration>
  ...
  <sessionState cookieless="false"
                regenerateExpiredSessionId="true"
                mode="Custom"
                customProvider="NCacheSessionProvider"
                timeout="20">
    <providers>
      <add name="NCacheSessionProvider"
          type="Alachisoft.NCache.Web.SessionState.NSessionStoreProvider"
           cacheName="demoClusteredCache"
           sessionAppId="demoApp"
           exceptionsEnabled="true"
           writeExceptionsToEventLog="false"
           enableLogs="false"
           enableSessionLocking="true"
           sessionLockingRetry="-1"
           emptySessionWhenLocked="false" />       
    </providers>

  </sessionState>
...
</configuration>

ここにある出力キャッシュについても同様です。 したがって、プロバイダーの概要を説明すると、これは、App Fabric の出力キャッシュを高めるためにアプリケーション内に追加する必要があるものです。 NCache 出力キャッシュ。

<!-- caching section group -->
<caching>
  <outputCache defaultProvider ="NOutputCacheProvider">
    <providers>
    <add name="NOutputCacheProvider" 
         type= "Alachisoft.NCache.OutputCacheProvider.NOutputCacheProvider, Alachisoft.NCache.OutputCacheProvider, 
         Version=x.x.x.x, Culture=neutral, PublicKeyToken=cff5926ed6a53769" 
         cacheName="demoClusteredCache" 
         exceptionsEnabled="false"enableDetailLogs="false" 
         enableLogs="true" 
         writeExceptionsToEventLog="false"/>"
    </providers>
  </outputCache>
</caching>

そして、左側にリストが表示されます NCache は巨大。 マルチサイトセッション サポートされており、 ビューステート プロバイダーはサポートされていますが、次のプロバイダーにはありません AppFabric. 出力キャッシュ カスタムフックを使用することは、 NCache。 同様に、私たちも SignalR Backplane, ASP.NET Core 応答キャッシング, ASP.NET Core SignalR Backplane。 したがって、このリストは非常に広範囲にわたるものです。なぜなら、私たちは以前の機能セットと比較して積極的に機能セットを更新しているからです。 AppFabric.

WANレプリケーション

そして、一般的には、ご存知のとおり、 NCache と比較して、100% ピアツーピア アーキテクチャです。 AppFabric。 多くのキャッシュ トポロジを比較して確認できます。 WANレプリケーションが利用可能です。 マルチ データセンターのサポートが利用可能です。 NCache、アクティブ-パッシブ、アクティブ-アクティブ、または 3 つ以上のアクティブ-アクティブ データセンターが利用可能です。

私たちには膨大な数の顧客がおり、それをバックアップするためにすでに議論しました。 NCache Windows および .NET 環境に積極的に展開されています。 これで、今日のセッションはほぼ終了すると思います。 ご質問がございましたらお知らせください。

それで、ロン、ここで一つ質問があります。 質問は私たちの文書に記載されています AppFabric 私たちが持っているキャッシュクライアントラッパー。 すべてのクラスター ノード、ポート、タイムアウト設定などは、app.config ではなく API 経由で提供されます。 ラッパーを使用することで、API 経由と構成経由で同じものを提供できるでしょうか?

はい、できます。一般的にはインライン パラメーターもあります。 したがって、ラッパーは、最小限のコード変更と構成変更でキャッシュに接続できるように設計されています。 なるほど、そういう風に設計されているんですね。 したがって、移行が非常に簡単なオプションであるように見せたいと思ったのはこのためです。 したがって、構成レベルの変更のみを示しましたが、インラインで何かを提供したい場合は、init params を用意しています。 したがって、サーバー、サーバー 1、サーバー 2、サーバー 3 のポートのリストを提供できる初期化パラメータがあります。 client.ncconf の一部として見てきたクライアント側の設定はすべて、ここで開いてみましょう。 つまり、これらは、アプリケーション コード内でも指定できる構成設定です。 したがって、その可能性はあります。

そこで、参加者の XNUMX 人がパフォーマンス情報について質問しています。 帯域幅など。

NCache 非常にスケーラブルであり、アプリケーションに 100% の線形スケーラビリティを実現する機能を備えています。 したがって、サーバーをどんどん追加すると、リクエストの処理能力が増加するだけです。 したがって、汎用的なアイデアが必要な場合は、ベンチマークを確認することを強くお勧めします。 これをお見せしましょう。 当社では、ベンチマークを公開しています。ご存知のとおり、5 秒あたりのスループット操作数はわずか XNUMX です。 NCache サーバーでは、2 秒あたり 5 万リクエストを達成することができました。 そうです、それはあなたがレビューできるものであり、ここからも同様に見ることができます。私たちは XNUMX を使用しただけです。 NCache サーバー。 あります デモンストレーション これも。 したがって、これを確認したい場合は、 ホワイトペーパー このテストのビデオ ライブ デモンストレーションでは、2 台のサーバーで開始し、その後、ある程度のスループットとリクエスト処理能力を達成することができ、さらに負荷をかけてサーバーの数を増やすことができました。 わずか 5 ノードのクラスターで、2 秒あたり XNUMX 万回のオペレーションを達成することができました。

したがって、サーバー リソースに関する限り、ご質問が必要な帯域幅またはサーバー リソースに焦点を当てているのであれば、これらは AWS サーバー、かなりハイエンドのサーバーでした。なぜなら、私たちは実際に、お客様が必要とする容量やストレッチを実証したかったからです。で達成できます NCache。 そのため、サーバーを制限まで拡張することができ、2 秒あたり 8 万リクエストを取得することができました。 ただし、1 ギガ以上のメモリ要件を持つ 16 ギガビット ネットワーク インターフェイス カードを使用して、最大 8 コアの Web サーバー構成を使用することもできます。 したがって、16 ギガでも問題ありませんが、XNUMX ギガをお勧めします。 したがって、データをホストするのに十分なメモリが必要です。

なぜですか NCache より良い解決策 Redis?

基本的に、上位 XNUMX つの理由を挙げるとすれば、まず .NET と非ネイティブ .NET です。 Redis Windowsとの互換性があまりありません。 サードパーティである Microsoft Open Tech によってサポートされている移植バージョンがあります。 Redis 研究室や Redis オープンソース自体は、使用しないことを推奨しています Redis Windows プラットフォーム上で。 したがって、比較すると、 AppFabric NCache の方が適しています。 主に、同じスタック上にあるため、 AppFabric & Redis そうではありません。 Redis 一般に、Linux ベースの製品に近いです。 一方 NCache Windows および Linux ベースの製品です。

高可用性に関する多くの問題があります Redis. Redis クラスターは 100% ピアツーピア アーキテクチャではありません。 NCache. NCache は完全にピアツーピア アーキテクチャのキャッシュ クラスターであり、任意のサーバーをオフラインにすることができます。 接続されているキャッシュ クライアントには影響せず、データの損失も発生しません。 それから、多くの機能が欠けています Redis。 クライアントキャッシュなどはありません。 最近導入されましたが、非常に基本的なものです。 2008 年からクライアント キャッシュを導入していますね。 したがって、これは非常に古い機能ですが、次の機能の一部として非常に強化されました。 NCache。 ブリッジ、サーバーサイド コード SQL のような検索、リードスルー、ライトスルー ハンドラー、キャッシュ ローダー、これらの機能はすべて、 Redis 比較資料をすぐにご覧いただきたいのですが、この資料は弊社のウェブサイトで公開されています。 比較ページ。 それで、ご覧のとおり Azure Redis vs NCache, Redis vs NCache 相違点の概要, Redis vs NCache （スライドデッキ） それから、いくつかの一般的な情報があります。 NCache.

それでは、これを簡単にお見せして、ご質問があればお知らせください。 これに登録しているので、サインインしましょう。はい。 それに関するフォローアップの質問は、非同期レプリケーションに関する質問でした。

非同期レプリケーションの動作が安全であると想定できますか? それは保証されていますか?

それは、それは…、だから、ご存知のとおりです。 非常にまれなシナリオですが、途中で失敗した場合、その更新は失われる可能性がありますが、更新は非常に高速です。 専用のスレッドがあります。 図をお見せして、最初の質問に戻りましょう。 そこで、まずこの質問に取り組みましょう。 つまり、サーバー 1 のアクティブなパーティションです。アプリケーションがここに何かを追加するとすぐに返されます。 NCache バックアップ内の更新を担当しており、非同期オプションと同期オプションがあります。

したがって、非同期は非常に高速です。 ミリ秒未満の範囲内で、サーバー 1 で呼び出しがトリガーされ、複製中にこのサーバーがダウンして更新を取得できないというシナリオを再現していただければ幸いです。 それは非常にまれなシナリオです NCache。 弊社の QA チームですら、これを再現しようと懸命に取り組んでいますが、再現することはできません。 したがって、ミリ秒未満のわずかな遅延で専用スレッドがバックアップを更新し、そのサーバーがダウンしている間、更新が失われる可能性がわずかにありますが、前述したように、これが再現されるのは非常にまれなシナリオであり、同期オプションがあります。この状況に対応するためにも利用できます。 バックアップを常に更新する必要があることが非常に心配な場合は、クライアントがアクティブとバックアップを一度に更新する同期更新を使用できます。 それはトランザクション操作です。 途中で失敗した場合は、操作全体がロールバックされます。 したがって、あなたの質問がそれに焦点を当てている場合、それは非常に安全です。

それで、話に戻りますが、 Redis、 これは Azure Redis vs NCache。 したがって、機能レベルの比較と、Azure が含まれるリストを確認できます。 Redis 役割は部分的であり、これらすべての面でのサポートは限られています。 したがって、高可用性は部分的にサポートされていますが、キャッシュ トポロジは制限されています。 WANレプリケーション 非常に限られており、 ASP.NETキャッシュ 特徴、 オブジェクトのキャッシュ 特徴、 同期 機能が完全に欠落している Redis そしてあなたが使用している場合 NCache オブジェクトのキャッシュの場合、これらの同期機能を利用できることは非常に意味があります。

SQL のような検索 不足している、 データのグループ化 が欠落しており、サーバー側のコードが完全に欠落しており、それは .NET ですらありません。 Redis .NET で書かれていません。 リストはさらに続きます。

質問は次のとおりです。つまり、私は知っています NCache Windows ネイティブであり、Linux と比較される Redis の方が良いですが、どうすればよいですか NCache Linux 上での比較 Redis Linuxでは？

同じ機能セット、同じサポートがサポートされています。 .NET Core Linux で利用可能です。 それで、 NCache つまり、Windows 製品だけではありません。 Redis。 どこで Redis 主に Linux 指向の製品です。 NCache WindowsとLinuxです。 したがって、ここで表示されている機能セットはすべて、Linux 環境で完全にサポートされています。 全ての .NET Core Windows 上のすべてのリリースと同様に、すべての Linux は互いに同等です。 Linux が抱える PerfMon カウンターの問題に対応するためのカスタム モニタリングが用意されていますが、それ以外、表示されているすべての機能セット、この比較はほぼ有効であり、すべてが Linux 環境でも同様に有効です。 私は Windows に重点を置いています。 Redis 一般的に、Windows サポートが完全に欠如しています。 しかし、これまでのところ、 NCache 懸念されるのは、当社の Windows 製品と Linux 製品はまったく同じです。 つまり、私たちが議論し、議論してきたすべての機能は、 NCache Linux 環境でも明らかに勝者であり、実際、新しい導入環境ではより多くの顧客が採用しています。 .NET Core アプリケーション内で好んで使用するのは、 NCache Linux環境の場合。 なぜなら、ライセンスの観点やオープンソースの観点から見ると、Linux は比較するとかなり互換性があり、使いやすいからです。 それで、私たちの NCache Linux サーバー上にあるサーバー、 .NET Core 最近では非常に一般的な方法です。

Docker サポートはありますか?

はい、もちろん承ります。 どうしてそれができないのですか Docker サポート NCache。 ダウンロード ページにアクセスすると、Docker に関するセクションが見つかります。 我々は持っています .NET Core Docker イメージは Linux 上で利用可能であり、 .NET Framework Windows と、両方で使用できる Docker ファイルも用意されています。 したがって、エンタープライズ、プロフェッショナル、オープンソースの場合は、私たちのものを使用できます。ちなみに、私たちは意図的に保持しています .NET Core Linux 専用のイメージです。Linux の方が一般的であり、実際のところ、Linux 用のイメージを使用できます。 Dockerイメージ あらゆる Kubernetes プラットフォームでも同様です。 そのような OpenShift、 といった Azure Kubernetesサービス, ElasticKubernetesサービス AWS や Google Kubernetes Service でも提供されています。 ですから、それは非常に一般的です。 アプリケーションのデプロイメントでは非常に人気があります。 したがって、これは当社の Web サイトから直接ダウンロードするか、 Dockerハブ そのことについては。

それがあなたの質問の答えである場合は、確認してください。 さらに質問がある場合はお知らせください。 他のもの？ 今すぐすべての質問を受け取ることができない場合でも、すでにたくさんの質問が届いていると思いますが、いつでもメールでお問い合わせください。 support@alachisoft.com。 技術的な質問や機能に関する質問がある場合は、メールでお問い合わせください。 support@alachisoft.com。 当社のサポートチームは、お客様のあらゆるご質問、ご意見、ユースケースの質問などにお答えします。

そして、取得に興味がある場合は、 NCache 始めました。XNUMX か月の無料期間があります NCache Enterprise 無料トライアルをダウンロードして、お使いの環境で使用できます。ご希望の場合は、次のいずれかまでお問い合わせください。 support@alachisoft.com or sales@alachisoft.com。 私たちはセットアップをお手伝いし、どのようなユースケースに取り組んでいるのかについてもお知らせします。 どのような機能に興味がありますか? 技術面でも必ずご満足いただけるよう努めます。

質問もありましたが、プレゼンテーションのスライドを入手できますか?

確かに、このウェビナーの録画は公開されるだけではなく、メールでお知らせすることを期待してください。また、特にスライドも公開することができます。 スライドをご希望の場合、または他のスライドが必要な場合は、今すぐリクエストしてください。 全員がスライドを入手できるようにします。

ご質問がなければ、いつでもご連絡ください。 ダウンロード NCache Enterpriseまだ遊んでいない場合は、ぜひ遊んでみてください。 ご使用の環境にセットアップするためのサポートが必要な場合は、ぜひお問い合わせください。

次はどうする？

• NCache 詳細
• ダウンロード NCache
• パーソナライズされたLIVEデモをリクエストする