キャッシュ内の楽観的ロックと悲観的ロック
環境内に共有リソースがある場合は常に、ロックの必要性が生じます。複数のユーザーがリソースを共有すると、データの不整合が発生する可能性があります。このような問題は、ロックによって最もよく処理できます。ロック メカニズムを使用すると、重要なデータ セットがフォールト トレラントになり、ユーザーに原子性、一貫性、分離性が提供されます。
Note
この機能は以下でも利用できます NCache Professional.
NCache は、さまざまな並列クライアントによって更新されるキャッシュ ストア内のデータ同期と整合性のための効率的なロック メカニズムを提供します。 NCache 内部ロックにより、キャッシュ クラスター全体のデータの一貫性が更新のたびに保証されます。 同じデータ。さらに、 NCache は、特定のキャッシュ データをロックする API を提供し、単一のスレッドまたはアプリケーションだけがキャッシュ データを更新または読み取りできるようにします。
ロックを使用する場合
問題提起
5000 人の口座所有者が使用する一意の銀行口座があるシナリオを考えてみましょう。口座には 1 ドルの残高があります。ユーザー 2000 は口座から 2 ドルを引き出し、ユーザー 1000 は口座に 4000 ドルを入金したいと考えています。与えられた条件を考慮すると、これらの操作を実行した後のアカウント残高は $5000 でなければなりません (2000-3000 = 3000 & 1000+4000 = XNUMX)。
ここで、両方のユーザーがアカウントに対してこの操作を同時に実行したいと考えていますが、このシナリオには適切な処理がないため、次のようなことが起こると考えてみましょう。
ユーザー 1 がアカウント残高を確認すると、5000 ドルと表示されます。 彼は 2000 ドルを引き出し、合計残高は 3000 ドルになります。
ユーザー 2 が口座残高を確認すると、5000 ドルと表示されます。 彼は 1000 ドルを入金し、合計残高は 6000 ドルになります。
次の図は、シナリオを視覚的に示しています。
ソリューション
この共有リソースの問題を解決するには、2 つのアプローチを使用できます。
1 つ目のアプローチは、あるユーザーが既に銀行口座に対して何らかの操作を実行している場合に、それ以上の操作ができないように銀行口座をロックすることです。
2 番目のアプローチは、両方のユーザーが使用できるように銀行口座が開かれていますが、実行される操作ごとに現在時刻に応じて銀行口座のバージョンが更新されるメカニズムを使用するものです。これにより、新しいバージョンをユーザーの操作に使用できるようになります。
NCache は、悲観的ロックと楽観的ロックとして知られるロックの両方のメカニズムを提供します。 これらについては、後続の章でさらに説明します。
タイプ : 楽観的ロックと悲観的ロック
使用可能なロックには XNUMX つのタイプがあります。 NCache:
悲観的ロック(排他的ロック)
悲観的ロックは、アイテムを排他的にロックするメカニズムです。LockHandle
そのため、ロックされている間、他のユーザーはアイテムにアクセスできません。楽観的ロック (キャッシュ項目のバージョン管理)
オプティミスティック ロックは、アイテムのバージョン管理を使用してアイテムをロックするメカニズムです。このメカニズムを使用すると、アイテムは別のユーザーが使用できるように開かれますが、アイテムに対して操作が実行されるたびに、アイテムのバージョンが自動的に更新されます。
も参照してください
。ネット: Alachisoft.NCache.ランタイム.キャッシュ 名前空間
Java: comの。alachisoft.ncache.ランタイムキャッシュ 名前空間
Node.js: キャッシュ とに提供されます。
Python: ncache.ランタイムキャッシュ とに提供されます。