ロックの基本概念からRedis分散ロックの実装まで

最近、分散トランザクション、分散フレームワーク、ZooKeeper、SpringCloud など、分散に関する問題が広く言及されるようになりました。この記事では、まずロックの概念を確認し、次に分散ロックを紹介し、Redis で分散ロックを実装する方法について説明します。

1. ロックの基礎知識

まず、私たちの仕事と研究におけるロックの概念を見直してみましょう。

なぜ最初にロックについて説明し、次に分散ロックについて説明しなければならないのでしょうか?

ロックの役割は、共有リソースへのマルチスレッドアクセスによって発生するスレッドセーフティの問題を解決することであることは誰もが知っています。しかし、日常生活で鍵はあまり使われません。ロックの概念や基本的な使用法についてよくわかっていない友人もいるかもしれませんので、まずロックについて説明し、次に分散ロックについて詳しく説明します。

[[286783]]

チケット販売の小さな例を見てみましょう。たとえば、全員が dota2 ti9 のチケットを入手しようとした場合、チケットがロックされていないとどのような問題が発生するでしょうか?この時点でコードは次のようになります。

パッケージスレッド;
 java.util.concurrent.TimeUnitをインポートします。 
 
公共 クラスチケット{ 
 
 /**
 * 初期在庫
* */  
整数ticketNum = 8 ; 
 
公共  void減らす( int num){
 // 在庫が十分かどうかを判定する 
 if ((チケット番号 - 番号) >= 0 ){
試す{
 TimeUnit.MILLISECONDS.sleep( 200 );
 }キャッチ(InterruptedException e){
 e.printStackTrace();
 }
チケット番号 -= 番号;
 System.out.println(Thread.currentThread().getName() + "販売に成功しました"  
 + num + "張、残り" + ticketNum + "張チケット" );
 }それ以外{
 System.err.println(Thread.currentThread().getName() + "販売されていません"  
 + num + "張、残り" + ticketNum + "張チケット" );
 }
 } 
 
公共 静的  void main(String[] args)はInterruptedExceptionをスローします{
チケットticket = new Ticket();
 //チケットを取得するために 10 個のスレッドを開始します。論理的に考えると、チケットを入手できない人が 2 人いるはずです。  
 ( int i = 0 ; i < 10 ; i++) {
新しいスレッド(() -> ticket.reduce( 1 )、 "user" + (i + 1 )).start();
 }
スレッドをスリープ状態にします(1000L)。
 } 
 
 }

コード分析: ここには 8 つの ti9 チケットがあり、同時にチケットを取得するために 10 個のスレッド (つまり、10 人のユーザーをシミュレート) が設定されています。グラブが成功した場合は成功と表示され、失敗した場合は失敗と表示されます。当然ながら、8 人がゲームを奪取することに成功し、2 人が失敗したはずです。実行結果を見てみましょう:

実行結果は期待と一致しないことがわかりました。 10 人全員がチケットを購入したため、スレッドセーフティの問題が発生したことになります。それで、何が原因だったのでしょうか?

理由は、複数のスレッド間に時間差があるためです。

図に示すように、残っているチケットは 1 つだけですが、両方のスレッドによって読み取られた残りのチケットは 1 です。これは、スレッド A が在庫を変更する前に、スレッド B がチケットを正常に取得したことを意味します。

どうすれば解決できるでしょうか?同期キーワードを追加すればうまくいくことは誰もが知っていると思います。 1 つのスレッドが Reduce メソッドを実行すると、他のスレッドは待機キューでブロックされるため、複数のスレッド間で共有変数の競合は発生しません。
例えば
たとえば、ジムに行って運動するとき、多くの人が同時に 1 台のマシンを使用したり、1 台のトレッドミルで走ったりすると、大きな問題が発生し、全員が互いに争うことになります。ジムのドアに鍵を付ければ、鍵を持っている人だけがジムに入って運動することができ、他の人はドアの外で待つことになるので、フィットネス機器の取り合いを避けることができます。コードは次のとおりです。
公共  同期した  void減らす( int num){
 // 在庫が十分かどうかを判定する 
 if ((チケット番号 - 番号) >= 0 ){
試す{
                TimeUnit.MILLISECONDS.sleep( 200 );
            }キャッチ(InterruptedException e){
                e.printStackTrace();
            }
            チケット番号 -= 番号;
            System.out.println(Thread.currentThread().getName() + "販売に成功しました"   
            + num + "张,REST" + ticketNum + "张票" );
        }それ以外{
            System.err.println(Thread.currentThread().getName() + "販売されていません"   
                    + num + "張、残り" + ticketNum + "張チケット" );
        }
    }

操作結果:

予想通り、2名がチケットを入手できませんでした。我々の目標は達成されたようだ。

2. ロックパフォーマンスの最適化

2.1 ロック保持時間を短縮する

実際、私たちの日常生活の理解によれば、ジム全体で運動している人が 1 人だけということはあり得ません。したがって、1 台のマシンをロックするだけで済みます。たとえば、1 人がランニングをしているときに、もう 1 人は他のスポーツを行うことができます。

チケットシステムの場合、在庫変更操作のコードをロックするだけで済みます。他のコードは引き続き並行して実行できるため、ロック保持時間が大幅に短縮されます。コードは次のように変更されます。

公共  voidロックによる削減( int num){
ブールフラグ = false ;
同期済み(チケット番号) {
 if ((チケット番号 - 番号) >= 0 ){
チケット番号 -= 番号;
フラグ = true ;
 }
 }
 if (フラグ){
 System.out.println(Thread.currentThread().getName() + "販売に成功しました"  
 + num + "张,REST" + ticketNum + "张票" );
 }
それ以外{
 System.err.println(Thread.currentThread().getName() + "販売されていません"  
 + num + "张,REST" + ticketNum + "张票" );
 }
チケット番号 == 0の場合{
 System.out.println( "所要時間" + (System.currentTimeMillis() - startTime) + "ミリ秒" );
 }
 } 
 
これを行う目的は、CPU リソースを最大限に活用し、コードの実行効率を向上させることです。
ここでは、2 つの方法で時間を出力します。
公共 同期した  void減らす( int num){
 // 在庫が十分かどうかを判定する 
 if ((チケット番号 - 番号) >= 0 ){
試す{
 TimeUnit.MILLISECONDS.sleep( 200 );
 }キャッチ(InterruptedException e){
 e.printStackTrace();
 }
チケット番号 -= 番号;
チケット番号 == 0の場合{
 System.out.println( "所要時間" + (System.currentTimeMillis() - startTime) + "ミリ秒" );
 }
 System.out.println(Thread.currentThread().getName() + "販売に成功しました"  
 + num + "张,REST" + ticketNum + "张票" );
 }それ以外{
 System.err.println(Thread.currentThread().getName() + "販売されていません"  
 + num + "张,REST" + ticketNum + "张票" );
 }
 }

確かに、コードの一部だけをロックすると、コードの実行効率が大幅に向上します。

したがって、スレッドの安全性の問題を解決した後、ロック後のコード実行効率も考慮する必要があります。

2.2 ロックの粒度を下げる

たとえば、最近公開された映画には『哨戒班』と『スパイダーマン』の 2 つがあります。支払い購入プロセスをシミュレートし、メソッドを待機させて、CountDownLatch の await メソッドを追加します。実行結果は次のとおりです。

パッケージスレッド;
 java.util.concurrent.CountDownLatchをインポートします。 
 
公共 クラスムービー {
プライベート 最終的なCountDownLatchラッチ =新しいCountDownLatch( 1 );
 //悪魔の哨戒 
プライベート整数 babyTickets = 20 ; 
 
 //スパイダーマン 
プライベート整数spiderTickets = 100 ; 
 
公共 同期した  void showBabyTickets()は InterruptedExceptionをスローします{
 System.out.println( "魔少年哨戒のチケットの残り枚数は: " + babyTickets);
 //買う 
ラッチを待機します。
 } 
 
公共 同期した  void showSpiderTickets()は InterruptedExceptionをスローします{
 System.out.println( "スパイダーマンの残りのチケットの数は: " + spiderTickets);
 //買う 
 } 
 
公共 静的  void main(String[] args) {
ムービー movie = new Movie();
新しいスレッド(() -> {
試す{
映画.showBabyTickets();
 }キャッチ(InterruptedException e){
 e.printStackTrace();
 }
 }, "ユーザーA" ).start(); 
 
新しいスレッド(() -> {
試す{
映画.showSpiderTickets();
 }キャッチ(InterruptedException e){
 e.printStackTrace();
 }
 }, "ユーザーB" ).start();
 } 
 
 }

実行結果:

悪魔少年ネザの残り投票数: 20

Nezha チケットの購入時にブロックすると、Spiderman チケットの購入に影響することが判明しました。実際、これら 2 つのムービーは互いに独立しているため、ロックの粒度を下げて、ムービーオブジェクト全体のロックを 2 つのグローバル変数のロックに変更する必要があります。変更されたコードは次のとおりです。

公共  void showBabyTickets()は InterruptedExceptionをスローします{
同期済み(babyTickets) {
 System.out.println( "魔少年哨戒のチケットの残り枚数は: " + babyTickets);
 //買う 
ラッチを待機します。
 }
 }
公共  void showSpiderTickets()は InterruptedExceptionをスローします{
同期済み(spiderTickets) {
 System.out.println( "スパイダーマンの残りのチケットの数は: " + spiderTickets);
 //買う 
 }
 }

実行結果:

悪魔少年ネザの残り投票数: 20

スパイダーマンの残り投票数: 100

これで、2 つの映画のチケットを購入しても、お互いに影響がなくなります。これはロックを最適化する 2 番目の方法であり、ロックの粒度を減らします。ちなみに、Java 並行性パッケージの ConcurrentHashMap は、大きなロックを 16 個の小さなロックに変換し、セグメント化されたロックを通じて効率的な並行安全性を実現します。

2.3 ロックの分離

ロック分離は、一般的に読み取り/書き込み分離と呼ばれます。ロックは読み取りロックと書き込みロックに分けられます。読み取りロックはブロックする必要はありませんが、書き込みロックでは同時実行の問題を考慮する必要があります。

3. ロックの種類

フェアロック: ReentrantLock
不公平なロック: Synchronized、ReentrantLock、cas
悲観的ロック: 同期
楽観的ロック: cas
排他ロック: Synchronized、ReentrantLock
共有ロック: セマフォ

ここでは、各タイプのロックの概念を一つ一つ説明することはしません。自分で学ぶこともできます。ロックは、バイアスロック、軽量ロック、重量ロックに分類することもできます。

4. Redis 分散ロック

ロックとロックの最適化の基本的な概念を理解した後、分散ロックの概念について詳しく説明します。

上の図は私たちが構築した分散環境を示しています。チケット購入アイテムは 3 つあり、1 つのインベントリに対応します。各システムには複数のスレッドがあります。上記の通り、在庫変更操作はロックされています。これら 6 つのスレッドのスレッドセーフティは保証できますか?

もちろん違います。各チケット購入システムにはそれぞれ独立した JVM プロセスがあるため、同期を追加しても 1 つのシステムのスレッドの安全性は保証されますが、分散スレッドの安全性は保証されません。

したがって、この問題を解決するには、3 つのシステムすべてに共通するミドルウェアが必要です。

ここでは、分散ロックとして Redis を選択します。複数のシステムが Redis に同じキーを設定します。設定は、キーが存在しない場合にのみ成功し、キーはいずれかのシステムの一意の識別子に対応します。システムがリソースへのアクセスを終了すると、キーは削除され、ロックを解除する目的が達成されます。

4.1 分散ロックで注意すべきこと

1) 相互排他性

一度にロックを取得できるのは 1 つのクライアントのみです。

これは理解しやすいですね。すべてのシステムのうち 1 つのシステムだけがロックを保持できます。

2) デッドロック防止

クライアントがロックを保持したままクラッシュし、ロックを解放しない場合、他のクライアントはロックを取得できず、デッドロックが発生します。したがって、クライアントがロックを解除することを確認する必要があります。

Redis では、デッドロックが発生しないようにロックの有効期限を設定できます。

3) ロックホルダーでロックを解除する

ベルを結んだ人が、それを解く必要があります。システムのロックとロック解除には同じクライアントを使用する必要があります。クライアント A のスレッドによって追加されたロックは、クライアント A のスレッドによってロック解除される必要があります。クライアントは別のクライアントのロックを解除できません。

4) 再入性

クライアントがオブジェクトロックを取得した後、クライアントはオブジェクトのロックを再度取得できます。

4.2 Redis分散ロックプロセス

Redis 分散ロックの具体的なプロセス:

1) まず、Redis キャッシュのプロパティを使用して、Redis にキーと値のペアを設定します。キーはロックの名前です。すると、クライアントの複数のスレッドがロックを競い合うことになります。競争が成功した場合、値はクライアントの一意の識別子に設定されます。

2) ロックを競合するクライアントは、次の 2 つのことを行う必要があります。

ロックの有効時間を設定する目的は、デッドロックを防ぐことです（非常に重要）

有効期間の長さは、ビジネスニーズに基づいて継続的なストレステストを通じて決定する必要があります。

ロック所有者がロックを解除できるように、クライアントに一意の ID を割り当てます (非常に重要)

したがって、ここでの値は一意の識別子 (uuid など) に設定されます。

3) 共有リソースにアクセスする

4) ロックを解除します。ロックを解除する方法は2つあります。 1 つ目は、有効期間が経過すると自動的にロックを解除することです。 2 番目は、一意の識別子に基づいて、ロックを解除する権限があるかどうかを最初に判断することです。識別子が正しい場合、ロックは解除されます。

4.3 ロックとロック解除

4.3.1 ロック

1) setnx コマンドロック

存在しない場合は設定します。Redis コマンド setnx を使用します。 setnx の意味は、ロックが存在しない場合にのみロックが正常に設定されるということです。

2) デッドロックを防ぐためにロックの有効期間を設定します。

ロックには 2 つの手順が必要です。何か問題が起きないか考えてみませんか？

ロック後にクライアントが突然クラッシュしたらどうなりますか?そうすると、ロックは有効期間のないロックとなり、デッドロックが発生する可能性があります。これが起こる可能性は非常に低いですが、問題が発生すると非常に深刻なので、これら 2 つの手順を 1 つにまとめる必要があります。

幸いなことに、Redis 3.0 ではこれら 2 つの命令が 1 つの新しい命令に統合されました。

Jedis の公式ドキュメントのソースコードを見てみましょう。

パブリック文字列セット(文字列キー、文字列値、文字列nxxx、文字列expx、長い時間) {
これは.checkIsInMultiOrPipeline() です。
 this .client.set(キー、値、nxxx、expx、時間);
戻る これは.client.getStatusCodeReply() です。
 }

これが私たちが望んでいるものです!

4.3.2 ロック解除

ロックを保持しているかどうかを確認します（一意の識別子を決定します）。
ロックを外します。

ロック解除も 2 段階のプロセスであり、ロック解除の原子性も確保され、2 つの手順が 1 つに結合される必要があります。

これは Redis では実現できず、Lua スクリプトでのみ実現できます。

 Redis.call( "get" 、key==argv[ 1 ])の場合
Redis.call( "del" ,key)を返します
それ以外 戻る  0終了

これは、ロックを保持しているかどうかを判定し、ロックを解除する Lua スクリプトです。

Lua スクリプトがアトミックなのはなぜですか? Lua スクリプトは eval() 関数を使用して jedis によって実行されるため、実行されると完全に実行されます。

5. Redis分散ロックコードの実装

公共 クラスRedisDistributedLockはLockを実装します{
 //コンテキスト、現在のロックホルダーIDを保存します 
プライベートThreadLocal<String> lockContext =新しいThreadLocal<String>(); 
 
 //デフォルトのロックタイムアウト 
プライベート 長時間= 100 ; 
 
 //再入可能性 
プライベートスレッド所有者スレッド; 
 
パブリックRedisDistributedLock() {
 } 
 
公共  voidロック() {
 while (!tryLock()){
試す{
スレッド.スリープ( 100 );
 }キャッチ(InterruptedException e){
 e.printStackTrace();
 }
 }
 } 
 
公共 ブール型tryLock() {
 tryLock(time,TimeUnit.MILLISECONDS)を返します。
 } 
 
公共 ブール型tryLock(長い時間、TimeUnit単位){
文字列 id = UUID.randomUUID().toString(); //各ロック保持者には一意のIDが割り当てられます 
スレッド t = Thread.currentThread();
ジェディス jedis = new Jedis( "127.0.0.1" , 6379 );
 //ロックが存在しない場合にのみロックし、ロックの有効時間を設定します 
 if ( "OK" .equals(jedis.set( "lock" ,id, "NX" , "PX" , unit.toMillis(time)))){
 //ロックを保持している人のID  
ロックコンテキストを設定します。 ①
 //現在のスレッドを記録する 
所有者スレッドを設定します。 ②
戻る 真実;
 }それ以外 所有者スレッド == t の場合
//ロックは再入可能であるため、現在のスレッドがすでにロックを保持しているかどうかを判断する必要があります。  
戻る 真実;
 }それ以外{
戻る 間違い;
 }
 } 
 
プライベート  void setOwnerThread(スレッドt){
この.ownerThread = t;
 } 
 
公共  voidロック解除() {
文字列スクリプト = null ;
試す{
ジェディス jedis = new Jedis( "127.0.0.1" , 6379 );
スクリプト = inputStream2String(getClass().getResourceAsStream( "/Redis.Lua" ));
 lockContext.get() がnullの場合
//誰もロックを保持していない 
戻る;
 }
 //ロックを削除 ③  
 jedis.eval(スクリプト、Arrays.asList( "lock" )、Arrays.asList(lockContext.get()));
ロックコンテキストを削除します。
 }キャッチ(例外 e) {
 e.printStackTrace();
 }
 } 
 
 /**
 * InputStreamを文字列に変換する
* @paramは
* @戻る
* @throwsIOException 例外をスローします
*/  
パブリックString inputStream2String(InputStream is) はIOExceptionをスローします{
 ByteArrayOutputStream baos =新しいByteArrayOutputStream();
整数i = - 1 ;
 ((i = is.read()) != - 1 )の間{
 baos.write(i);
 }
 baos.toString()を返します。
 } 
 
公共  void lockInterruptibly()はInterruptedExceptionをスローします{ 
 
 } 
 
 public条件 newCondition() {
戻る ヌル;
 }
 }

コンテキストグローバル変数を使用して、ロックを保持している人の UUID を記録します。ロックを解除するときは、ロックを解除できるかどうかを判断するために、uuid を Lua スクリプトにパラメータとして渡す必要があります。
分散ロックの再入可能性を実現するには、現在のスレッドを記録する必要があります。現在のスレッドがロックを保持している場合も、ロックは成功したとみなされます。
ロック解除中のアトミック性を保証するために、eval 関数を使用して Lua スクリプトを実行します。

6. 分散ロックの比較

6.1 データベースベースの分散ロック

1) 実装

ロックを取得するときにデータを挿入し、ロックを解除するときにデータを削除します。

2) デメリット

データベースに障害が発生すると、ビジネスシステムは利用できなくなります。
有効期限を設定しないとデッドロックが発生します。

6.2 Zookeeper に基づく分散ロック

1) 実装

ロックすると、指定されたノードのディレクトリに新しいノードが作成され、ロックが解除されるとこの一時ノードは削除されます。ハートビート検出機能があるため、デッドロックが発生せず、より安全です。

2) デメリット

パフォーマンスは平均的で、Redis ほど効率的ではありません。

それで：

パフォーマンスの観点から: Redis > zookeeper > データベース
信頼性（セキュリティ）の観点から： zookeeper > Redis > データベース

七。結論

この記事では、ロックの基本概念から始め、複数のスレッドが共有リソースにアクセスするときに発生する可能性のあるスレッドセーフティの問題を提案し、次にロックを追加することでスレッドセーフティの問題を解決します。この方法ではパフォーマンスが低下するため、ロック保持時間の短縮、ロック粒度の低減、ロックの分離という 3 つの方法でロックを最適化する必要があります。

次に、分散ロックの 4 つの特性について説明します。