zookeeeperにおける楽観的ロックと悲観的ロックの応用
一、概念紹介
1、悲観ロックは悲観同時制御(Pessimistic Concurrency Control,PCC)とも呼ばれ、データベースの中で非常に典型的で非常に厳格な同時制御戦略である.悲観的なロックは、同じデータの同時更新によるデータの一貫性の問題を効果的に回避するために、強力な排他的および排他的な特性を有します.悲観的ロックの実現原理では、あるトランザクション(トランザクションAを仮定)がデータを処理している場合、処理中にデータがロックされ、その間、他のトランザクションはデータの更新操作を行うことができず、トランザクションAがデータの処理を完了し、対応するロックが解放されるまで、他のトランザクションは、データの更新操作を再競争することができます.つまり、独立したデータに対して、システムは唯一の鍵を割り当てているだけで、誰がこの鍵を手に入れたのか、誰がこのデータを更新する権利があります.一般的に、実際の生産応用では、悲観的ロック戦略は、データ更新競争が非常に激しいシーンを解決するのに適しており、このようなシーンでは、通常、単純で乱暴な悲観的ロックメカニズムを採用して同時制御の問題を解決する.
2、楽観ロックは楽観同時制御(Optimistic Concurrency Control,OCC)とも呼ばれ、一般的な同時制御戦略でもある.悲観的なロックに比べて、楽観的なロックメカニズムはより緩やかで友好的に見えます.悲観的なロックは、異なるトランザクション間の処理が互いに干渉すると仮定し、1つのトランザクションが最初から最後までデータをロックする必要があります.楽観的なロックは、複数のプロセスに影響を与えません.したがって、トランザクションのほとんどの時間にロック処理を行う必要はありません.楽観的ロック・メカニズムでは、更新リクエストが送信される前に、各トランザクションが現在のトランザクションがデータを読み出した後、他のトランザクションがこのデータを変更したかどうかを最初にチェックします.他のトランザクションに更新がある場合は、コミット中のデータをロールバックする必要があります.楽観的なロックは、通常、データの同時性が少なく、トランザクションの競合が少ないアプリケーションシーンで使用されます.
楽観ロックには、データ読み出し、書き込みチェック、およびデータ書き込みの3つの段階があり、書き込みチェックは楽観ロック制御全体の鍵となります.書き込み検証フェーズでは、トランザクションは、データの読み込みフェーズ後に他のトランザクションがデータを更新したかどうかを確認し、データの更新の一貫性を確保します.
3、CAS理論
v値については、更新のたびにその値が予想値aであるかどうかを比較し、予想に合致している場合にのみ、vを値bに原子化して更新し、予想に合致しているかどうかが楽観ロックの「書き込み検証」フェーズである.
zookeeperでは、versionバージョン番号によって楽観的なロックを実現する「書き込み検証」メカニズムを制御します.zookeeper内では、プロセッサでは、次の方法で実現されます.
setDataRequestリクエスト処理を1回行う場合、まずバージョンチェックが行われます.zookeeeperはsetDataRequestリクエストから現在のリクエストのバージョンバージョンバージョンバージョンバージョンバージョンバージョンバージョンを取得し、データレコードnoderecordから現在のサーバ上のデータの最新バージョンcurrentversionを取得します.バージョンが-1の場合、クライアントは楽観的なロックを必要とせず、バージョンの比較を無視することができます.バージョンが-1でない場合は、バージョンとcurrentversionを比較し、2つのバージョンが一致しない場合はBadVersionException異常を放出します.
1、悲観ロックは悲観同時制御(Pessimistic Concurrency Control,PCC)とも呼ばれ、データベースの中で非常に典型的で非常に厳格な同時制御戦略である.悲観的なロックは、同じデータの同時更新によるデータの一貫性の問題を効果的に回避するために、強力な排他的および排他的な特性を有します.悲観的ロックの実現原理では、あるトランザクション(トランザクションAを仮定)がデータを処理している場合、処理中にデータがロックされ、その間、他のトランザクションはデータの更新操作を行うことができず、トランザクションAがデータの処理を完了し、対応するロックが解放されるまで、他のトランザクションは、データの更新操作を再競争することができます.つまり、独立したデータに対して、システムは唯一の鍵を割り当てているだけで、誰がこの鍵を手に入れたのか、誰がこのデータを更新する権利があります.一般的に、実際の生産応用では、悲観的ロック戦略は、データ更新競争が非常に激しいシーンを解決するのに適しており、このようなシーンでは、通常、単純で乱暴な悲観的ロックメカニズムを採用して同時制御の問題を解決する.
2、楽観ロックは楽観同時制御(Optimistic Concurrency Control,OCC)とも呼ばれ、一般的な同時制御戦略でもある.悲観的なロックに比べて、楽観的なロックメカニズムはより緩やかで友好的に見えます.悲観的なロックは、異なるトランザクション間の処理が互いに干渉すると仮定し、1つのトランザクションが最初から最後までデータをロックする必要があります.楽観的なロックは、複数のプロセスに影響を与えません.したがって、トランザクションのほとんどの時間にロック処理を行う必要はありません.楽観的ロック・メカニズムでは、更新リクエストが送信される前に、各トランザクションが現在のトランザクションがデータを読み出した後、他のトランザクションがこのデータを変更したかどうかを最初にチェックします.他のトランザクションに更新がある場合は、コミット中のデータをロールバックする必要があります.楽観的なロックは、通常、データの同時性が少なく、トランザクションの競合が少ないアプリケーションシーンで使用されます.
楽観ロックには、データ読み出し、書き込みチェック、およびデータ書き込みの3つの段階があり、書き込みチェックは楽観ロック制御全体の鍵となります.書き込み検証フェーズでは、トランザクションは、データの読み込みフェーズ後に他のトランザクションがデータを更新したかどうかを確認し、データの更新の一貫性を確保します.
3、CAS理論
v値については、更新のたびにその値が予想値aであるかどうかを比較し、予想に合致している場合にのみ、vを値bに原子化して更新し、予想に合致しているかどうかが楽観ロックの「書き込み検証」フェーズである.
zookeeperでは、versionバージョン番号によって楽観的なロックを実現する「書き込み検証」メカニズムを制御します.zookeeper内では、プロセッサでは、次の方法で実現されます.
version = setDataRequest.getVersion();
int currentVersion = nodeRecord.stat.getVersion();
if(version != -1 && version != currentVersion)
{
throw new KeeperException.BadVersionException(path);
}
version = currentVersion + 1;
setDataRequestリクエスト処理を1回行う場合、まずバージョンチェックが行われます.zookeeeperはsetDataRequestリクエストから現在のリクエストのバージョンバージョンバージョンバージョンバージョンバージョンバージョンバージョンを取得し、データレコードnoderecordから現在のサーバ上のデータの最新バージョンcurrentversionを取得します.バージョンが-1の場合、クライアントは楽観的なロックを必要とせず、バージョンの比較を無視することができます.バージョンが-1でない場合は、バージョンとcurrentversionを比較し、2つのバージョンが一致しない場合はBadVersionException異常を放出します.