問題現象
H5 ゲーム、オンライン ユーザーからアカウント残高情報が取引フローと一致しないというバグが報告されています。これは、データベースの同時更新の問題として考えることができ、具体的な原因を特定して解決策を提供します。
シナリオの説明
バックグラウンドがユーザーに代わって現金を再チャージまたは引き出すとき、同時実行性が高い場合、100 元の再チャージがあり (現在のユーザー残高が 50 元であると仮定します)、同時にユーザーは 10 元を賭けます。このとき、2 つのアカウント変更情報を生成するために使用されます。結果は、「
1 変更金額 10 変更残高 40 内容「ベット」
2 変更金額 100 変更残高 140 内容「リチャージ」
または
1 変更金額 100 変更残高 150 内容」になります。 「リチャージ」
2 変更金額 10 変更残高 140 内容「ベット」
ですが、
アカウント変更情報テーブルでは
1 変更金額 100 変更残高 150 内容「リチャージ」 2 変更金額 10 変更残高 40 内容「ベット」 ここでは、変更
後の残高 140 となります。
ユーザー変更残高エラー。
環境説明
mysql5.6 + innodb + php5.6
シナリオシミュレーション
具体的な操作は
select Money from user where id=x;
update usercoinlog set bdmoney = just found Balance + change amount WHERE userid=x;
問題が発生しました 原因
箇所
バックグラウンドチャージとユーザーベットを同時に行った場合、同時に見つかった残高が50となっており、更新時に50を基準記録として使用すると上記エラーが発生します！
解決策
オプション 1
データベース ロックを増やします。ただし、これにはいくつかの欠点があります。後で紹介します。
解決策 2:
クエリ時にフィールド値 (更新数など) を取得します。更新時には、テーブル セット Money=Money-50、更新回数 = 更新回数 + 1 (userid=123、更新回数 = クエリを実行したところ) を更新します。回数、例えば同時に送信した2つのクエリの結果は50ですが、必ず実行更新が連続するので、このときMoney-50の更新回数も同時に+1されます。更新操作により、更新の数がクエリされた回数と等しくないことがわかり、更新が無効です
この問題は完璧に解決されます！
拡張された思考
更新の問題は同じですが、挿入の問題は同じままです。
解決
各人は、各号に 1 つのレコードのみを持つことができます。号番号は各人に一意ですが、全員に一意ではありません。+id は、現在の期間における各人の一意の値です。新しいフィールドを作成できます。書き込み時に現在の発行番号 +id を書き込みます。高同時書き込み中にこのフィールドの値が存在すると、書き込みは失敗します。例外がスローされ、更新操作が実行されます。複数の列を組み合わせて一意にすることもできるため、一意のフィールドをさらに追加する必要はありません。
個人的な謙虚な意見: Paizhuan へようこそ!_間違いの修正へようこそ