私たちの毎日の仕事では、一部の企業は、厳密数と順序を制御するために必要とされる、例えば、私は上記のマイクロ手紙を具現化ロジックについて今日言いたいです。
ビジネスシナリオ：
マイクロチャネルのユーザーが撤退要求を開始し、ユーザーが脱退、要求インタフェースの量を入力します！その後、我々は、このテーブル、富裕層の運営会社をスキャンタイミングタスクの撤退の要求を生成します。
だからここでの問題はありますか？ユーザーは、ほぼ同期要求で、$ 6、二度要求を開始撤退するとします。コードの検証は、レコード（10を取り出しているので、6よりも大きい）、手術台にこの時間は、これは撤退の量を減らすことができ、それは負の数に還元することができる二離脱の次に生産を通じて現金の量の2倍を提供することができますテーブルに、定期的なタスクは、それが2つのプレイお金を実施し、離れて血液の損失を席巻しました！だから、これを回避するために必要です！
それを解決する方法は何ですか！この場合のように、一般的な考え方は（楽観的ロックは概念のみ、ノー特定のロックです）を解決するために楽観的ロックの方法を使用することです、もちろんあなたも、更新暴力ロックのために、このレコードを悲観的ロックを使用して、変更することができます提出。しかし、このような行動は、比較的低い効率だろう。
定義によるロックは、より楽観的であるので、楽観的、私はこれは、更新の時間が直接逃げるために問題があるユーザーに伝える競合がある場合にのみ、矛盾するデータを検出しなくなるまで、それが提出され、通常の状況下では起こらないと信じていますインクルード
だから、具体的に何を意味するのでしょうか？（have_money - 6） - 離脱更新ユーザ設定have_money =（6 have_money）のビジネス・ロジックにマイクロチャネル> 0、ID = 2。
だから、この文は現金残高の不足を置くことができることを示し、失敗した場合、あなたが現金引き出し要求レコードを追加する必要はありません。このアプローチは、別の方法は、私たちが百度を所有することができます。この形式のバージョン番号を形成することで、楽観的ロック式の条件です。