ビジネスにおける楽観主義と悲観的なロックの実用的なアプリケーションのケース

楽観的なロックと悲観的なロックの選択は、ビジネスシナリオとデータの一貫性要件に依存します。 1.悲観的なロックはデータの競合を想定し、ロックはデータの一貫性を確保しますが、銀行の転送などの高い並行性の下では効率が低くなります。 2.楽観的なロックデータの競合確率が低く、ロックが追加されていないと仮定します。更新前にデータが変更されているかどうかを確認します。高効率ですが、eコマースインベントリ管理やフォーラムコメントなどのデータの矛盾。 3.高い並行性シナリオでは、楽観的なロックと悲観的なロックを組み合わせ、楽観的なロックの最初の前処理、そして最終的には、効率とデータの一貫性を考慮して、悲観的ロックを確認することを検討できます。最終的な選択には、効率とデータの一貫性のトレードオフが必要です。

楽観的なロックと悲観的なロック：ビジネス慣行のトレードオフと選択

楽観的なロックと悲観的なロック、これら2つの概念は神秘的に聞こえますが、実際には、データベースへの同時アクセスを扱う場合、2つの完全に異なる戦略です。簡単に言えば、楽観的なロックは「データは一般的に矛盾しない」と信じていますが、悲観的なロックは「データは競合する可能性が高い」と考えています。この記事では、退屈な定義を提供するものではありませんが、ビジネスシナリオに参加して、実際の条件に基づいて適切なソリューションを選択する方法を確認します。それを読んだ後、ビジネスニーズに基づいて古いドライバーのようなこれら2つのロックメカニズムを制御できます。

基本から始めましょう。名前が示すように、悲観的なロックは、常に最悪の場合を想定しています - 同時の修正。データの競合を回避するために、データにアクセスするときにデータを直接ロックします。典型的な例は、データベースのトランザクション分離レベルと、いくつかのプログラミング言語によって提供されるミューテックスメカニズムです。銀行口座の転送を想像してください。悲観的なロックは、厳格な警備員のようなものです。一度に操作を入力できるユーザーは1人だけで、他のユーザーは並んでいるだけです。これにより、データの一貫性が保証されますが、効率性...特に並行性が大きい場合は、待ち時間が長くなります。

楽観的なロックは完全に異なります。データの競合の確率は非常に低いため、ロックを積極的に追加しないと考えています。データを更新する前に、データが変更されたかどうかを確認します。変更されていない場合、更新されます。変更された場合、競合が促され、ユーザーが再入力されます。これは柔軟な管理者のようなもので、複数のユーザーがデータを同時に表示および変更でき、変更を送信するときにのみ確認を実行できます。これははるかに効率的ですが、リスクがあります。つまり、「汚いライティング」が発生する可能性があり、注意して処理する必要があります。

実際のケースを見てみましょう。

ケース1：eコマース製品在庫管理

コモディティインベントリは、典型的な同時シナリオです。悲観的なロックを使用する場合は、ユーザーが製品ページにアクセスするたびにロックを追加するか、インベントリをチェックするだけで、深刻なパフォーマンスボトルネックにつながる必要があります。そして、楽観的なロックは非常に適しています。バージョン番号メカニズムを使用して楽観的なロックを実現できます。各製品にはバージョン番号があり、インベントリが更新されるたびに、バージョン番号が一貫しているかどうかを確認します。一貫性がない場合、それはデータが変更され、更新が拒否されたことを意味します。これは、製品在庫に投稿されたラベルのようなもので、変更の数を記録し、ラベルが変更されていない場合にのみ変更できます。

 <code class="language-python">class Product:</code><pre class='brush:php;toolbar:false;'> def __init __（self、id、name、stock、version）：
    self.id = id
    self.name = name
    self.stock = stock
    self.version =バージョン

def update_stock（self、new_stock、current_version）：
    self.version == current_version：
        self.stock = new_stock
        self.version = 1
        trueを返す＃更新成功Else：
        false＃updateが失敗し、データが変更されました

同時の更新をシミュレートします

Product = Product（1、 "iPhone"、100、1）
thread1 = threading.thread（ターゲット= lambda：product.update_stock（90、1））
thread2 = threading.thread（target = lambda：croduct.update_stock（80、1））

thread1.start（）
thread2.start（）
thread1.join（）
thread2.join（）

print（f "final Inventory：{product.stock}"）＃結果の実行の順序に応じて、結果が80または90ではない場合があります。

このコードは、Pythonを使用して、楽観的なロックの実装をシミュレートします。これは単純化されたバージョンであり、データベーストランザクションの原子性などの問題を実際のアプリケーションで考慮する必要があることに注意してください。見たことがありますか？楽観的なロックは効率的ですが、データの矛盾につながる可能性があり、競合に対処するために適切なメカニズムが必要です。

ケース2：フォーラムの投稿コメント

フォーラムの投稿コメント、並行性のボリュームも非常に大きいです。悲観的なロックを使用する場合、すべてのコメントをロックする必要がありますが、これは効率的すぎます。ここにも楽観的なロックが適用されます。バージョン番号と同様のメカニズムを使用するか、タイムスタンプを使用してデータが変更されたかどうかを判断できます。

ケース3：銀行譲渡（別の強調）

上記のように、悲観的なロックはデータの一貫性を確保できるため、より安全な選択のようです。ただし、並行性のボリュームが非常に高い場合、悲観的なロックのパフォーマンスボトルネックは非常に明白になります。この時点で、楽観的なロックと悲観的なロックを組み合わせることを検討できます。たとえば、並行性シナリオでの前処理のために楽観的なロックを使用し、最後のコミットが提出された場合にのみ最終確認のために悲観的なロックを使用します。これにより、効率とデータの一貫性の両方が保証されます。これには、より複雑な戦略と設計が必要です。

要するに、楽観的なロックや悲観的なロックには絶対的な良いことも悪いこともありません。選択する戦略は、特定のビジネスシナリオとデータの一貫性の要件に依存します。高い並行性シナリオでは、楽観的なロックは通常より効率的ですが、データの競合を慎重に処理する必要があります。データの一貫性のために非常に高い要件を備えたシナリオでは、悲観的なロックはより安全ですが、パフォーマンスはボトルネックになる可能性があります。選択を行うときは、効率とデータの一貫性を量り、実際の状況に応じて適切なソリューションを選択するか、組み合わせて使用​​する必要があります。銀の弾丸はなく、適切な解決策のみがあることを忘れないでください。ロックメカニズムのマスターになりたいです！

以上がビジネスにおける楽観主義と悲観的なロックの実用的なアプリケーションのケースの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。