データベース・ロックの同時処理

前言:いくつかの原因ですでに1年以上更新されていないので、最近再びメンテナンスを始めて、それからいくつかの自分の沈殿したものを分かち合います!

一、楽観錠

楽観的なロックを実現するためによく使用されます.
1、表にversionフィールドを追加(デフォルト1)、更新時にversionチェックを同時に追加します.

    update XXX set XXX,version=version + 1 where version =  version( )

この使い方は、フロントエンドでの同時およびリセットを防止するために使用されます.更新時にフロントエンドからバックエンドに移行する必要があることを覚えておいてください.この方法には限界があります.バージョンフィールドには実際の意味はありません.
2、表にステータスフィールドを追加して、前置ステータスチェックとして使用します.例えば、注文書の支払いに成功するには、作成した支払い待ちの注文を支払い済みに更新する必要があります.

update XXX set status = 'PAID' where status = 'UNPAID'

この使い方は、受注センターや中台ビジネスシステムなど広く使われています.
一般的でない楽観的なロックを実現する方法:
3、実現方法は第一点と似ています.私たちの表には更新時間がよくあるからです.gmt_modifiedフィールドで、TIMESTAMP(3)(正確には1 ms)に設定できます.
このような注文書表のいくつかのフィールドを更新するのは、第2の状況ステータスマシンで制御しにくい可能性があります.タイムスタンプで楽観的なロックとして使用するのも良い方法です.

  update XXX set attribute = XXX where gmt_modified = XXX

二、悲観ロック

悲観ロックは簡単に使用しないでください.使用できるものは使用しないでください.悲観ロックは独占ロックなので、残りのタスクはロックされたデータを更新して待っています.使用方法:

select * from XXX where id=1 for update

デフォルトではデータベースの更新操作が自動的にコミットされるため、アプリケーション・レイヤが悲観的なロックを使用する場合は、悲観的なロックを使用する必要がある典型的なシーンがあります.たとえば、1つのプライマリ・オーダーの下に2つのサブオーダーがあり、サブオーダーがキャンセルされた場合は、プライマリ・オーダーのステータスをキャンセルする必要があります.2つのサブ受注は同時に2つの異なるリクエスト呼び出しでキャンセルされ、この場合、悲観的なロックを使用してプライマリ・プライマリ・受注をロックして同時ロックを防止する必要があり、最終的には2つのサブ受注がキャンセルされた場合、プライマリ・受注ステータスはキャンセルにプッシュされます.

三、データベースロックの応用

データベース・ロックは比較的簡単な同時発生防止の有効な方案であり、いくつかのタイミング・タスクによってスケジューリングされたタスクでは、n個のタイミング・タスクを同時に実行する必要がある場合、同時発生を処理するために楽観的なロックの2番目を採用し、明確なステータス・マシンを通じてデータを奪って処理し、同じ文書を繰り返し抽出することができる.以上のように基本的な手段であり、マスターすれば異なるシーンで交差して使用することができます.