Webアプリケーションの同時問題処理のちょっとした経験

2491 ワード

Webアプリケーションでは、1つのアカウントにN以上の数値に関するフィールドがあります.例えば1つの口座の金額、ポイントなどです.これらのフィールドは増減に関連します.テスト環境であれば、プログラマーまたはテストで手動でクリックします.普通は問題が見つからない.
いったん正式な環境に上がると.実際のユーザーが操作すると、わけのわからない金額と流水記録が一致しない場合が発生しやすい.十分な経験がなければ、問題を調べるのは難しい.
業界では3つのソリューションが一般的に使用されています
  • 1.メッセージキュー
  • の使用
  • 2.悲観ロック
  • 3.楽観ロック
  • ブロガー自身が小さな会社にいるため、メッセージキューの実際の操作経験はありません.だからこの文章は主に後の2種類を討論します.
    悲観ロック
    名前からすれば、必ず併発する可能性があると考え、ソースからデータの乱れを防ぐことです.
    一般的な処理方法:
    データベースのロック.SQLサーバのRowLockやMysqlのfor updateのように
    利点:プログラムに問題がない場合はデータの問題が全く発生しない
    欠点:パフォーマンスがあまりよくなく、データベース・ロックはリソースを非常に消費する行為です.
    楽観ロック
    楽観ロックは悲観ロックとは逆です.同時問題はないと考える.修正を提出するときだけ、現在のデータに修正の兆候があるかどうかをチェックします.
    一般的な処理方法:
    データベースにカラムを追加します.現在変更されているバージョン番号を記録します.変更するたびに、バージョン番号が以前にクエリーされたものと一致しているかどうか、一致している場合は判断します.修正に成功し、一致せず、修正できません.クエリー・データを再ロードし、判断操作を繰り返す必要があります.
    疑似コードは次のとおりです.
    ndex = 1  //      
    while(true){
    selct id ,money ,version from table  //      
    money+=1; //    
    update table set money = money,version = (version+1) where id = @id and version = version //      ,        
    if(update){
    break;
    }
    //
    
    index+=1;
    if(index>3){
    break;
    }
    
    }

    楽観的なロックの利点:無ロック操作を実現でき、悲観的なロックよりもパフォーマンスが向上します.
    楽観的なロックの欠点:汚い読み取りの問題があり、クエリの回数は悲観的なロックの数倍になります.
    この2つの方法を理解すれば、各中小規模アプリケーションを縦横に使用することができます.