NCache アーキテクチャ
今日は、について話します NCache 建築。 NCache は、.NET および Java アプリケーション用のインメモリ分散ストアです。 非常に高速でスケーラブルです。 また、これを高トランザクション サーバー アプリケーションで使用して、アプリケーションのパフォーマンスとスケーラビリティを向上させることができます。
の一般的な使用法 NCache
分散キャッシュ
一般的な XNUMX つの方法 NCache 使用されている。 ナンバーワンは、 分散キャッシュ ここでは、アプリケーション データをキャッシュして、高価なデータベース トリップを削減します。そして XNUMX つ目は、 メッセージングとストリーム プラットホーム。 アーキテクチャについて説明する前に、これらの両方について簡単に説明します。
-
アプリのデータキャッシュ
したがって、分散キャッシュでは、アプリケーション データ キャッシュは、 NCache API は通常、アプリケーション データをキャッシュするだけなので、キャッシュはデータベースよりもはるかに高速であるため、頻繁にデータベースにアクセスする必要はありません。 また、メモリ内にあるためスケーラビリティが高く、高速です。 アプリケーションに近いため高速であり、分散されているためスケーラブルです。 また、.NET アプリケーションがあり、EF Core を使用している場合は、次のように使用できます。 NCache EF Core も使用でき、NHibernate と EF 6 も使用できます。 Java アプリケーションがある場合は、使用できます NCache Hibernate の XNUMX 番目のレベルのキャッシュとして。 Spring Cache として使用したり、JCache に対してプログラムしたりすることもできます。 -
Webアプリのキャッシュ
分散キャッシュの使用の XNUMX 番目の部分は、Web アプリケーションがある場合に、 のセッション NCache その後 NCache これらのセッションを複数のサーバーにレプリケートします。 NCache サーバーがダウンしてもデータは失われませんが、分散ストアであり、明らかに超高速であるため、これらのセッションは非常にスケーラブルです。 また、.NET、Java、Nodejs などのすべての言語で利用できるマルチサイト セッション機能もあります。セッションに加えて、たとえば、.NET 6、ASP などでも利用できます。.NET Core アプリケーションはそれらを保存できます 応答キャッシュイン NCache そして、彼らはまた、 NCache として SignalR 用バックプレーン。 SignalR は、Web アプリがイベントをクライアントに送信する必要があるライブ Web アプリケーション用です。 .NET 4.8 を使用している場合は、セッション状態を保存することもできます。 状態を表示, 出力キャッシュ、SignalR もあります。
NCache ミッションクリティカルなアプリ向け
早速お見せしましょう NCache のように見える。 ミッションクリティカルなアプリケーション向けの分散キャッシュとしての機能は次のとおりです。 私がミッション クリティカルという言葉を使用しているのは、ほとんどの場合、顧客がミッション クリティカルという言葉を使用していることがわかるからです。 NCache 顧客対応の非常に機密性の高いアプリケーションでは、それらはビジネスにとって非常に重要です。 それで、 NCache その場合、これは非常に重要なインフラストラクチャの一部です。
そして、前述したように、これらは高トランザクションのサーバー アプリケーションです。 これらは Web アプリケーションです。 これらは、マイクロサービス、Web API、またはその他のサーバー アプリケーションです。 明らかに、.NET、Java、Node.js、または Python を実行できます。 そして、これらのアプリケーションは、SQL Server、Oracle、Db2、MySQL、またはその他のリレーショナル データベースとしてデータベースにアクセスしようとしているか、レガシー メインフレーム データにアクセスしているか、あるいは NoSQL database Mongo DB、Cosmos DB、Cassandra など。 この状況では、 NCache …を使用することで分散キャッシュになります NCache XNUMX つ以上のサーバーを別個のキャッシュ層として使用します。別個のキャッシュ層を持つ必要はありませんが、アプリケーションは同じボックス内で実行できます。 NCache これはまったく問題なく動作しますが、より一般的なデプロイメント アーキテクチャは別個のキャッシュ層を持つことであり、これは単によりクリーンな使用方法です。 NCache.
たとえば、2 サーバーのキャッシュ クラスターから始めるとします。 NCache 集まる、 NCache これらすべてのサーバーのメモリ、CPU、ネットワーク カード リソースを XNUMX つの論理容量にプールし、アプリケーションを通じてより多くのトランザクション負荷をかけているとします。 NCache これら XNUMX つのサーバーは最大限に活用されており、XNUMX 台目のサーバー、XNUMX 台目のサーバー、XNUMX 台目のサーバーなどを簡単に追加できます。 NCache ボトルネックになることはありません。 これはデータベースではできないことです。 データベースは拡張できません。 NoSQL 拡張性はありますが、ほとんどの場合、さまざまなビジネス上の理由でリレーショナル データベースを使用する必要があり、レガシー メインフレームも使用していることがわかりました。 したがって、データストレージ層は拡張できないため、 NCache できる限り多くのデータをキャッシュできるようにすることで、アプリケーションの拡張を支援します。 一般的な目標は、約 80% の確率でデータを検索できるようにすることです。 NCache データベースにアクセスするのではなく、 この比率を達成できれば、データベースの負担が軽減され、アプリケーションがスケールできるようになります。
メッセージングとストリーム
XNUMX 番目の一般的な使用例、つまり NCache これをメッセージングおよびストリーム プラットフォームとして使用し、複数のアプリケーションが相互に通信できるようにすることです。 Pub / Subメッセージングを通じて、 連続クエリまたは NCache ベースのイベント。 それがどのようなものかお見せしましょう。 したがって、たとえば、大量のリアルタイム メッセージングやストリーム処理を行う必要がある高トランザクション サーバー アプリケーションがある場合は、次のように使用できます。 NCache。 今も同じ NCache それは分散キャッシュでしたが、今ではメッセージングとストリームのプラットフォームになっています。 繰り返しますが、これはインメモリ分散ストアです。 直線的にスケールします。 複数のサーバー間でメッセージを複製します。 実際には、 NCache 永続性も含まれています。
これにより、さまざまなアプリケーションを使用できるようになります。たとえば、Pub/Sub メッセージングは非常に一般的な方法であり、方法論であり、分離された方法で相互に通信できる複数のパブリッシャーと複数のサブスクライバーが存在するパラダイムです。 分離とは、パブリッシャーがサブスクライバーが誰であるかを知らず、特定のトピックにメッセージをパブリッシュするだけであり、これらのサブスクライバーはメッセージを取得できることを意味します。 継続的クエリも同様です。 つまり、これらが XNUMX つの一般的な方法です NCache 使用されている。
.NET と Java アプリケーションの比較
では、その方法について話しましょう NCache .NET アプリケーションと Java アプリケーションを処理します。 NCache には、非常に興味深いネイティブ マルチプラットフォーム機能が備わっています。これについて詳しく説明します。
.NET版
NCache .NET と Java の両方のネイティブ ソリューションを提供しようとします。 つまり、.NET アプリケーションがある場合、アプリケーション スタック全体で .NET が使用され、.NET 以外のものは何も使用されていないことになります。 したがって、たとえば、 NCache には、アプリケーションがアプリケーションで使用するネイティブ .NET クライアントがあります。 これはアプリケーションサーバー上で実行され、 NCache はこれを 100% 'C Sharp' (C#) で開発しました。
同様に、.NET で作成した、リードスルー、ライトスルー、ライトビハインド、ローダー/リフレッシャーなどのサーバー側コードがある場合、 NCache は、そのコードを独自の .NET CLR プロセスで実行します。 その方法を説明しましょう。 そして、この図に戻ってきます。 たとえば、次のようになります。 NCache このアーキテクチャには、Windows または Linux 上で実行できる .NET アプリケーションがあります。 ネイティブがあります NCache .NETクライアント。 そして、これはある人と話しています NCache .NET Edition であるクラスター NCache 集まる。 つまり、サーバー側のコードも .NET であるということになります。
さて、その方法 NCache これが、キャッシュ プロセスと管理プロセスが存在し、サーバー側のコード プロセスから分離されているため、マルチプラットフォーム ネイティブ サポートが非常に強力になる理由です。 そして、非常に高性能な RPC があります。 それはインメモリ RPC です。 NCache 使用します、それ NCache は、超高速な独自の RPC を開発しました。 これが、キャッシュがサーバー側のコードと通信する方法です。 したがって、たとえば、リードスルー ハンドラーを呼び出す必要がある場合、リードスルー ハンドラーはこの .NET CLR プロセス内で実行され、データベースにアクセスしてデータを取得し、それをキャッシュに渡します。 そして、同じことがライトスルー、ローダー、リフレッシャーにも当てはまります。 したがって、アプリケーションのエクスペリエンス全体が .NET になります。
Java版
さて、Java 側に切り替えましょう。 繰り返しますが、同様に、Java サーバー側コードが作成されます。 NCache は、アプリケーション サーバー上で .NET と同じように実行される 100% Java クライアントを備えています。 こちらはJava版です。 たとえば、Linux 上で実行される可能性が高い Java アプリケーションがあるとします。あるいは、Windows、Docker、Kubernetes 上で実行される可能性もあるとします。 したがって、そのアプリケーションには、 NCache Java クライアントは、ここで述べたように 100% ネイティブ Java であり、この Java クライアントは基本的に .NET クライアントと同一です。 それはまた、 NCache を使用して、.NET クライアントと同じ方法でクラスター化します。 NCache独自のソケット プロトコルと NCache サーバーは、サーバー側の Java コードが独自の JVM 上で実行されるように設計されています。
したがって、これから行う開発、テスト、デバッグはすべてネイティブ JVM プロセス内で行われます。 そして、このキャッシュ プロセスは、たとえば、Oracle や Db2、さらには SQL Server データベースにアクセスしてデータを取得し、キャッシュ プロセスに渡すリードスルー ハンドラーを呼び出します。 ここでも、同じ高性能のインメモリ RPC が使用されます。 したがって、.NET と Java コードを独自のネイティブ プロセスにカプセル化するアーキテクチャを採用することで、 NCache Java と .NET の両方のネイティブ スタックを提供できます。
また、Java アプリケーションの場合は、Windows または Mac OS で開発を行うことをお勧めします。 NCache 完全にサポートしている、あるいは Linux さえサポートしているので、.NET の人よりも Docker や Kubernetes を使用する可能性が高くなります。 NCache は Docker イメージを提供し、さらに Kubernetes、Azure AKS、AWS EKS、Google GKE、または Red Hat OpenShift の完全なサポートも提供します。 非常にシームレスに使用できます。
そう、 NCache とてもユニークです。 ネイティブの .NET エクスペリエンスと、同時にネイティブの Java エクスペリエンスを提供します。 したがって、Java ショップであれば、非 Java 製品を使用しているとは感じませんし、.NET ショップであれば、非 Java 製品を使用しているとは感じません。ネット製品。 それが美しさです NCache その設計方法。
動的クラスター
さて、それでは本題に入りましょう 動的クラスタリング の一部 NCache 高可用性を実現するアーキテクチャ。 そして、ちょっと待ってください。 最初の部分は動的クラスターです。 私がクラスターという言葉を使用するときは、Kubernetes クラスターやその他のオペレーティング システム レベルのクラスターを意味するものではありません。 これは NCache独自の TCP ベースのクラスター。 また、このクラスターにはピアツーピア アーキテクチャが採用されています。 ピアツーピアとは、マスターもスレーブも存在しないことを意味します。 マスター/スレーブの問題は、マスターがダウンするとスレーブが動作不能になるか制限されることですが、ピアツーピア アーキテクチャではすべてのノードが同等の能力を発揮します。 明らかにクラスター コーディネーター ノードが存在します。これが最も古いノードであり、そのノードがダウンすると、次に古いノードがクラスター コーディネーターとして自動的に選択されます。 クラスター コーディネーターはクラスターのメンバーシップを行います。 分散マップ、クラスターの健全性、その他多くのことを管理します。これについては後ほど説明します。
動的クラスタリングとは、キャッシュやアプリケーションを停止せずに、実行時にクラスターにサーバーを追加または削除できることを意味します。 中断はありません。 そして、たとえば、クラスターに新しいサーバーを追加すると、クラスターのメンバーシップが実行時に明らかに更新され、その実行時情報がクライアントに伝播されます。 それについては、次のスライドでもう少し詳しく説明します。
クラスター接続フェイルオーバー機能もあります。 したがって、これらはソケットであるため、クラスター サーバーは通常、互いにかなり近い同じサブネット内にありますが、常にそうであるとは限りません。 サーバーを別のリージョンに展開しているお客様もいらっしゃいますが、ほとんどの場合は、 NCache サーバーは互いにかなり近くにある必要があります。 ただし、接続障害が発生する可能性があります。 その場合は NCache 再試行ロジックがあり、タイムアウトがあります。 ハートビート ロジックがあり、すべてが動的であることを確認するためのものです。
動的クライアントと動的構成
動的クライアント接続
動的アーキテクチャのもう XNUMX つの部分は動的クライアントです。 したがって、このように、クラスターには実行時にサーバーを追加または削除する機能があり、実行時にクライアントを追加または削除する機能もあります。 クライアントとはどういう意味ですか? クライアントとは、 NCache アプリケーション サーバー、Web サーバー上で実行されるクライアント。アプリケーションが通信する部分です。 したがって、実行時にクライアントを追加でき、停止せずに実行時にクライアントを削除できます。 NCache、キャッシュ、またはアプリケーションを中断することなく実行できます。 それが最初の部分です。
動的構成
XNUMX 番目の部分は動的構成です。 したがって、最後のスライドで述べたように、クラスターにサーバーを追加すると、クラスターのメンバーシップが変更されます。 この情報は、接続されているすべての既存のクライアントに伝播され、接続する必要のある新しいサーバーがあることがわかります。 したがって、キャッシュ トポロジに基づいて選択した場合は、そのサーバーに接続することもできます。 さらに、トポロジーによっては、配布マップが存在する場合があります。 分散マップは、パーティション化されたキャッシュとパーティション化されたレプリカ キャッシュに適しています。 ただし、サーバーを追加すると更新され、実行時に反映されます。 また、その他の設定変更も多数あります。 ホット適用機能があり、実行時に伝播されます。 それでは、第二部です。
クライアント接続フェイルオーバー
XNUMX 番目の部分は、クラスター接続フェイルオーバーと同じ方法であるクライアント接続フェイルオーバーです。 ただし、クライアントが常にクラスター サーバーの近くにあるとは限らないため、これは実際にはさらに必要になります。 また、間にルーターやファイアウォールが存在する場合もあります。 そのため、クライアントとクラスター間の接続が切断される可能性が高くなります。 それで、 NCache かなりインテリジェントな再試行機能、タイムアウトを備えています。 キープアライブ機能もあるため、接続が切断された場合でもクライアントは接続を維持し、クライアント自身を再接続します。 NCache 集まる。
スプリットブレインの検出と回復
動的な側面に関するもう XNUMX つの重要なトピック NCache アーキテクチャはスプリットブレインです。 スプリット ブレインは、クラスター内で発生する可能性のある現象です。
接続切断時にスプリットブレインが発生する
そして、スプリット ブレインは、たとえば 1 台のサーバーからなる正常なクラスターがある場合、これらのサーバー間の接続が何らかの理由で切断されたときに発生します。また、ネットワーク接続がある場合はいつでも切断される可能性があります。 そして、私たちはそれを常に目にしています。 したがって、それが起こると、サブクラスターが形成されます。 この場合、スプリット 2、スプリット 3、スプリット XNUMX があるとします。各サブ クラスターは、自分が生き残りであると考えます。 したがって、独自のクラスター コーディネーターを作成し、独立したクラスターになります。
スプリットブレイン検出
ただし、これらすべての分割は、以前は正常なクラスターの一部であったことを覚えており、これらのサーバーは自発的に離脱したわけではなく、スムーズに離脱したわけでもありません。 から「ノードからの離脱」を実行しませんでした。 NCache 代わりに管理ツールが接続を切断しました。 したがって、ネットワーク接続が復元されるかどうかを確認するために、これらのサーバーを探し続けます。 そして、ほとんどの場合、XNUMX 分、XNUMX 分、XNUMX 分、XNUMX 時間後に接続が復元される可能性が高くなります。
スプリットブレインリカバリー
それが起こると、スプリット ブレイン リカバリが実行されます。 そして、これらの分割がマージされるもの。 これらのサブ クラスターは、最大から最小まで反復的な方法でマージされます。これらが独立したクラスターになったため、明らかにデータの一部が失われ、データの一部が失われることになります。 ただし、それはすべて、指定したルールに基づいて自動的に行われます。
スプリット ブレインの詳細については、別の記事を参照してください。 ビデオ しかし、これで概要がわかります。 これは、 NCache クラスターは健全な状態を維持し、スプリット ブレインが発生してもいつでも回復できます。
キャッシングトポロジ
さて、それでは、次へ進みましょう キャッシングトポロジ。 キャッシュ トポロジは、本質的にはデータ ストレージ、レプリケーション戦略、そしてクライアント接続戦略でもあります。 トポロジには XNUMX つあり、XNUMX つはパーティション キャッシュ、パーティション レプリカ、レプリケート キャッシュ、およびミラー キャッシュです。 パーティション化されたキャッシュを使ってみましょう。
パーティション化されたキャッシュ
パーティション化されたキャッシュ 基本的に、キャッシュ全体がパーティションに分割され、各サーバーには 100 つのパーティションがあります。 そして、バケットという概念があります。 したがって、すべてのパーティションにバケットがあります。 キャッシュ全体で合計 XNUMX バケット。 したがって、パーティションの数に応じて、それらのバケットはパーティション間で均等に分割されます。
そして、これらのパーティションは実行時に作成されますが、これがこの重要な部分です。 したがって、サーバーを追加するとパーティションが作成されます。 たとえば、100 台のサーバーから開始し、パーティションが XNUMX つだけあり、XNUMX 個のバケットすべてがそのパーティション内にあるとします。 実行時に XNUMX 台目のサーバーを追加すると、前のスライドで説明したクラスター メンバーシップ情報が更新されるだけでなく、分散マップも更新されます。 分散マップは基本的に、どのパーティションにどのバケットが含まれているかを示すマップです。 したがって、XNUMX 番目のパーティションを追加すると、分布マップが変更されるとします。 分散マップは実際には、バケットにマッピングされたハッシュ マップです。 ハッシュ マップ値の範囲はバケットまでです。 また、これは追加したデータの量によって変化するのではなく、サーバーの数、パーティションの数を変更する場合、またはデータのリバランスを実行する場合にのみ変化します。 したがって、パーティションは動的です。
動的データバランシング
XNUMX 番目の部分は、動的なデータ バランシングがあることです。 したがって、これはすべてハッシュ マップ ベースであるため、使用したキーのタイプに基づいて、一部のバケットが他のバケットよりも多くのデータを取得する可能性が非常に高くなります。 そして、一部のパーティションはほぼ満杯になり、他のパーティションはほぼ空になります。 そして、それが起こったとき、 NCache には、しきい値を設定できるこの機能があります。 たとえば、パーティションが 80% を超えていっぱいになった場合、その 20%、または 10%、または 5% を削除するとします。 削除するのではなく、動的にバランスをとることを意味します。 したがって、データ バランシングとは、これらのバケットをパーティション 1 から取得して他のパーティションにコピーするか、他のパーティションに移動することを意味します。 したがって、データバランシングにより、データとすべてのパーティションがほぼ均等になることが保証されます。
クライアントはすべてのパーティションに接続します
パーティション キャッシュでは、すべてのクライアントがすべてのパーティションまたはすべてのサーバーに接続します。 このようにする理由は、3 回の呼び出しで必要な項目に直接アクセスしたいためです。 たとえば、1 つのサーバーにのみ接続されており、項目番号 1 が必要な場合、サーバー 2 と通信し、サーバー XNUMX はサーバー XNUMX に移動して項目番号 XNUMX を取得します。 そして、これは XNUMX ホップの操作であり、クライアントがデータのある場所に直接アクセスできるほど最適化されていません。 そして、クライアントは分布マップのおかげでそれを知っています。 そのため、クライアントがデータの場所を把握できるように配布マップが作成され、クライアントはそこから直接アクセスしてデータを取得できます。
したがって、パーティション化キャッシュにはレプリケーションがありません。 したがって、サーバーがダウンすると、そのデータが失われます。 後で説明する「永続化」を使用する以外に方法はありません。 そうすれば、パーティション化されたキャッシュでもデータが失われることはありません。
パーティション-レプリカキャッシュ
パーティションのレプリカ (動的)
次のトポロジはパーティション レプリカ キャッシュです。 ちなみに、これは両方の長所を提供するため、最も人気のあるトポロジです。 これによりパーティショニング、つまりスケーラビリティが得られます。 また、高可用性であるレプリケーションも提供します。 したがって、データの損失はありません。 したがって、たとえば、これはパーティション化されたキャッシュと同じ方法であり、すべてが同じですが、すべてのパーティションが別のサーバー上にレプリカを持つようになります。 したがって、パーティション 1 はサーバー 1 上にあり、そのレプリカはレプリカ 2 と呼ばれます。つまり、この場合はサーバー XNUMX になります。つまり、パーティションが実行時に動的に作成されたのと同じように、レプリカも実行時に作成されます。追加または削除されます。 そして、それらは明らかに常に異なるサーバー上にあります。
もう XNUMX つの部分は、すべてのレプリカがパッシブであるということです。 パッシブとは、クライアントが直接話しかけないことを意味します。 クライアントとは、パーティションとのみ通信し、その後パーティションがレプリカを更新することを意味します。 したがって、パーティション内の何かを更新するたびに、パーティションはレプリカ内のそれを更新します。 そして、その更新はデフォルトでは非同期です。 非同期なので高速になります。 まず第一に、クライアントはレプリケーションが行われるのを待つ必要がありません。第二に、一括レプリケーションを実行できます。 したがって、これらの更新を何百または何千も組み合わせて、一度にレプリカに移動またはプッシュできます。 なぜなら、このネットワーク旅行のコストは、データを結合するよりもはるかに速く、またははるかに高価だからです。
非同期/同期レプリケーション
ただし、非同期レプリケーションでは、明らかに常に一貫性が保たれるわけではありません。 最終的には一貫性があり、おそらく 95% ～ 99% の場合には十分ですが、非常に機密性の高いデータを扱う場合は 1 ～ 5% の場合もあります。 したがって、必要なのは非同期レプリケーションではなく、同期レプリケーションです。 したがって、同期レプリケーションと呼ばれる機能があり、これをオンにすると、クライアントがパーティション内のアイテムを更新するたびに、パーティションが最初にレプリカを更新するまで操作は完了しません。 したがって、そのレプリケーションが失敗すると、操作は失敗します。 このように、操作が成功するとレプリケーションも成功することがわかります。 つまり、これは非常に重要な機能です。
そして最後に、パーティション化されたトポロジ、パーティション化されたキャッシュ トポロジと同様に、レプリカ上でも動的データ バランシングが行われます。 したがって、パーティションが動的にデータバランスされている場合、レプリカは常にパーティションの同一のコピーであるため、レプリカはそれに一致する必要があります。 したがって、データバランシングも行われることになります。
動的パーティション化
動的パーティショニングが実際にどのように行われるかを簡単に見てみましょう。 たとえば、6 つのサーバーのクラスターがあり、その中に XNUMX つのアイテムがあり、XNUMX 番目のサーバーを追加したいとします。これは別の使用例なので、データはまだ追加しません。これがデータの状況です。別のノードを追加すると、他のパーティションに移動します。
たとえば、ノードを追加するとします。 つまり、現在 3 番目のサーバーが存在します。 したがって、パーティション 3 が作成され、パーティション 1 はパーティション 2 とパーティション 1 からデータを取得します。つまり、2 からいくつかのデータを取得し、3 からいくつかのデータを取得します。つまり、パーティション 1 からアイテム 4 を取得し、パーティション 2 からアイテム 3 を取得するとします。そしてパーティション XNUMX になります。
パーティション 3 になったので、そのレプリカは別のサーバー上に存在する必要があるため、サーバー 1 に配置されるとします。つまり、サーバー 1 にはレプリカ 2 が存在していましたが、レプリカ 3 に変換され、その後レプリカ 2 が移動されます。したがって、たとえば、レプリカ 3 には 3、3、4 ではなく 4、5 が含まれ、レプリカ 6 には 2、5 が含まれます。これらすべては、アプリケーションが認識することなく、実行時に動的に行われます。あらゆる中断。
サーバーがダウンした場合と同じことが逆に起こります。たとえば、XNUMX つのパーティションがあったとします。 NCache クラスターと、サーバー 3 がダウンしました。あなたがそれをダウンさせたか、ダウンさせたかのどちらかです。それが起こるとすぐに、パーティション 3 が使用できなくなったため、レプリカ 3 が色を変更したことがわかりますが、アクティブになります。 通常、先ほども言いましたが、レプリカはアクティブではありません。 パーティションのみがアクティブですが、これでパーティション化されます。 ただし、同じボックス上に XNUMX つのパーティションがあり、レプリカが存在しないことは望ましくないため、これは一時的なものにすぎません。
これで、ここでパーティション 1 とマージされます。つまり、アイテム 3 がパーティション 1 に移動し、アイテム 4 がパーティション 2 に移動し、状況は次のようになり、このレプリカ 3 がレプリカ 2 になります。同じことが逆方向にもすべて実行時に発生します。動的パーティショニングは非常に柔軟で、非常に動的です。 このダイナミクスにより、高可用性のパワーが追加されます。 NCache.
メンテナンスモード
動的パーティショニングは非常に便利で強力ですが、再パーティショニングをしたくない場合もあり、その XNUMX つが定期メンテナンスです。 たとえば、オペレーティング システムのパッチを適用していて、そのパッチによってサーバーが XNUMX 分間または XNUMX 分間ダウンすることになるとします。 ご存知のとおり、キャッシュ クラスター全体には数十ギガバイトのデータが含まれる可能性があります。 したがって、その XNUMX 分間だけパーティションを再分割し、そのノードをバックアップしたときに再度パーティションを再分割する必要はありません。 したがって、スケジュールメンテナンス機能をオンにすることができます。 NCache この場合、このノードを停止するときは、管理ツールを使用してノードを停止する必要があります。これにより、このレプリカがアクティブになりますが、再パーティション化は行われません。
したがって、パーティション 1 レプリカ 3、パーティション 2 レプリカ 1 の 3 つのサーバー構成のままになります。このレプリカ 3 は実際にはパーティション 1 であり、アクティブで動作していることを意味します。 パーティション 2 はここにバックアップされているため、明らかに高可用性ではありません。 パーティション 3 にはバックアップがなく、レプリカ 5 にもバックアップはありません。 ただし、これは 10 ～ XNUMX 分間だけ必要なため、一時的なものにすぎません。 したがって、このサーバーが復帰すると古い状態に戻り、再びパーティションになると再びレプリカになります。 これが、定期メンテナンス機能の仕組みです。 NCache 作品。
複製されたキャッシュ
次のトポロジは と呼ばれます。 複製されたキャッシュ。 このトポロジでは、XNUMX つ以上のサーバーを使用できます。この場合、すべてのサーバーにキャッシュのコピー全体があり、すべてのサーバーがアクティブになります。つまり、すべてのサーバーにクライアントが接続されています。 ただし、ここではすべてのクライアントは XNUMX つのサーバーにのみ接続します。 なぜなら、そのサーバーにはキャッシュ全体があるからです。 したがって、パーティションまたはパーティションのレプリカのように XNUMX つのサーバーに接続する必要はありません。
このトポロジでは、キャッシュ全体がすぐそこにあるため、すべての読み取りが超高速になりますが、更新は同期して実行する必要があります。 なぜなら、これらは両方ともアクティブなサーバーであるため、同じアイテムがこことここで同時に更新される可能性があり、明らかにデータの整合性の問題に巻き込まれたくないからです。 つまり、インデックス作成スキームがあり、インデックスがあり、実際にはシーケンス番号のようなものが発行され、すべての項目が同じシーケンスで更新される同期方式で行われます。 したがって、更新を常に正しい方法で行うことができます。 ただし、同期更新の代償として、項目 1 を更新するクライアントがある場合、このサーバーは項目 2 に項目 1 を更新するよう通知することになります。両方のサーバーが項目 1 を正常に更新した場合にのみ、更新は成功し、制御は戻ります。 つまり、パーティションまたはパーティション レプリカ トポロジほど高速ではありませんが、更新が成功すれば、常にすべてのサーバーに対して更新が行われるため、動作は保証されています。
このトポロジは、読み取り集中型の操作に適しています。 XNUMX サーバー クラスターの場合、書き込みもかなり高速で、パーティション レプリカほどではありませんが、ほとんどの状況ではかなり高速です。 ただし、サーバーを追加すると、更新のパフォーマンスが低下します。 実際には、より多くのサーバーを同期的に更新する必要があるため、速度が遅くなります。 したがって、このトポロジには独自の用途があるため、このトポロジを維持します。 私たちの顧客の多くは特別な状況でそれを使用しています。
ミラーリングされたキャッシュ
XNUMX 番目のトポロジは、 ミラーリングされたキャッシュ。 これも非常に特殊なトポロジです。 これは 2 ノード トポロジのみです。 アクティブ ノードとパッシブ ノードがあります。 繰り返しますが、アクティブ ノードにはキャッシュ全体があり、キャッシュのコピーがパッシブ ノードに存在します。 すべてのクライアントはアクティブ ノードに接続し、すべての内容についてアクティブ ノードを更新します。更新は非同期にミラーリングまたはパッシブ ノードに複製されます。 そして、非同期であるということは、パーティション レプリカと同様に非常に高速であることも意味します。
このトポロジでは、アクティブ ノードがダウンすると、パッシブ ノードが自動的にアクティブになり、すべてのクライアントが自動的にパッシブ ノードまたは新たにアクティブ ノードに移動します。 そして、そうすることでダウンタイムも中断もなくなり、それがフェイルオーバーサポートの自動化と呼ばれるもので、私が言いたかったのはそういうことです。 そして、明らかに、アクティブ ノードが復帰すると、これが再びアクティブになり、同じことが逆に起こります。
したがって、ミラー トポロジは特殊なケースにも非常に役立ちます。 これら XNUMX 台のサーバーを超える拡張性はありませんが、すべてのクライアントがここに接続するため、独自の用途があり、別のボックスにレプリカを作成できます。 これは、たとえば災害復旧の場合に使用できるということです。
ライブ永続性
もう一つの非常に強力な機能は、 NCache と呼ばれる ライブ永続性。 ライブ永続性は、パーティションおよびパーティション レプリカ トポロジでのみ使用できます。ライブ永続性は、実行時にキャッシュを更新すると、永続ストアも即座に更新されることを意味します。 永続ストアへの更新は非同期です。 したがって、アプリケーションのパフォーマンスや NCache パフォーマンス。 このようにして、アプリケーションは非常に高速な状態を維持できるのです。 永続化はバケット レベルで行われます。 したがって、キャッシュ全体を表すバケットは 100 個あり、 NoSQL 書類保管庫。 これはファイルベースのストアであるため、サーバーベースのストアではありません。 それはありません NoSQL database サーバー、それは NoSQL ドキュメントストア NCache を使用します。 内のすべてのサーバーに共通の共通の場所で使用できます。 NCache そうすれば、それらはすべて同じ永続ストアに依存できます。
この利点のいくつかとこの機能が提供される理由は、第一に、永続化する内容が何であれ、たとえば、キャッシュ全体を永続化でき、キャッシュ全体が常に永続化されることです。 キャッシュ内で更新しているものはすべて、数ミリ秒の違いで永続ストアにも保持されていると言えます。 したがって、それを取得して別のキャッシュにリロードすることも、すべてのサーバーがダウンした場合でも、いつでも永続ストアから再起動することができます。 非常に少量のデータを除いて、データが失われることはありません。 あるいは、ある環境から別の環境にキャッシュを移動したい場合もあり、それは簡単に行うことができます。
もう XNUMX つの利点は、パーティションおよびパーティション レプリカ トポロジに実際に高可用性が追加されることです。 さて、パーティション トポロジについてですが、ここで詳しく説明します。 先ほど述べたように、パーティション キャッシュにはレプリケーションがありません。そのため、パーティションやサーバーがダウンした場合、そのパーティションは失われます。 まあ、永続性がオンになっている場合は、そうではありません。 なぜなら、そのデータのコピーもこれらのバケットに保存されているからです。 したがって、このサーバーがダウンした場合、メモリ内のバケットは再割り当てされますが、明らかにデータはなく他のサーバーに割り当てられます。これらのサーバーは、これらのバケットが永続ストアにデータが存在する空のバケットであることを認識しているため、永続ストアからそのデータをリロードします。店。
したがって、パーティション キャッシュを使用している場合でも、サーバーがダウンしてもデータを失わないようにすることができます。 また、パーティション レプリカとパーティション キャッシュと同じ利点があります。
ここで得られる利点は、より多くのメモリを使用できることです。 ここで割り当てる必要はないが、永続ストアを割り当てる必要があるレプリカにはより多くのメモリを割り当てる必要があるため、より多くのデータをキャッシュに保存できます。 これがパーティション化キャッシュの利点です。 パーティションレプリカにも利点があります。 そして、興味深いのは、これによってすでに高可用性が実現されているものの、高可用性が得られるのは、ある時点で XNUMX 台のサーバーがダウンした場合のみである場合、たとえば XNUMX 台のサーバーが同時にダウンし、永続性さえも維持されなかった場合です。パーティションレプリカではデータが失われる可能性があります。 なぜなら、各パーティションには XNUMX つのコピーしか存在しないため、XNUMX 台のサーバーがダウンした場合、許容できる以上のサーバーを失うことになるからです。 永続性があれば問題はありません。永続ストアからすべてのデータをリロードするだけです。
明らかに、どちらの場合も、永続ストアからデータをロードするときは常に、XNUMX つのサーバーがあったが、現在は XNUMX つのサーバーがあることに留意する必要があります。 データの価値が大きすぎて XNUMX 台のサーバーに収まらない可能性があります。対処しなければならないもう XNUMX つの問題は、残りの XNUMX 台のサーバーに XNUMX 台すべてに相当するメモリを収容できる十分なメモリがあることを確認することです。サーバー。 したがって、それが唯一の制限です。 それ以外の場合、永続性によりパーティション キャッシュとパーティション レプリカ キャッシュの両方に実際に価値が追加されます。
クライアントキャッシュ
さて、もう XNUMX つの非常に重要な機能は、 NCache と呼ばれる クライアントキャッシュ。 分散ストア環境で InProc 速度を実現します。 たとえば、分散型 NCache クラスター、アプリケーションはここで実行されています、これは通常、データベースまたは実行中の他のものの上にあるキャッシュです。クライアント キャッシュは通常、分散キャッシュ シナリオがある場合に使用されます。クライアント キャッシュは、クラスターの上にあるキャッシュです。このキャッシュ クラスターはアプリケーションのすぐ近くにあります。 アプリケーションサーバーまたは NCache クライアントボックス。 また、好みに応じて InProc または OutProc にすることもできます。 InProc キャッシュは、実際にデータを逆シリアル化されたオブジェクト形式でヒープ上に保持するため、超高速です。 つまり、そのオブジェクトがヒープ上にあるようなものです。 それよりも早くなる可能性があります。
したがって、InProc キャッシュは超高速ですが、同時に優れている点は、キャッシュと同期していることです。 NCache 集まる。 また、同期方法は、クラスターが認識しているクライアント キャッシュに保存されているものすべてです。 したがって、このクライアント キャッシュに保持されていたものがクラスター内の別のクライアントで更新されると、クラスターはクライアント キャッシュに自身を更新するように通知します。 そして、クライアント キャッシュ自体が非同期で更新されます。 もちろん、数ミリ秒の遅延はありますが、前述したように、ほとんどの場合は結果整合性がモデルであり、通常は 99% のケースで許容されます。
それが受け入れられない場合は、 NCache を提供します…そして、オプティミスティック同期がデフォルトです。この場合、数ミリ秒の遅延があり、技術的には古いデータがある状況が発生する可能性がありますが、99% の場合は問題ありません。 しかし、それが問題なく、データが非常に機密であるにもかかわらず、それでもクライアント キャッシュを使用したい場合は、アプリケーションがクライアント キャッシュから何かをフェッチする前にクライアント キャッシュを確実に取得するという悲観的な同期機能を使用できます。キャッシュは、そのデータの新しいバージョンがあるかどうかだけを確認します。これは、データ自体を取得するよりも呼び出しが高速です。 NCache 複数のバージョン情報を保持します。 そして、そのデータの新しいバージョンがある場合はクライアント キャッシュがそれを取得し、そうでない場合はクライアント キャッシュからそれを返します。
コードを変更せずに使用できるクライアント キャッシュ。 環境に接続するだけで、読み取りが集中する状況に適しています。 少なくとも 5:1、10:1 でより多くの読み取りを行う場合は理想的ですが、1:1 の場合、たとえば Web セッションの場合、クライアント キャッシュは実際にはまったく役に立ちません。 実際、まったくお勧めできません。
WANレプリケーション
マルチゾーン/マルチリージョン
さて、別の部分 NCache どこですか NCache ありません WANレプリケーション アプリケーションのマルチゾーンまたはマルチリージョン展開を処理します。 したがって、たとえば、災害復旧のためにアプリケーションを XNUMX つの異なるサイトにデプロイし、XNUMX つはアクティブ、もう XNUMX つはパッシブにすることができます。 そして、このアプリケーションを手に入れました。 NCache 実行中ですが、ここには実行されていないアプリケーションがあります。 ただし、このサイトがダウンした場合でも、すぐに負荷を回復できるようにする必要があります。 ということで、橋を架けることができます。 ブリッジは 2 ノードのクラスターそのものであり、ブリッジと同じボックス上に配置できます。 NCache メインにするか、別の専用にするかはあなた次第です。 そして、このキャッシュ内で更新したものはすべて、WAN を介して他のキャッシュに非同期的に複製されます。 つまり、アクティブ-パッシブです。
アクティブ-アクティブでも同じことができます。 このサイトさえアクティブな状況がある場合、両方のサイトが相互に更新できるアクティブ/アクティブを使用して、まったく同じことを実行できるとします。 その場合、紛争が解決する可能性もあれば、発生する可能性もある状況もあります。 そして、競合とは、同じ項目、同じキーが両方のサイトで同時に更新されていることを意味します。 その場合、ブリッジはデフォルトで「最後の更新が優先」ロジックを適用します。 したがって、更新されたタイムスタンプが遅い方が優先されます。 ただし、たとえば、必要に応じて、ブリッジが呼び出す .NET または Java コードである競合解決および競合解決ハンドラーを提供することもできます。これにより、データまたはオブジェクトの両方のコピーがその解決ハンドラーに渡されます。そして、コンテンツを分析してどちらがより正しいかを判断すると、「よし、この更新が優先」となり、その更新が両方のサイトに適用されます。 それが双方に適用される限り、紛争は発生しません。
NCache には、アクティブ/アクティブ、アクティブ/パッシブ、またはそれらの組み合わせで XNUMX つ以上のサイトを提供する機能があります。 したがって、たとえば、少なくとも XNUMX つのアクティブが必要ですが、これらがすべてパッシブになることも、すべてアクティブになることも、アクティブとパッシブの組み合わせになることもあります。 そして、やはり同じように、複数のアクティブなアクティブな場合、これは競合の解決になる可能性があります。
コンテナ (Docker および Kubernetes)
最後に、コンテナーは Docker と Kubernetes で非常に人気のあるものになりました。 それで、 NCache は、まだ .NET や Windows 側よりも Java や Linux 側で人気があるため、それらをサポートしていることは明らかですが、時間の経過とともに変化すると確信しています。 どちらにしても、 NCache は両方の環境で完全に処理できます。 たとえば、これは典型的なものです Kubernetes のデプロイメント NCache.
これが NCache 展開。 あるよ NCache 独自のディスカバリーサービスを取得しました。 これらはスケーリング可能なポッドであり、Kubernetes クラスター内にアプリケーションが存在します。 NCache これは、Azure、AKS、AWS、EKS、Google GKE、または Red Hat OpenShift のいずれかです。 Red Hat OpenShift は通常、AWS、Azure、Google などの別のクラウド、あるいは別のクラウドのいずれかですが、 NCache それらすべてをサポートします。 そして、このポッドは Linux である可能性があり、これは Kubernetes でより一般的なケースです。 NCache 完全に正常に動作します。 また、アプリケーションは Linux または Windows にすることもできます。 したがって、これらは Linux または Windows、Linux または Windows のいずれかになります。
Docker / Kubernetes (マルチゾーン)
WAN レプリケーションが開始されるのと同じように、必要に応じて、たとえばクラウドのおかげで複数のアベイラビリティ ゾーンを持つことができます。 マルチゾーン Kubernetes を実行したいと考えていました。
したがって、私たちが推奨する方法は、XNUMX つの Kubernetes クラスターを作成し、XNUMX つの Kubernetes クラスターを作成することです。 NCache デプロイメントの場合、これらはアクティブ-アクティブまたはアクティブ-パッシブになる可能性があります。 そして、橋は完全にここに設置することも、完全にここに設置することもできます。 または、XNUMX つの部分がこのゾーン上にあり、もう XNUMX つの部分がそのゾーン上にあるブリッジ分割を設定し、レプリケーションを非同期で実行することもできます。
今日のテーマはこれでほぼカバーされていると思います。 私たちのウェブサイトにアクセスして、以下を参照することを強くお勧めします。 NCache プレイグラウンド これは、ブラウザからライブ実行コピーを使用する非常に迅速かつ簡単な方法です。 NCache2 ノードを取得することもできます NCache インストール作業を行わずに、すべてのツールを使用してクラスター化します。 または、準備ができたらここに来てください 登録してダウンロードする どちら NCache Enterprise .NET エディションの場合、または NCache Enterprise Java版の場合。 先ほども述べたように、Linux の .tar.gz または .msi を入手することも、Docker を入手することもできます。 Docker イメージをプルするだけです NCache。 私のプレゼンテーションはこれで終わりです。 どうもありがとうございます。