Alibaba第2回インタビュー：Redis分散ロックの有効期限が切れたが、業務が完了していない場合はどうすればよいですか？

[[420487]]

インタビュアー: あなたのシステムでは分散ロックをどのように実装していますか?

私：Redis 分散ロックを使用しました。具体的なアプローチとしては、バックエンドがリクエストを受信した後、分散ロックを追加します。ロックが成功すると、ビジネスが実行されます。ロックが失敗した場合は、ロックを待機するか、要求を拒否します。業務実行が完了するとロックが解除されます。

インタビュアー：具体的にどのようなコマンドが使われているのか教えていただけますか？

私: SETNX コマンドは次のように使用します。

 SETNX キー名値

設定が成功した場合は 1 が返されます。それ以外の場合は 0 が返されます。次の図に示すように、クライアント 1 はロックを正常にロックしましたが、クライアント 2 はロックを取得できませんでした。

インタビュアー：この設定に問題はありますか？正常にロックされたクライアントがクラッシュした場合はどうなりますか?

私：例えば、上の図のクライアント 1 がクラッシュした場合、ロックを解除することはできません。有効期限を設定できます。コマンドは次のとおりです。

セット キー値 [EX 秒] [PX ミリ秒] NX

インタビュアー：有効期限を設定した場合、業務が完了していないのにRedisロックの有効期限が切れてしまった場合はどうすればいいでしょうか？

私：鍵を交換しなければなりません。

インタビュアー：どのように機能するのか教えていただけますか？

私: ロックの設定に成功したら、ウォッチドッグを起動して、一定時間 (たとえば 10 秒) ごとに現在の分散ロックを更新します。つまり、現在のキーのタイムアウトを 10 秒ごとにリセットします。コマンドは次のとおりです。

 EXPIRE <キー> <秒数>

全体のプロセスは次のとおりです。

インタビュアー: ウォッチドッグを実装するにはどうすればいいですか?

私: クライアントが正常にロックされると、スケジュールされたタスクが開始され、10 秒ごとに (できれば構成サポートを使用して) ビジネスが処理されたかどうかを確認できます。検出の基礎は、分散ロックのキーがまだ存在するかどうかを判断することです。そうであれば更新されます。

インタビュアー: 現在のスレッドが処理されている場合、このキーは別のクライアントによって書き込まれますか?

私: クライアントごとに clientID を指定し、VALUE に clientID プレフィックスを追加できます。このように、ロックを更新するときに、現在の分散ロックの値のプレフィックスを判断して、それが現在のクライアントに属しているかどうかを判断できます。一致する場合はロックを更新し、そうでない場合は何もしません。

インタビュアー：再ロック機能はご自身で実装されたのですか？

私：私たちはredissonの分散ロックソリューションを使用しています。 redisson を使用して分散ロックを取得するのは非常に簡単です。コードは次のとおりです。

 RLock ロック = redisson.getLock( "クライアントロック" );
ロック。ロック();
試す {
    //加工事業
} キャッチ (例外 e) {
    //例外を処理する
ついに
    ロックを解除します。
 }

具体的な原則は次のとおりです。クライアント 1 が正常にロックした場合、この分散ロックのデフォルトのタイムアウトは 30 秒です (Config.lockWatchdogTimeout を通じて変更できます)。ロックが正常に追加されると、ウォッチドッグが開始されます。ウォッチドッグは、クライアント 1 がまだロック キーを保持しているかどうかを 10 秒ごとにチェックするバックグラウンド スレッドです。そうであれば、ロックキーの寿命が延長されます。拡張操作は、ロック キーのタイムアウトを再度 30 秒に設定することです。

インタビュアー：redisson ではタイマーはどのように実装されていますか？

私: redisson タイマーは、netty-common パッケージの HashedWheelTime を使用して実装されています。

インタビュアー: クライアント1がクラッシュした場合、分散ロックは更新できますか?

私：分散ロックの更新はクライアント上で実行されるため、クライアント1がダウンすると更新スレッドが動作できなくなり、ロックを更新できなくなります。この時点で、分散ロックは削除され、他のクライアントが取得できるようにする必要があります。

インタビュアー: クライアント 1 がクラッシュした場合、他のクライアントはロックを取得するのに 30 秒待たなければなりません。ロックをすぐに削除する方法はありますか?

私: client1 がダウンしているため、タイムアウト期間後にロックが自動的に削除されるまで待つことしかできません。すぐに削除したい場合は、センチネルがすべての Redis クライアントのリストを維持できるようにセンチネル メカニズムを追加するなどの追加作業を行う必要があります。センチネルはクライアントがダウンしているかどうかを定期的に監視します。ダウンタイムが検出されると、クライアントのロックは直ちに削除されます。以下のように表示されます。

ここでのセンチネルは、Redis のセンチネルではなく、クライアントの障害を検出するためにビジネス システム自体によって作成されたセンチネルです。

インタビュアー：redisson を使用しない場合、分散ロック継続をどのように実装しますか?たとえば、springboot2.0 で使用されるデフォルトの Redis クライアントは Lettuce です。

私：Lettuce は redisson のようなウォッチドッグ メカニズムを提供していないため、ロックの更新はビジネス システム自体で実装する必要があります。これは次の手順で実現できます。

1. ロック コマンドについては、Spring パッケージ内の分散ロック コードを参照します。ロックが存在し、現在のクライアントによって追加された場合は、ロックを更新します。ロックが存在しない場合は、ロックを追加します。コードは次のとおりです。

プライベート静的最終文字列 OBTAIN_LOCK_SCRIPT =
 "ローカル lockClientId = redis.call('GET', KEYS[1])\n" +
 "lockClientId == ARGV[1] の場合\n" +
 " redis.call('PEXPIRE', KEYS[1], ARGV[2])\n" +
 " true を返す\n" +
 "そうでなければ lockClientId ではない\n" +
 " redis.call('SET', KEYS[1], ARGV[1], 'PX', ARGV[2])\n" +
 " true を返す\n" +
 "終了\n" +
 "falseを返す" ;

2. ロックを HashMap などのデータ構造に保存します。スケジュールされたタスクは定期的にマップをスキャンし、各ロックを更新します。コードは次のとおりです。

プライベート最終 Map<String, RedisLock> locks = new ConcurrentHashMap<>();

3. 再ロックコマンド

プライベート静的最終文字列 RENEW_LOCK_SCRIPT =
 "ローカル lockClientId = redis.call('GET', KEYS[1])\n" +
 "lockClientId == ARGV[1] の場合\n" +
 " redis.call('PEXPIRE', KEYS[1], ARGV[2])\n" +
 " true を返す\n" +
 "終了\n" +
 "falseを返す" ;

4. 現在のクライアントによってロックが追加された場合はロックを更新し、そうでない場合は失敗します。

ロック継続コードを定期的に実行するスケジュールされたタスクを記述します。

 redisTemplate.execute ( renewLockScript 、
                        Collections.singletonList(lockKey)、クライアントID、
                        文字列.valueOf(expireAfter));

インタビュアー：この質問はここまでにしましょう。次の質問に移りましょう...