ビッグデータの専門家が、Zookeeper と Redis をベースにした分散ロックの実装方法を段階的に説明します。

[[282700]]

分散システムでは、分散ロックを使用して複数のインスタンス間の同期の問題を解決します。たとえば、マスター選出では、分散ロックを取得できる方がマスターとなり、取得できなかった方がスレーブとなります。あるいは、ロックを取得できるインスタンスが特定の操作を実行できる場合もあります。

現在、一般的に使用されている分散ロック実装には、Zookeeper ベースと Redis ベースの 2 つがあります。 Zookeeper と redis も、本番環境で頻繁に使用されるサードパーティ コンポーネントです。以下では、その実装原則を分析します。

分散ロックの実装要件

分散ロックを実装するには、少なくとも次の 3 つの要件を満たす必要があります。

1. 相互に排他的であるため、同じロックを保持できるのは常に 1 つのクライアントのみです。
2. デッドロックは発生せず、保持中のクライアントが異常クラッシュしても、後続のクライアントのロックには影響しません。
3. デバイスをロックした人はロック解除も行う必要があり、ロックとロック解除の両方を同じクライアントが実行する必要があります。

Zookeeper 分散ロック

Zookeeper の分散ロックについて説明する前に、明確にしておく必要がある概念が 2 つあります。

1. 一時ノード: ライフサイクルはリンク サイクルと同じです。たとえば、クライアント リンク A は一時ノード NodeA を作成します。リンク A が閉じられたり、ネットワークが異常切断されたりすると、NodeA も消えます。
2. 連続ノード: ノード名は小さいものから大きいものの順に作成されます。たとえば、最初に 000000001 が作成された場合、次に作成されるノードには 000000002 が割り当てられます。

Zookeeper の分散ロック実装の原則は、一時的なシーケンシャル ノードを使用することです。一般的なプロセスは次のとおりです。

• 各クライアントが特定の機能をロックすると、Zookeeper によって指定されたディレクトリに一意の一時シーケンス ノードが生成されます。
• すべての一時ノードの中でシーケンス番号が最も小さいノードが現在のロックの保持者になります。
• ロックを解除するときは、保持している一時ノードを削除するだけです。

たとえば、ロック プロセス中に、すべてのクライアントは /lock ディレクトリの下に一時ノードを作成します。作成した一時ノードが /lock ディレクトリ内の最小のノードであることがわかった場合、ロックを正常に取得できます。それ以外の場合は、自分より小さいノードの中で最大のノードを監視します。

自身よりも小さいノードの中で最大のノードを監視する目的は、「集団ショック」効果を回避することです。集団ショックとは、ロックの解放によって待機中のすべてのクライアントが起動してしまうのを防ぐためのものですが、ロックを取得できるのは 1 つのクライアントだけです。

ロックを解除するには、作成した一時シーケンス ノードを削除するだけです。全体のプロセスフローチャートは次のとおりです。

利点: ロックは非常に安全で、飼育員のデータは簡単に失われません。ユーザーにとって使いやすい。

デメリット: パフォーマンス消費量が高い。一時ノードは動的に生成および削除される必要があるため、クラスターの負荷が高いときに一時ノードが消えるまでに時間差（通常 1 分以内）が生じます。

Redis 分散ロック

Redis の分散ロック実装は Zookeeper よりも複雑で、Redis 単一インスタンスとマルチインスタンス (マスター マスター) の実装方法に分かれています。

なお、Redis をマスタースレーブ構造で展開する場合、ロックの取得と解放はマスターからのみ要求でき、これは基本的に単一インスタンスの実装原理と同じであることに注意してください。そうしないと、マスターとスレーブを切り替えるときに複数の人が同じロックを取得する可能性があります。

例えば：

クライアント A はマスターからロックを取得します。

A によって作成されたキーをスレーブに書き込む前に、マスター ノードがクラッシュしました。 （マスタースレーブ同期は非同期操作です）

スレーブノードがマスターノードになります。

スレーブは A がロックを保持しているという情報を持っていないため、B も A が保持しているのと同じロックを取得します。

Redis シングルインスタンス実装ソリューション

次のコマンドでロックを取得します。

リソース名をランダム値に設定 NX PX 30000

このコマンドの機能は、このキーが存在しない場合にのみその値を設定し (NX の機能、つまり存在しない)、タイムアウトを 30000 ミリ秒に設定し (PX の機能)、このキーの値を my_random_value に設定することです。この値は、ロック要求を取得するすべてのクライアント間で一意である必要があります。

キー値のタイムアウト期間は、「ロック有効期間」とも呼ばれます。ロックが自動的に解除される時間です。

この実装ソリューションは、ダウンタイムが保証されない非分散型の単一ポイント環境に適用できます。

Redis クラスター実装ソリューション (Redlock アルゴリズム)

アルゴリズムの分散バージョンでは、N 個の Redis マスター ノードがあり、これらは完全に独立しており、データを同期するためにレプリケーションや分散調整アルゴリズムを必要としないと想定しています。

ここで N = 5 と仮定すると、クライアントがロックを取得するプロセスは次のようになります。

• 現在の時刻をミリ秒単位で取得します。
• ポーリングは、同じキーを使用して N 個のノードのロックを要求します。 (マスターノードが使用されていない場合に次のマスターを迅速に要求できるように、各要求のタイムアウトは短く設定されます)。
• マスターノードの半数以上 (ここでは 3 個) でロックが正常に取得された場合、クライアントは 2 番目のステップでロックの要求に費やされた時間を計算します。ロック解除時間より短い場合、ロックは正常に取得されたとみなされます。
• ロックが正常に取得された場合、ロックが自動的に解放されるまでの時間は、初期ロック解放時間からロックの要求にかかる時間を引いた時間と同じになります。
• ロックの取得に失敗した場合 (成功したロックの数がマスターの数の半分を超えていないか、要求時間 > ロック解放時間)、クライアントは各マスター ノードのロックを解放します。

ロックを正常に取得するノードの数がマスター ノードの数の半分を超える必要があるという考えは、おそらく Zookeeper の paxos アルゴリズムに基づいています。

指摘する必要があるもう 1 つの点は、クライアントがデータの取得に失敗した場合、複数のクライアントが同時に再試行して失敗することを回避するために、いつでも遅延後に再試行する必要があるということです。

利点: 高性能

デメリット: 単一インスタンスでは単一点の問題が発生する、複数インスタンスのマスター/スレーブ切り替えによりデータ損失が発生する、マスター/マスター クラスター モードの実装が複雑になる。

ZookeeperとRedisに基づく分散ロックについて専門家が解説します