高洛峰2017-04-17 16:29:11
アプリケーションのシナリオは次のようになります:
ユーザー残高を変更する前に、変更による問題を恐れて誤ってユーザー残高を 0 などに変更してしまいました。
代わりに、最初にユーザー アカウント変更テーブルにレコードを挿入し、次にアカウント変更テーブルからデータを取得してユーザー残高フィールドを更新することを選択します。
この行動を慣用句で表現してください:「恐れて正しい道を選択しない」
ユーザー残高を変更するときの問題が心配なので、ユーザー アカウント変更テーブルを挿入するときの問題も心配する必要があると考えたことはありますか? アカウント変更テーブルを確保するために別のテーブルが必要ですか?もう一方の時計は誰が保証してくれるのでしょうか？
実際には、正しい解決策を知っている必要があります。 2 つの安全でないメソッドを使用して 1 つの安全なメソッドを作成するのではなく。そうすることで、安全なメソッドが得られなかっただけでなく、安全でないメソッドが 2 つ得られたことになります。
正しい方法は、ユーザーの貸借対照表を直接変更し、排他的ロックを追加することです。例:
リーリー
伊谢尔伦2017-04-17 16:29:11
それがデータの損失を引き起こすかどうかはわかりませんが、マルチスレッドの同時実行の場合、テーブルに挿入した場合でも、後のデータが前のデータを上書きする可能性が非常に高いです。まず、複数のスレッドでは機能しません。後続のスレッドが最初に挿入される可能性があります。
したがって、作成者は mysql のトランザクション機能を有効にすることをお勧めします。詳細については、この質問を参照してください。
https://segmentfault.com/q/10...