これは良いことです: Redisの分散ロックの深い理解につながります

[[375372]]

分散ロックとは何ですか?

Redis に関して言えば、最初に思い浮かぶ機能はデータをキャッシュする機能です。さらに、Redis は単一プロセスと高パフォーマンスの特性を備えているため、分散ロックによく使用されます。

ロックはプログラム内の同期ツールであり、共有リソースに一度に 1 つのスレッドのみがアクセスできるようにするものであることは誰もが知っています。私たちは皆、よく使用する synchronized や Lock などの Java のロックに精通しています。ただし、Java ロックは単一のマシンでのみ有効であり、分散クラスター環境では有効ではありません。このとき、分散ロックを使用する必要があります。

分散ロックは、その名前が示すように、分散プロジェクト開発で使用されるロックです。分散システム間の共有リソースへの同期アクセスを制御するために使用できます。一般的に、分散ロックは次の特性を満たす必要があります。

1. 相互排他: 常に、同じデータに対して分散ロックを取得できるのは 1 つのアプリケーションだけです。

2. 高可用性: 分散シナリオでは、少数のサーバーのダウンタイムが通常の使用に影響することはありません。この場合、分散ロックを提供するサービスをクラスターにデプロイする必要があります。

3. ロックのタイムアウトを防止する: クライアントが積極的にロックを解除しない場合、サーバーは一定時間後に自動的にロックを解除し、クライアントがクラッシュしたりネットワークにアクセスできなくなったりしたときにデッドロックを防止します。

4. 排他性: ロックとロック解除は同じサーバーによって実行される必要があります。つまり、ロック保持者だけがロックを解除できます。追加したロックを他の人がロック解除することはできません。

業界には分散ロック効果を実現できるツールが数多くありますが、その操作はロック、ロック解除、ロックタイムアウトの防止だけです。

この記事は Redis 分散ロックに関するものなので、Redis の知識ポイントに基づいて拡張するのは自然なことです。

ロックを実装するコマンド

まず、Redis コマンドをいくつか紹介します。

1. SETNX、使用法はSETNXキー値

SETNX は「SET if Not eXists」の略語です。設定が成功した場合は 1 を返し、それ以外の場合は 0 を返します。

setnx の使用法

キーロックの値を「Java」に設定した後、別の値に設定すると失敗することがわかります。見た目はシンプルでロックを独占しているように見えますが、鍵に有効期限がないという致命的な問題があります。この方法では、キーを手動で削除するか、ロックを取得した後に有効期限を設定しない限り、他のスレッドがロックを取得することはありません。

この場合、キーに有効期限を追加し、ロックを取得するときにスレッドが直接 2 つの手順を実行できるようにすることができます。

 SETNXキー1
期限切れキー秒数

このソリューションにも問題があります。ロックの取得と有効期限の設定が 2 つのステップに分割されており、これらはアトミック操作ではないためです。ロックの取得は成功しても、時間の設定に失敗する可能性があります。それは時間の無駄ではないでしょうか?

しかし、心配しないでください。Redisの担当者はすでにこの問題を検討しているので、次のコマンドが導入されています。

2. SETEX、使用法 SETEX キーの秒数の値

値 value をキーに関連付け、キーの有効期間を秒数に設定します。キーがすでに存在する場合、SETEX コマンドは古い値を上書きします。

このコマンドは次の 2 つのコマンドに似ています。

セット キー値
EXPIREキー秒数 # 有効期限を設定する

これら 2 つのステップはアトミックであり、同時に完了します。

setexの使用法

3. PSETEX、使用法 PSETEX キーミリ秒値

このコマンドは SETEX コマンドに似ていますが、SETEX コマンドのように秒単位ではなくミリ秒単位でキーの有効期間を設定します。

ただし、Redis バージョン 2.6.12 以降では、SET コマンドでパラメータを使用して、SETNX、SETEX、および PSETEX コマンドと同じ効果を実現できます。

例えば、このコマンド

セット キー値 NX EX 秒

NX および EX パラメータを追加すると、その効果は SETEX と同等になり、これは Redis でロックを取得する最も一般的な方法でもあります。

ロックを解除する方法

ロックを解除するコマンドは簡単で、キーを直接削除するだけです。しかし、前述したように、分散ロックはロック保持者自身によって解放される必要があるため、まず現在ロックを解放しているスレッドが保持者であることを確認してから削除する必要があります。このようにすると、2 つのステップになり、原子性に違反しているように見えます。私たちは何をすべきでしょうか?

慌てる必要はありません。Lua スクリプトを使用して、次のように 2 つのステップを組み立てることができます。

 redis.call( "get" 、KEYS[1]) == ARGV[1]の場合
それから 
 redis.call( "del" ,KEYS[1])を返す
それ以外 
 0を返す
終わり

KEYS[1]は現在のキーの名前であり、ARGV[1]は現在のスレッドのID（またはそれが属するスレッドを識別できる他の固定でない値）になります。これにより、期限切れのロックを保持しているスレッドや他のスレッドが誤って既存のロックを削除することを防ぐことができます。

コードの実装

原理を理解した後は、手動でコードを記述して、Redis 分散ロックの機能を実装できます。この記事の目的は、分散ロックの書き方を教えることではなく、主に原理を説明することなので、擬似コードで実装しました。

最初は、ロックとロック解除の基本的なメソッドを含む redis ロックツールクラスです。

パブリッククラスRedisLockUtil { 
 
    プライベート文字列 LOCK_KEY = "redis_lock" ; 
 
    //キー保持時間、5ms
    プライベートロングEXPIRE_TIME = 5; 
 
    // 待機タイムアウト、1秒
    プライベートロングTIME_OUT = 1000; 
 
    // redis コマンドパラメータ。nx および px のコマンドセットと同等
    プライベートSetParams params = SetParams.setParams().nx().px(EXPIRE_TIME); 
 
    // ローカルの Redis クライアントに接続された Redis 接続プール
    JedisPool jedisPool = new JedisPool( "127.0.0.1" , 6379); 
 
    /**
     * ロック
     *
     * @パラメータID
     * スレッドID、または現在のスレッドを識別できるその他の一意のフィールド
     * @戻る 
     */
パブリックブールロック(文字列id) {
        ロングスタート = System.currentTimeMillis();
        ジェディス jedis = jedisPool.getResource();
        試す {
のために（;;） {
                // SETコマンドはOKを返し、ロックが正常に取得されたことを証明します
                文字列ロック = jedis.set (LOCK_KEY, id, params);
                if ( "OK" .equals(lock)) {
戻る 真実;
                }
                // それ以外の場合はループして待機します。 TIME_OUT 内にロックが取得されない場合、取得は失敗します。
                long l = System.currentTimeMillis() - 開始;
                （l >= TIME_OUT）の場合{
戻る 間違い;
                }
                試す {
                    // しばらくスリープします。そうしないとループが繰り返し失敗します。
                    スレッド.sleep(100);
                } キャッチ (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        ついに
            jedis.close ();
        }
    } 
 
    /**
     * ロック解除
     *
     * @パラメータID
     * スレッドID、または現在のスレッドを識別できるその他の一意のフィールド
     * @戻る 
     */
パブリックブールロック解除(文字列id) {
        ジェディス jedis = jedisPool.getResource();
        //キーのluaスクリプトを削除する
        文字列スクリプト = "if redis.call('get',KEYS[1]) == ARGV[1] then" + " return redis.call('del',KEYS[1]) " + "else"  
            + " 0 を返す " + "終了" ;
        試す {
            文字列結果 =
                jedis.eval(スクリプト、Collections.singletonList(LOCK_KEY)、Collections.singletonList(id)).toString();
戻る  "1" .equals(結果);
        ついに
            jedis.close ();
        }
    }
 }

特定のコード関数のコメントが明確に記述されているので、効果をテストするためのデモクラスを作成できます。

パブリッククラスRedisLockTest {
    プライベート静的RedisLockUtil デモ = 新しい RedisLockUtil();
    プライベートスタティック 整数NUM = 101; 
 
公共 静的void main(String[] args) {
 ( int i = 0; i < 100; i++)の場合{
            新しいスレッド(() -> {
                文字列 id = Thread.currentThread().getId() + "" ;
                ブール値 isLock = demo.lock(id);
                試す {
                 // ロックを取得したら、共有パラメータを減算します
                    if (isLock) {
                        数--;  
                        System.out.println (数値) ;
                    }
                ついに
                 // ロックを解除し、最後に必ずロックを入れてください
                    デモのIDをロック解除します。
                }
            }）。始める（）;
        }
    }
 }

同時実行をシミュレートするために 100 個のスレッドを作成し、実行後の結果は次のようになります。

コード実行結果

ロックの効果が得られ、スレッドの安全性が保証されていることがわかります。

もちろん、上記のコードは単に効果を実現するだけであり、機能は明らかに不完全です。健全な分散ロックには考慮すべき点が多く、実際の設計はそれほど簡単ではありません。

私たちの目標は、原則を学び、理解することだけです。産業グレードの分散ロックツールを手作業で作成するのは非現実的であり、不必要です。同様のオープンソースツール (Redisson) は多数あり、原理も似ており、業界の同業者によって長い間テストされているため、そのまま使用できます。

機能は実現されていますが、実際には設計の観点から見ると、このような分散ロックには大きな欠陥があり、それがこの記事の焦点でもあります。

分散ロックの欠点

1. クライアントの長期ブロックはロックの失敗につながる

クライアント 1 はロックを取得しますが、ネットワークの問題または GC により長時間ブロックされ、ビジネスプログラムが実行される前にロックが期限切れになります。このとき、クライアント 2 も正常にロックを取得できるため、スレッドセーフティの問題が発生する可能性があります。

クライアントが長時間ブロックされました

では、このような異常をどうやって防ぐのでしょうか?最初に解決策について話すのではなく、他の欠陥を紹介してから議論しましょう。

2. Redis サーバーのクロックドリフト問題

Redis サーバーのマシンクロックが進むと、キーは早期にタイムアウトになります。たとえば、クライアント 1 がロックを取得した後、キーは 12:02 に期限切れになりますが、Redis サーバー自体のクロックはクライアントよりも 2 分進んでいるため、キーは 12:00 に無効になります。このとき、クライアント 1 がロックを解除していない場合、複数のクライアントが同時に同じロックを保持する可能性があります。

3. 単一ポイントインスタンスのセキュリティ問題

Redis がシングルマスターモードの場合、このマシンがダウンすると、すべてのクライアントがロックを取得できなくなります。可用性を向上させるために、マスターにスレーブを追加することができます。ただし、Redis のマスターとスレーブの同期は非同期であるため、クライアント 1 がロックを設定した後に、マスターがハングアップし、スレーブがマスターに昇格する可能性があります。非同期レプリケーションの特性により、クライアント 1 によって設定されたロックは失われます。この時点で、クライアント 2 もロックを正常に設定できるため、クライアント 1 とクライアント 2 が同時にロックを取得することになります。

Redis の単一点問題を解決するために、Redis の作者は RedLock アルゴリズムを提案しました。

RedLockアルゴリズム

このアルゴリズムを実装するための前提は、Redis を複数のノードにデプロイする必要があり、これにより単一点障害を効果的に防ぐことができるということです。具体的な実装アイデアは次のとおりです。

1. 現在のタイムスタンプ（ミリ秒）を取得します。

2. まず、キーの有効期間 (TTL) を設定します。この時間以降は自動的に解除されます。次に、クライアントは同じキーと値を使用してすべての Redis インスタンスを設定しようとします。 Redis インスタンスに接続するたびに、TTL よりもはるかに短いタイムアウトを設定します。これは、閉じられた Redis サービスを長時間待つことを避けるためです。そして、次の Redis インスタンスを取得してみます。

たとえば、TTL (有効期限) が 5 秒の場合、ロックを取得するためのタイムアウトを 50 ミリ秒に設定できます。したがって、50 ミリ秒以内にロックを取得できない場合は、ロックは放棄され、次のロックが試行されます。

3. クライアントは、最初のステップの時間と Redis サーバーのクロックドリフトエラーを差し引いた、取得可能なすべてのロックを取得します。この時間差が TTL 時間より短く、ロックを正常に設定したインスタンスの数が >= N/2 + 1 (N は Redis インスタンスの数) の場合、ロックは正常に追加されます。

たとえば、TTL が 5 秒の場合、Redis に接続してすべてのロックを取得するのに 2 秒かかり、その後クロックドリフト (エラーが約 1 秒であると仮定) を差し引くと、ロックの実際の有効時間は 2 秒だけになります。

4. 何らかの理由でクライアントがロックを取得できない場合、すべての Redis インスタンスのロック解除を開始します。

このアルゴリズムによれば、5 つの Redis インスタンスがあると仮定すると、クライアントは 3 つ以上からロックを取得すれば成功したとみなされます。フローチャートのデモンストレーションはおそらく次のようになります。

キーの有効期間

さて、アルゴリズムが導入されました。設計の観点から見ると、RedLock アルゴリズムのアイデアは主に Redis の単一点障害の問題を効果的に防止することであることは間違いありません。さらに、TTL の設計時にはサーバークロックのドリフトのエラーも考慮されるため、分散ロックのセキュリティが大幅に向上します。

しかし、これは本当にそうなのでしょうか?個人的には効果は平均的だと感じています。

まず、RedLock アルゴリズムでは、ロックの有効時間が Redis インスタンスへの接続時間から減算されることがわかります。ネットワークの問題によりこのプロセスに時間がかかりすぎると、ロックに残される有効時間が大幅に短縮されます。クライアントが共有リソースにアクセスできる時間は短く、プログラム処理中にロックが期限切れになる可能性が非常に高くなります。さらに、ロックの有効時間をサーバーのクロックドリフトから減算する必要がありますが、どのくらい減算すればよいのでしょうか?この値が正しく設定されていない場合、問題が発生する可能性が高くなります。

2 つ目のポイントは、このアルゴリズムでは Redis の単一点障害の問題を防ぐために複数のノードの使用を考慮していますが、ノードがクラッシュして再起動すると、複数のクライアントが同時にロックを取得する可能性があるということです。

5つのRedisノードA、B、C、D、Eがあり、クライアント1と2がそれぞれをロックしていると仮定します。

クライアント 1 は A、B、C を正常にロックし、ロックを正常に取得しました (ただし、D と E はロックされませんでした)。
ノード C のマスターがクラッシュしたため、ロックがスレーブに同期されませんでした。スレーブがマスターにアップグレードされた後、クライアント 1 によって追加されたロックは失われました。
この時点でクライアント 2 がロックを取得し、C、D、E をロックします。ロックは正常に取得されます。

この方法では、クライアント 1 とクライアント 2 は同時にロックを取得しますが、プログラムの潜在的なセキュリティリスクは依然として存在します。さらに、これらのノードの 1 つで時間のずれが発生すると、ロックのセキュリティ問題も発生する可能性があります。

したがって、複数のインスタンスの展開によって可用性と信頼性は向上しますが、RedLock は Redis の単一点障害の隠れた危険性を完全に解決するものではなく、クロックドリフトや長期のクライアントブロッキングによって発生するロックタイムアウトの問題も解決しません。ロックのセキュリティリスクは依然として存在します。

結論は

さらに、ロックの絶対的な安全性をどのように確保できるのかと疑問に思う人もいるかもしれません。

これに対して私が言えるのは、ケーキを食べて、ケーキも残しておくことはできないということだけです。分散ロックツールとして Redis を使用する主な理由は、Redis 自体が非常に効率的で単一プロセスであり、高い同時実行性でも十分なパフォーマンスを保証できるためです。しかし、多くの場合、パフォーマンスとセキュリティを十分に考慮することはできません。ロックのセキュリティを確保する必要がある場合は、db や zookeeper などの他のミドルウェアを使用して制御できます。これらのツールはロックのセキュリティを非常によく保証できますが、パフォーマンスは不十分としか言えません。そうでなければ、ずっと前に誰もが使用していたはずです。

一般的に、Redis を使用して共有リソースを制御し、高いデータセキュリティ要件が求められる場合、究極の保証ソリューションは、ビジネスデータに対してべき等制御を実行することです。この方法では、複数のクライアントがロックを取得しても、データの一貫性には影響しません。もちろん、すべてのシナリオがこれに適しているわけではありません。具体的な選択は読者自身が行う必要があります。結局のところ、完璧な技術というものは存在せず、最適なものだけが最良なのです。

<<: もう混乱しないでください。クラウドネイティブをこのように理解できるかもしれない

>>: 新世代のハイブリッドクラウド管理の発表: クラウドジャーニーの成功または失敗はこれに左右されるでしょうか?