Redis で分散ロックを実装する方法

Ah Fen は最近 Redis に魅了されています。なぜ？ Redis は確かに非常に強力だと感じます。メモリベースのシステムであるキー値ストレージデータベースには、実は非常に多くの機能があります。 Ah Fen も Redis を本格的に学びたいと思っています。やはり、Redis は面接時に非常にプラスになるポイントだと言えます。

分散ロック

分散ロックはなぜ必要なのでしょうか?

現在、多くの大規模プロジェクトはすべて分散ベースであり、分散シナリオにおけるデータの一貫性の問題は常に無視できない問題となっています。分配に関するCAP理論をご存知ですか？

CAP 理論によれば、分散システムは一貫性、可用性、および分断耐性を同時に満たすことはできず、最大でもそのうちの 2 つしか満たすことができません。

私たちのシステムは、最終的には常に最終的な一貫性を満たしますが、この最終的な一貫性のために、分散トランザクションについて質問する人もいれば、分散ロックに焦点を当てる人もいます。

分散ロックの種類

分散ロックのデータベース実装
分散ロックを実装するためのキャッシュ
Zookeeperは分散ロックを実装する

しかし、Ah Fen は分散ロックを実装するためにキャッシュを使用することを選択しました。これは、私たちのプロジェクトで最も一般的に使用されている Redis です。 Redis は、次のようなさまざまな場所で使用できます。

セッションキャッシュ
メッセージキュー
分散ロック
メッセージの公開と購読
商品リスト、レビューリスト

今日は、Redis を使用して分散ロックを実装し、その使い方を学びます。

準備

1. Jedis jar パッケージを使用する準備をし、jar パッケージをプロジェクトにインポートします。

 <! --ジェディス-->  
 <依存関係>
    <groupId>redis.clients</groupId>
    <artifactId>ジェダイ</artifactId>
    <バージョン>2.9.0</バージョン>
 </依存関係>

ツールクラスを書いてみましょう。

パブリッククラスRedisPoolUtil { 
 
    プライベート静的最終文字列 LOCK_SUCCESS = "OK" ;
    プライベート静的最終文字列 SET_IF_NOT_EXIST = "NX" ;
    プライベート静的最終文字列 SET_WITH_EXPIRE_TIME = "PX" ; 
 
    プライベート RedisPoolUtil(){}
    /**
     *
     * @param ジェディス
     * @param lockKey ロック
     * @param requestId リクエストフラグ
     * @param expireTime タイムアウト
     * @戻る 
     */
公共 静的ブール型 tryGetDistributedLock(Jedis jedis、String lockKey、String requestId、 int expireTime) { 
 
        文字列結果 = jedis.set (lockKey、requestId、SET_IF_NOT_EXIST、SET_WITH_EXPIRE_TIME、expireTime); 
 
        if (LOCK_SUCCESS.equals(結果)) {
戻る 真実;
        }それ以外{
            試す{
                スレッド.sleep(10); // 100ミリ秒スリープ
            }catch(例外 e){
                e.printStackTrace();
            }
        }
戻る 間違い;
    }
 }

jedis.set(lockKey、requestId、SET_IF_NOT_EXIST、SET_WITH_EXPIRE_TIME、expireTime);このロック姿勢こそが最も理解する必要があるもので、そうでなければ使い方が分からないでしょう。

key: ロックキーは、実際には一意のフラグに相当します。異なるフラグを使用して、異なるビジネスをロックできます。

requestId: これは実際にデバイスをロックするために使用されるリクエストを識別するために使用されます。分散ロックでは、ロックとロック解除は同じクライアントによって実行されなければならないということを知っておく必要があります。

もう 1 つの典型的なケースは、B が A のロックを解除し、解除の混乱が生じるというものです。同じリクエストを追加しない場合は、スレッド A がビジネスを処理し、ロックを実行します。ロックは 5 秒後に期限切れになり、スレッド B はロックを取得しようとします。 A が 5 秒以上ビジネスを処理すると、A はロックの解除を開始しますが、B はこの時点でロックを検出しないため、ロックします。 A が対応する業務の処理を終了していない場合、処理を終了した後にロックを解除すると、B が追加したロックがそのまま解除されるか、ロックがまったく解除されなくなります。

SET_IF_NOT_EXIST: 名前が示すように、キーが存在しない場合は、Set 操作を実行します。存在する場合は何もせず、ロックも行いません。

SET_WITH_EXPIRE_TIME: 期限切れにするかどうか

expireTime: キーの有効期限を設定します。あなたのビジネスがロックされ、後続のビジネスがそれをロックしたい場合、ロックを保持したまま期限が切れた後にロックを解除しないと、問題が発生します。

上記のメソッドでは、tryGetDistributedLock が通常使用するロックメソッドです。

ロック解除

公共 静的ブール型 releaseDistributedLock(Jedis jedis、String lockKey、String requestId) { 
 
        文字列スクリプト = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end" ;
        オブジェクト結果 = jedis.eval(script、Collections.singletonList(lockKey)、Collections.singletonList(requestId)); 
 
        if ( "OK" .equals(結果)) {
戻る 真実;
        }
戻る 間違い; 
 
    }

このスクリプトを見ると、少し奇妙に感じるかもしれません。実はこれは Lua スクリプトであり、Lua スクリプトの意味は比較的単純です。

まずロックに対応する値を取得し、それがrequestIdと等しいかどうかを確認します。
等しい場合はロックを解除します（ロック解除）
eval() メソッドを実行する

実はこのとき、del で削除できないのかと言う人もいます。試してみてください。このように書くと、リーダーがあなたの足を折るでしょう。

最初にロックの所有者を判別せずにロックを解除するこの方法では、どのクライアントでもいつでもロックを解除できるようになります。つまり、ロックを追加しなくても、開けることができるのです。これはどのように機能するのでしょうか?

ここに誰でも使えるコードがあります。比較的シンプルですが、プロジェクトで直接使用できます。

試す{
ブール値の結果 = RedisPoolUtil.tryGetDistributedLock(jedis, "xxxxx" , uuid, 5000); 
 
 if(結果) {
        xxxx コード スニペット
}それ以外{ 
 
 } 
 
 }キャッチ（）{ 
 
 }ついに{
 RedisPoolUtil.releaseDistributedLock(jedis, "xxxxx" , uuid);
 }

分散ロックの要件

相互排他性を満たす。つまり、一度にロックを保持できるのは 1 つのクライアントのみであり、複数のクライアントがロックを保持できるわけではありません。
デッドロックは発生しません。つまり、分散ロックを実装する場合、ロックが解除されていないと他のクライアントがロックできないとは言えません。他のクライアントのロックに影響を与えないようにする必要があります。
ロックとロック解除は同じクライアントが行う必要があります