Java はさまざまなロックを提供していますが、なぜ分散ロックが必要なのでしょうか?

[[357636]]

現在、単一プロジェクト構造は基本的に残っておらず、分散クラスターやマイクロサービスがほとんどです。サーバーが複数あるため。資源共有の問題は避けられません。リソース共有であるため、同時実行の問題は避けられません。これらの問題に対して、Redis は分散ロックという優れたソリューションも提供します。この記事では、分散ロックがなぜ必要なのかというトピックについて主に説明します。

少し前に、グループ内の仲間が、分散ロックでほとんどの運用上の問題を解決できるのであれば、Java が提供するロックは何の役に立つのかと質問しました。分散ロックを直接使用したほうが良いのではないでしょうか?私はこの質問についてよく考え、最初は同様の答えがあるかどうかオンラインで調べました。それから私はそれについて考えました。この問題を解決するには、本質から分析する必要があります。

よし、車に乗って出発しよう。

1. はじめに

これは分散ロックであるため、サーバーが 1 つだけではなく、複数存在する可能性があります。例を使って段階的に説明します。あるウェブサイトにフラッシュセール商品があり、まだ 100 個残っているとします。すると、陝西省、江蘇省、チベットなどの人々がこのイベントを見て、狂ったように買い始めるのです。このフラッシュセール商品の数量値が Redis データベースに保存されていると仮定します。

ただし、異なる地域のユーザーはフラッシュセールに異なるサーバーを使用します。これにより、クラスター アクセス メソッドが形成されます。

Redis を統合するために Springboot を使用します。

2. プロジェクトの準備

（1）POM依存関係を追加する

<依存関係>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </依存関係>
        <依存関係>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>テスト</scope>
        </依存関係>
        <依存関係>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-redis</artifactId>
        </依存関係>
        <依存関係>
            <グループ ID>org.apache.commons</グループ ID>
            <artifactId>コモンズプール2</artifactId>
        </依存関係>

（２）属性設定を追加する

# Redis データベース インデックス (デフォルトは 0)
 spring.redis.データベース= 0
 # Redis サーバーのアドレス
spring.redis.host=ローカルホスト
# Redis サーバー接続ポート
spring.redis.port=6379
 # Redis サーバー接続パスワード (デフォルトでは空)
 spring.redis.パスワード=
 # 接続プール内の最大接続数（負の値は制限なしを意味します）デフォルトは 8 です
spring.redis.lettuce.pool.max -アクティブ=8
 # 接続プールの最大ブロッキング待機時間（負の値は制限なしを意味します）デフォルトは -1 です
spring.redis.lettuce.pool.max -wait =-1
 # 接続プール内のアイドル接続の最大数。デフォルトは8です
spring.redis.lettuce.pool.max -idle =8
 # 接続プール内のアイドル接続の最小数。デフォルトは0です
spring.redis.lettuce.pool です。最小アイドル=0

（3）新しい設定パッケージを作成し、RedisConfigクラスを作成する

@構成
パブリッククラスRedisConfig {
    @ビーン
パブリックRedisTemplate<String, Serializable >
            redisTemplate(レタス接続ファクトリー接続ファクトリー) {
        RedisTemplate<String, Serializable > redisTemplate = new RedisTemplate<>();
        redisTemplate.setKeySerializer(新しい StringRedisSerializer());
        redisTemplate.setValueSerializer(新しい GenericJackson2JsonRedisSerializer());
        redisTemplate.setConnectionFactory(接続ファクトリー);
 redisTemplateを返します。
    }
 }

（4）新しいコントローラーを作成し、Mycontrollerクラスを作成します。

 @レストコントローラ
パブリッククラスMyController{
    オートワイヤード
    プライベート StringRedisTemplate stringRedisTemplate;
    @GetMapping( "/テスト" )
パブリック文字列deduceGoods(){
 int商品 = Integer .parseInt(stringRedisTemplate.opsForValue().get( "商品" ));
実商品数= 商品数-1;
        もし商品>0の場合{
            stringRedisTemplate.opsForValue() です。 ( "商品" 、実商品 + "" )を設定します。
戻る  「商品は正常に購入されましたが、まだ次の商品が残っています: " + realGoods + "個" ;
        }それ以外{
戻る  「商品は売り切れました。次回のイベントにようこそ」 ;
        }
    }
 }

非常にシンプルな統合チュートリアル。ポートは 8080 です。プロジェクトをコピーし、ポートを 8090 に変更し、負荷分散として nginx を使用してクラスターを構築します。これで環境が整理されました。以下の分析を始めましょう。

3. 分散ロックが必要なのはなぜですか?

フェーズ1: ネイティブアプローチの採用

ポート 8080 にアクセスするために複数のスレッドを使用します。ロックがないため、この時点で同時実行の問題が確実に発生します。したがって、この商品は共有リソースであり、複数のスレッドによってアクセスされるため、Java のさまざまなロックをすぐに思い浮かべることができますが、その中で最も有名なのは synchronized です。したがって、上記のコードを最適化したほうがよいでしょう。

フェーズ2: 同期ロックの使用

この時点でコードを変更します。

 @レストコントローラ
パブリッククラスMyController{
    オートワイヤード
    プライベート StringRedisTemplate stringRedisTemplate;
    @GetMapping( "/テスト" )
パブリック文字列deduceGoods(){
        同期された（これ）{
 int商品 = Integer .parseInt(stringRedisTemplate.opsForValue().get( "商品" ));
実商品数= 商品数-1;
            もし商品>0の場合{
                stringRedisTemplate.opsForValue() です。 ( "商品" 、実商品 + "" )を設定します。
戻る  「商品は正常に購入されましたが、まだ次のものが残っています: " + realGoods + "個" ;
            }それ以外{
戻る  「商品は売り切れました。次回のイベントにようこそ」 ;
            }
        } 
 
    }
 }

ご覧のとおり、現在、 synchronized キーワードを使用してロックを追加しているため、複数のスレッドが同時にアクセスするときにデータの不整合やその他の問題が発生しません。このアプローチは、単体構造では確かに役立ちます。現在、単一の構造を持つプロジェクトは非常に少なく、大部分はクラスター化されています。この時点で同期は機能しなくなります。なぜ同期が機能しないのですか?

フラッシュセール製品にアクセスするためにクラスター アプローチを使用します (nginx が負荷分散を行います)。データの不一致が表示されます。つまり、 synchronized キーワードのスコープは実際にはプロセスであり、このプロセスの下のすべてのスレッドをロックできます。ただし、マルチプロセスは不可能です。フラッシュセール商品の場合、この値は固定です。ただし、各地域にサーバーが存在する可能性があります。このように、異なる地域のサーバーは異なり、アドレスも異なり、プロセスも異なります。したがって、同期ではデータの一貫性を保証することはできません。

フェーズ3: 分散ロック

上記の synchronized キーワードでは、複数のプロセスのロック メカニズムを保証することはできません。この問題を解決するには、Redis 分散ロックを使用できます。では、コードをもう一度変更してみましょう。

 @レストコントローラ
パブリッククラスMyController{
    オートワイヤード
    プライベート StringRedisTemplate stringRedisTemplate;
    @GetMapping( "/テスト" )
パブリック文字列deduceGoods(){
      ブール値の結果 = stringRedisTemplate.opsForValue().setIfAbsent( "lock" , "Feng Dongdong" );
      if(!結果){
戻る  「他の人はそれを即座に殺しているので入ることができません」 ;
      }
 int商品 = Integer .parseInt(stringRedisTemplate.opsForValue().get( "商品" ));
実商品数= 商品数-1;
      もし商品>0の場合{
          stringRedisTemplate.opsForValue() です。 ( "商品" 、実商品 + "" )を設定します。
          システム。 out .println( "商品の購入に成功しました。残りのアイテムは: " + realGoods + "items" );
      }それ以外{
          システム。 out .println( "商品は売り切れました。次のイベントへようこそ" );
      }
      stringRedisTemplate.delete ( "lock" ) ;
戻る  "成功" ;
    }
 }

とても簡単です。文章を追加して判断するだけです。実際、setIfAbsent メソッドの機能は、redis の setnx と同じです。つまり、現在のキーがすでに存在する場合、操作は実行されず、false が返されます。現在のキーが存在しない場合は、操作できます。最後に、他のユーザーがインスタント キル操作を実行できるように、このキーを放すことを忘れないでください。

もちろん、これは単なる基本的な例です。実際、分散ロックを実装するには多くの手順があり、多くの落とし穴が指摘されていません。いくつか解決してみましょう:

フェーズ4: 分散ロックの最適化

（１）第一の落とし穴：フラッシュセール商品では例外が発生し、分散ロックが解除できない

  パブリック文字列deduceGoods()は例外をスローします{
     ブール値の結果 = stringRedisTemplate.opsForValue().setIfAbsent( "lock" , "Feng Dongdong" );
     if(!結果){
戻る  「他の人はそれを即座に殺しているので入ることができません」 ;
     }
     試す {
 int商品 = Integer .parseInt(stringRedisTemplate.opsForValue().get( "商品" ));
実商品数= 商品数-1;
        もし商品>0の場合{
           stringRedisTemplate.opsForValue() です。 ( "商品" 、実商品 + "" )を設定します。
           システム。 out .println( "商品の購入に成功しました。残りのアイテムは: " + realGoods + "items" );
       }それ以外{
           システム。 out .println( "商品は売り切れました。次のイベントへようこそ" );
       }
    }ついに {
       stringRedisTemplate.delete ( "lock" ) ;
    }
戻る  "成功" ;
 }

この時点では、try ステートメントと finally ステートメントを追加するだけです。ロックは最終的には削除する必要があります。

（２）２つ目の落とし穴：フラッシュセールに時間がかかり、他のユーザーが待てない

パブリック文字列deduceGoods()は例外をスローします{
    stringRedisTemplate.expire( "lock" ,10, TimeUnit.MILLISECONDS);
    ブール値の結果 = stringRedisTemplate.opsForValue().setIfAbsent( "lock" , "Feng Dongdong" );
    if(!結果){
戻る  「他の人はそれを即座に殺しているので入ることができません」 ;
    }
    試す {
 int商品 = Integer .parseInt(stringRedisTemplate.opsForValue().get( "商品" ));
実商品数= 商品数-1;
       もし商品>0の場合{
           stringRedisTemplate.opsForValue() です。 ( "商品" 、実商品 + "" )を設定します。
           システム。 out .println( "商品の購入に成功しました。残りのアイテムは: " + realGoods + "items" );
       }それ以外{
           システム。 out .println( "商品は売り切れました。次のイベントへようこそ" );
       }
    }ついに {
       stringRedisTemplate.delete ( "lock" ) ;
    }
戻る  "成功" ;
 }

これに有効期限を追加します。つまり、10 ミリ秒以内にフラッシュ セールが成功しない場合は、フラッシュ セールが失敗したことを意味し、次のユーザーが置き換えられます。

（３）３番目の落とし穴：同時実行性の高いシナリオでは、フラッシュセールが長くなりすぎてロックが永久に無効になる

先ほど設定したロックの有効期限は 10 ミリ秒です。ユーザーのフラッシュセール時間が 15 ミリ秒の場合、そのユーザーがフラッシュセールに成功する前に他のユーザーが参加する可能性があることを意味します。このような状況が頻繁に発生すると、製品の購入に成功するまでに多数のユーザーが流入する可能性があります。他のユーザーが事前にロックを解除したが、現在のユーザーはまだフラッシュセールに成功していない可能性があります。これは最終的にデータの不整合につながります。解決方法をご覧ください:

パブリック文字列deduceGoods()は例外をスローします{
    文字列ユーザー= UUID.randomUUID().toString();
    stringRedisTemplate.expire( "lock" ,10, TimeUnit.MILLISECONDS);
    ブール値の結果 = stringRedisTemplate.opsForValue().setIfAbsent( "lock" , user );
    if(!結果){
戻る  「他の人はそれを即座に殺しているので入ることができません」 ;
    }
    試す {
 int商品 = Integer .parseInt(stringRedisTemplate.opsForValue().get( "商品" ));
実商品数= 商品数-1;
       もし商品>0の場合{
           stringRedisTemplate.opsForValue() です。 ( "商品" 、実商品 + "" )を設定します。
           システム。 out .println( "商品の購入に成功しました。残りのアイテムは: " + realGoods + "items" );
       }それ以外{
           システム。 out .println( "商品は売り切れました。次のイベントへようこそ" );
       }
    }ついに {
       if( user .equals(stringRedisTemplate.opsForValue().get( "lock" ))){
                 stringRedisTemplate.delete ( "lock" ) ;
       }
    }
戻る  "成功" ;
 }

つまり、ロックを削除するときに、それが現在のスレッドであるかどうかを判断します。そうであれば削除します。そうでない場合は削除しません。こうすることで、他のスレッドが侵入しても、ロックがランダムに削除され、混乱が生じることはありません。

さて、ここまでは分散ロックの理由について基本的に紹介しました。 Redisson は分散ロックにおいて素晴らしい仕事をしました。次の記事でも、Redisson に焦点を当てて、分散の実装方法とその背後にある原則を紹介します。

この記事はWeChat公式アカウント「Yugong Yaoyishan」から転載したものです。下のQRコードからフォローできます。この記事を転載する場合は、Yugongyaoyishanの公式アカウントまでご連絡ください。