Redisの作者と分散マスターが戦い、最大の勝者はメロンを食べるネットユーザーだった

背景

面接では、履歴書に Redis について記載するかどうかに関わらず、基本的に避けられない話題です。

この記事で議論するレッドロックの神々の戦いの問題を紹介するために、私たちは一連のインタビューを経なければなりません:

1. 分散ロックに Redis を使用する場合に注意すべき問題はありますか?

2. Redis を 1 か所にデプロイすると、どのような問題が発生しますか?

3. では、単一ポイントの問題をどのように解決する予定ですか?

4. マスタースレーブモードなどのクラスターモードでは問題はありますか?

5. クラスター モードが信頼できない問題を Redis がどのように解決するかをご存知ですか?

6. Redlock について簡単に紹介していただけますか?

7. Redlock の何が問題だと思いますか?

明らかに、上記は面接でよく聞かれる質問です。途中には他の多くの Redis 検査ポイントを挿入できるため、ここでは詳しく説明しません。

シングルポイント Redis は分散ロックには信頼性がないため、Redis クラスター モードに基づく分散ロック ソリューションが登場しました。

Redis クラスター モードに基づく分散ロック ソリューションはまだ信頼性が低いため、Redis の作成者は Redlock ソリューションを提案しました。

Redis の作者が提案した Redlock ソリューションは、別の分散システムの専門家からは信頼できないとみなされたため、両者の間で争いが始まりました。

この戦いをきっかけに、さらなる議論が巻き起こった。

この戦いは決着がつかないほど接戦で、最終的な勝者はいない。最大の勝者は誰かを選ぶとしたら、それは番組をただ見ているネットユーザーたちだろう。なぜなら、番組をただ見ているネットユーザー（私のような）は、この2人の偉大な選手の対決から多くのことを学べるからです。

完璧に思えるアイデアも、よくよく考えてみると、それほど完璧ではないということを深く実感させられます。

したがって、この記事は次の 5 つのモジュールで説明します。

まず最初にアドバイスをさせてください。この記事には約 12,000 語ありますので、注意してお読みください。読み終えなくても構いません。ただ「いいね！」していただくことが私にとって最大の励みになります。素晴らしい！

シングルポイントRedis

私の経験によると、面接で Redis について話すと、友人の 90% が「Redis は私たちのプロジェクトでホット データをキャッシュするために使用されます」と言います。

すると、面接官は必ずこう質問します。

キャッシュに Redis を使用する以外に、Redis のどのような用途を見たことがありますか?

次に、80% の友人がこう言うでしょう: 分散ロックにも Redis を使用しました。

(もちろん、Redis にはキャッシュや分散ロック以外にも多くのトリックがありますが、この記事ではそれらについて重点的に扱いません。興味があれば、自分で学ぶことができます。)

すると面接官はこう言います。

次に、Redis に基づくロックのロックと解除の詳細について説明してください (または疑似コードを書いてください)。

面接官はロックのロックと解除の詳細について話していることに注目してください。悪魔は細部に宿る。

この質問をすることで、面接官は次の重要な点を聞きたいと考えています。

ポイント 1: アトミック コマンド ロック。一部の「古い」記事では、Redis のロック操作は、最初にキーを設定し、次にキーの有効期限を設定すると説明されているためです。このように記述する基本的な理由は、アトミック コマンド ロック操作が Redis の初期バージョンではサポートされていないためです。非アトミック操作によってどのような問題が発生するかを説明する必要はありませんよね?わからない場合は戻って通知を待ちます。

バージョン 2.6.12 以降では、次のコマンドを Redis に送信することで、アトミック ロック操作を実装できます。

SETキー ランダム値 NX PX 30000

ポイント2: 値を設定するときは random_value を入れます。ただ「OK」と答えるのではなく。

まず、上記のコマンドのいくつかのパラメータの意味を説明します。

random_value: クライアントによって生成されるランダムな文字列であり、十分に長い期間にわたってすべてのクライアントからのすべてのロック取得要求の中で一意である必要があります。

NX: 設定するキー値が存在しない場合にのみ設定操作が成功できることを示します。これにより、最初に要求したクライアントのみがロックを取得でき、ロックが解除されるまで他のクライアントはロックを取得できなくなります。

PX 30000: このロックの自動有効期限が 30 秒であることを示します。もちろん、30 秒は単なる例であり、クライアントは適切な有効期限を選択できます。

値をランダムな文字列に設定する理由を説明します。これも3番目の重要なポイントです。

ポイント3: value の値は、主にロックをより安全に解除するために乱数に設定されます。ロックを解除する際には、キーが存在するかどうか、またキーに対応する値が指定した値と同じかどうかを確認する必要があります。それらが同じである場合にのみロックを解除できます。ここでは、取得、判断、削除という 3 つの操作があることがわかります。アトミック性を保証するには、Lua スクリプトを使用する必要があります。

(基本的に、これらの重要なポイントに答えることができれば、面接官は次の質問に進みます。これらはポイントを獲得するための通常のウォームアップの質問なので、覚えておいてください。)

クラスターモード

面接官は次のように質問します。

先ほどの議論の後、ロックを取得および解放するためのより良い方法がすでにあります。単一の Redis インスタンスに基づいており、この単一のインスタンスが常に利用可能であると仮定すると、この方法は十分に安全です。この Redis ノードがクラッシュしたらどうなるでしょうか?

この問題に関しては、実際に Redlock について直接話すことができます。しかし、慌てないでください。豊富な知識（質問に対する熱意ある準備）を示すには、まず Redis クラスターについて話す必要があります。次のように言うことができます:

ノード障害による問題を回避するために、Redis クラスター方式を使用して Redis の高可用性を実現できます。

Redis クラスタ モードには、マスター スレーブ モード、センチネル モード、クラスタ モードの 3 種類があります。

マスタースレーブモードでは、スレーブノードにデータのコピーが存在することが保証されますが、マスターノードに障害が発生した場合は、スレーブノードをマスターノードに手動で切り替える必要があります。非常にシンプルですが、実際の運用環境ではほとんど使用されません。

センチネル モードは、マスター スレーブ モードのアップグレード バージョンです。このモードでは、異常に対応するマスターノードが主観的または客観的にオフラインになり、マスタースレーブ切り替えが行われます。高い可用性を確保できます。

クラスター モードでは高い同時実行性が保証されます。クラスター全体ですべてのデータを共有し、異なるキーが異なる Redis に配置されます。各 Redis はスロットの一部に対応します。

（上記の3つのモードも面接の焦点です。それらについては語るべきことがたくさんあると言えます。これらはこの記事の焦点では​​ないので、詳細には説明しません。主な意味は、面接中に関連する質問に遭遇し、これらのことを知っていることを示す必要があるということです。これらはすべて面接のルーチンです。）

上記のクラスター モードでは、ノードが非同期で通信するため、依然として問題が残ります。ロックがマスター ノードに追加されたばかりで、データがまだスレーブに同期されていない場合。このとき、マスター ノードはハングアップし、そのロックは失われます。新しいマスターが登場した後 (マスター/スレーブ モードの手動切り替えまたはセンチネル モードのフェイルオーバー プロセス)、同じロックが再度取得される可能性があり、ロックが 2 回取得されるシナリオが発生します。

ロックが2回解除されたため、安全ではなくなりました。安全なロックは、分散されているかどうかに関係なく、一度に 1 つのクライアントによってのみ保持されます。

レッドロックについて

上記の問題を解決するために、Redis の作者は Redlock と呼ばれるアルゴリズムを提案しました。

Redis の分散環境では、N 個の Redis マスターが存在すると想定します。これらのノードは互いに完全に独立しており、マスター スレーブ レプリケーションやその他のクラスター調整メカニズムは存在しません。

単一の Redis インスタンスでロックを安全に取得および解放する方法についてはすでに説明しました。このメソッドは、N 個のインスタンスのロック取得と解放に使用されるようにします。

次の例では、同時にクラッシュしないように、それぞれ 5 台のサーバー上で実行される 5 つの完全に独立した Redis マスター ノードがあると想定しています。

公式ウェブサイトによると、クライアントがロックを取得するには、次の 5 つの手順を実行する必要があることがわかります。

ステップの説明ソース: http://redis.cn/topics/distlock.html

1. 現在の Unix 時間をミリ秒単位で取得します。

2. 同じキーとランダム値を使用して、N 個のインスタンスから順番にロックを取得しようとします。ステップ 2 では、Redis にロックを設定するときに、クライアントはロックの有効期限よりも短いネットワーク接続と応答のタイムアウトを設定する必要があります。たとえば、ロックの自動有効期限が 10 秒の場合、タイムアウトは 5 ～ 50 ミリ秒にする必要があります。これにより、サーバー側の Redis がすでにクラッシュしているにもかかわらず、クライアントが応答結果を待機している状況を回避できます。サーバーが指定された時間内に応答しない場合、クライアントはできるだけ早く別の Redis インスタンスを試す必要があります。

3. クライアントは、現在の時刻からロックが取得された時刻 (手順 1 で記録された時刻) を引いて、ロックを取得するために使用された時刻を取得します。ロックが Redis ノードの過半数 (ここでは 3 つのノード) から取得され、使用された時間がロックの有効期限よりも短い場合にのみ、ロックが正常に取得されたと見なされます。

4.ロックが取得された場合、キーの実際の有効期間は、有効期間からロックの取得に使用された時間を差し引いたものになります (手順 3 で計算された結果)。

5. 何らかの理由でロックの取得に失敗した場合（少なくとも N/2+1 個の Redis インスタンスでロックが取得されていないか、ロックの取得時間が有効時間を超えている場合）、クライアントはすべての Redis インスタンスのロックを解除する必要があります（一部の Redis インスタンスが正常にロックされていない場合でも）。

上記の手順から、ほとんどのノードが正常に動作できる限り、Redlock の正常な動作が保証されることがわかります。これにより、これまでのシングルポイント Redis の場合に発生していた非同期通信によるノード障害やロック障害の問題を解決できます。

しかし、障害再起動後のロックセキュリティの問題は依然として解決されていません。次のシナリオを考えてみましょう。

3 つのノード A、B、C があります。

1. クライアント 1 は A と B を正常にロックします。C のロックは失敗しました。

2. このとき、ノード B がクラッシュして再起動しますが、永続化戦略により、クライアント 1 の B 上のロックは永続化されません。クライアント 2 は同じロックを適用する操作を開始し、B と C を正常にロックします。

3. この時点で、クライアント 1 とクライアント 2 の両方によって保持されている同じロックが再び表示されます。

(次は、Redis の永続化戦略についてお話しします。これは、知識ポイントが満載です)

たとえば、Redis の AOF 永続化メソッドは、デフォルトで 1 秒に 1 回ディスクに書き込みます。これは fsync 操作です。そのため、最悪の場合、1 秒分のデータが失われる可能性があります。

もちろん、データが変更されるたびに fsync 操作を実行するように設定することもできます (fsync=always)。ただし、これにより Redis のパフォーマンスが大幅に低下し、設計コンセプトに違反することになります。 (私もこのように使われているのを見たことがありません。あまりに珍しいのかもしれません。)

また、fsync を実行してもデータは失われないと思いますか?実際のシステム環境は複雑であり、Redis の範囲を超えています。サーバーまたはシステムの問題になっています。

したがって、マーフィーの法則によれば、上記の例のように、ノードの再起動によってロックが失敗する可能性は常にあります。

この問題を解決するために、 Redis の作者は遅延再起動の概念を提案しました。

つまり、ノードがクラッシュした後、すぐに再起動するのではなく、再起動する前に一定時間待つことになります。待機時間はロック有効期限 (TTL) よりも長くする必要があります。この目的は、このノードが参加しているすべてのロックが再起動前に期限切れになるようにすることです。これは、後続のロック操作に参加する前に以前のアカウントをキャンセルすることと同じです。

しかし、問題があります。待機期間中、このノードは外部に公開されません。その後、ほとんどのノードがダウンすると、待機状態になります。これにより、システム内のロックは TTL 時間内に正常にロックできなくなるため、システムが使用できなくなります。

Redlock アルゴリズムについて注目すべきもう 1 つの点は、ロック解除操作です。

ロックを解除する場合、すべてのノードに対してロック解除操作を開始する必要があります。これを実行する目的は、ロック フェーズ中にノードがロック要求を受信して​​正常に設定するが、クライアントに返された応答パケットが失われ、クライアントがロックが成功しなかったと判断するという問題を解決することです。したがって、ロックを解除する場合は、すべてのノードに対してロック解除操作を開始する必要があります。

これは通常の慣行ではないと思うかもしれません。

詳細はこんな感じです。言われてみれば、特に特別なことではないように思えますが、この点について思いつかず、問題が生じる可能性があります。だからこそ、私たちは「細部にこそ悪魔が宿る」と言うのです。

さて、紹介は以上です。興味のある方は、公式ウェブサイトにアクセスして詳細をご覧ください。

中国語: http://redis.cn/topics/distlock.html 英語: https://redis.io/topics/distlock

さて、長い長い準備を経て、ついに神々の戦いに突入します。

神々の戦い

神 1: Redis の作者 Antirez。友達の中には英語名にあまり敏感でない人もいるので、これからは彼をCurly-haired Brotherと呼ぶことにします。

2番目の神：分散分野の専門家であるマーティン・クレップマン。彼をブラザー・ロングヘアと呼びましょう。

上記の二人の美女の写真を見て、そしてこの記事を書いている間に薄くなっていった自分の髪を見て、思わず声を出して泣いてしまいました。たぶん、「いいね！」をもらうことでのみ、私を落ち着かせることができるでしょう。

公式サイトの Redlock ページの最後に、Curly は次のように書いています。「あなたも分散システムを使用している方であれば、あなたの意見や見解は非常に重要なので、ぜひ私たちと議論してください。」

つまり、「ハンマーを要求すればハンマーが手に入る」のです!この衝撃は、関連分野の専門家を含む多くのネットユーザーの注目を集めました。

長髪の兄ハンマー

この話は、2016 年 2 月 8 日に Brother Changfa が公開した「分散ロックの実行方法」という記事から始まります。

記事の URL: http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

この部分は次のように直接翻訳されます:

この本のための調査の一環として、Redis の Web サイトで Redlock というアルゴリズムを見つけました。このアルゴリズムは、Redis にフォールト トレラントな分散ロック (より正確にはリース) を実装すると主張しており、このページでは分散システム担当者からのフィードバックを求めています。このアルゴリズムは私にいくつかの考えを与えたので、時間をかけてこの記事を書きました。 Redlock の独立した実装はすでに 10 個以上あり、このアルゴリズムをすでに誰が利用しているかはわからないため、メモを公開する価値があると考えました。 Redis の他の側面については、他の場所で批判されている部分もあるため、ここでは説明しません。

この記事を見てください、冒頭は火薬でいっぱいです:フィードバックが欲しいと言ったので、フィードバックを提供します。そして、もしこれに関して他の問題があったとしても、私はそれについては話しません。 (実際、筆者もこの記事の中で、Redis を気に入って使用していますが、Redlock アルゴリズムは厳密ではないと考えています)

長髪の兄弟は主に次の絵を中心に開発されました:

一見して理解できない場合は、Changfa が 2017 年に出版した「Data Intensive Application System Design」という本から中国語版を紹介します。

上の画像には、リースの申し込みとリースの満了のキーワードが記載されています。リースは、実際にはタイムアウト付きのロックとして理解できます。

この本では、この写真の下に次のような説明が書かれています。

HBase を例に挙げてみましょう。その設計目標は、ストレージ システム内のファイルに一度に 1 つのクライアントのみがアクセスできるようにすることです。複数のクライアントが同時にファイルに書き込もうとすると、ファイルは破損します。上の図は次のことを説明しています。

1. クライアント 1 が最初にロックを申請し、ロックを正常に取得します。その後、クライアントは長い GC を実行し、STW 状況が発生しました。

2. STW期間中に、クライアント1が取得したロックのタイムアウト期間が経過し、ロックが無効になります。

3. クライアント 1 のロックが期限切れになったため、クライアント 2 がロックを申請すると正常に取得できます。

4. クライアント 2 はファイルの書き込みを開始し、ファイルの書き込みを完了します。

5. クライアント 1 が STW から回復します。ロックの有効期限が切れたことがわからず、ファイルの書き込みを継続するため、クライアント 2 によって書き込まれたファイルが破損します。また、ロックは常に 1 つのクライアントによってのみ保持されるという原則、つまり相互排他性を満たしていないことがわかります。

本の中では明確には書かれていませんが、よく考えてみると、ここでのロックサービスとはRedisのことを指しているのではないでしょうか？

クライアント 1 がファイルを書き込むときに、ロックの有効期限が切れたかどうかを判断できないのかと言う友人もいるでしょう。

君は本当に賢い小さな幽霊だね。質問させてください。GC はいつでも発生する可能性があります。判決後にGCが発生した場合はどうなりますか?

あなたは私と議論を続けていますが、クライアントが GC のない言語を使用した場合はどうなるのでしょうか?

**スレッドが一時停止する理由は GC だけではありません。 **これが起こる理由はたくさんあります。チャンファ兄弟の本に挙げられている例を見てみましょう。

上記の内容をまとめると、ロック サービスが正常であっても、ロックには保持時間があるため、クライアントのブロック、長い GC、またはネットワーク上の理由により、共有リソースが複数のクライアントによって同時にアクセスされます。

実際、上の写真の長髪の男性は本の中でこう言っています。「これは誤った実装です。」

よくよく考えてみると、上の図は、Redis ロックの有効期限の設定が不合理で、前のタスクが完了していないのにロックの有効期限が切れて次のタスクにもロックが適用されているように見えます。

このシナリオでは、Redis には実際に独自のウォッチドッグ メカニズムがあります。しかし、それは Redlock の議論の範囲を超えているため、ここでは説明しません。

ロングヘアー兄弟はどんな解決策を提案したのでしょうか?

彼はそれを「フェンシングトークン」と呼んだ。

チャンファ兄弟は、ロックとリースのメカニズムを使用してリソースへの同時アクセスを保護する場合、異常な理由によりロックの有効期限が切れたノードが他の正常な部分に影響を与えないようにする必要があると考えます。この目標を達成するには、非常にシンプルなフェンシングを使用できます。

ロック サービスがロックまたはリースを許可するたびに、許可されるたびに増加するフェンシング トークンも返されると想定します。

次に、クライアントは、ストレージ システムに書き込み要求を送信するたびに、保持しているフェンシング トークンを含める必要があります。ストレージ システムはトークンを検証し、より高いトークンを持つ要求がすでに処理されていることが判明した場合、要求の実行を拒否する必要があります。

たとえば、次の図をご覧ください。

1. クライアント 1 はタイムアウト付きのロックを取得し、トークン 33 を取得しますが、その後、ロックの有効期限が切れるまで長い一時停止状態になります。

2. この時点で、クライアント 2 はロックとトークン番号 34 を取得し、書き込み要求 (およびトークン番号 34) をストレージ サービスに送信します。

3. 次に、クライアント 1 が回復し、トークン番号 33 で書き込みを試みます。ストレージ サーバーは、より高いトークン番号 (34) が最近完了したことを記録しているため、トークン番号 33 での書き込み要求を拒否します。

このバージョン番号の仕組みは Zookeeper を思い出させます。 ZK をロック サービスとして使用する場合、トランザクション識別子 zxid またはノード バージョン cversion をフェンシング トークンとして使用できます。どちらも単調に増加する要件を満たすことができます。

Changfa Ge のメカニズムでは、実際にはリソース自体がリクエストによって保持されているトークン情報を積極的にチェックする必要があります。より高いトークンを持つ要求が処理されたことが判明した場合、より低いトークンを保持するすべての書き込み要求を拒否する必要があります。

ただし、すべてのリソースがデータベース内のデータであるとは限りません。バージョン番号を通じて追加のトークン チェックをサポートできます。追加のトークン チェックをサポートしていないリソースの場合、このアイデアを使用してこの制限を回避することもできます。たとえば、ファイル ストレージ サービスにアクセスするときに、トークンをファイル名に埋め込むことができます。

要約すると、ロック保護の外で要求処理が行われないようにするには、追加のチェック メカニズムが必要です。

チャンファ兄弟は本の中で次のようにも述べています。「サーバー側でトークンをチェックするのは少し複雑に思えるかもしれませんが、これは実際に推奨される正しいアプローチです。システム サービスは、すべてのクライアントが期待どおりに動作するとは想定できません。」セキュリティの観点から、サーバーはクライアントによるこの種の不正使用を防ぐ必要があります。

これは、バックエンド開発者として、フロントエンドや他のインターフェースから送信されるデータを信頼できず、検証する必要があるという事実に似ています。

この時点で、チャンファ兄弟は基礎工事を終え、RedLock に目を向け始めました。彼は、Redlock はシステム クロックに大きく依存する分散ロックであると考えています。

彼は例を挙げた。

1. クライアント 1 は、Redis ノード A、B、C からロックを正常に取得します。ネットワークの問題により、D と E にはアクセスできません。

2. ノード C のクロックが進み、そこで保持されているロックが期限切れになります。

3. クライアント 2 は、Redis ノード C、D、E から同じリソースのロックを正常に取得します。ネットワークの問題により、A と B にはアクセスできません。これで、クライアント 1 とクライアント 2 の両方がロックを保持していると認識します。

このようなシナリオは、Redlock がシステム クロックに大きく依存しているために発生する可能性があり、システム時間が不正確になると、アルゴリズムのセキュリティが保証されなくなります。

チャンファ兄弟は、先ほど述べた点を裏付けるためにこの例を挙げました。つまり、優れた分散アルゴリズムは非同期モデルに基づくべきであり、アルゴリズムのセキュリティはタイミングの仮定に依存すべきではない、つまり、時間をセキュリティの保証として使用できないということです。非同期モデルでは、プログラムの一時停止、メッセージの遅延、ネットワークの損失、システム時間エラーなどの要因はセキュリティには影響せず、アクティビティにのみ影響します。

簡単に言えば、極めて極端なケースでは、分散システムでできる最善のことは、限られた時間内に結果を出さないことであり、間違った結果を出すことはできません。

Paxos や Raft など、そのようなアルゴリズムは実際に存在します。明らかに、この基準からすると、Redlock のセキュリティ レベルは不十分です。

巻き毛の兄が提案した出発を遅らせる計画については、長髪の兄はそれをきっぱりと拒否した。出発を遅らせて何が悪いんだ？遅延開始は、まだ十分に正確なタイミング測定に依存していません。

おそらくチャンファ兄弟は、時計を飛ばすという例は十分ではないと感じているのでしょう。 NTP を正しく設定すればクロックを修正できると確信しているため、クロックのジャンプは非現実的だと誰もが考えるかもしれません。

この文脈で、彼はプロセスの一時停止がアルゴリズムの失敗を引き起こす可能性がある例を挙げています。

1. クライアント 1 は、Redis ノード A、B、C、D、E に対してロック要求を開始します。

2. 各 Redis ノードはクライアント 1 にリクエスト結果を返しましたが、クライアント 1 はリクエスト結果を受信する前に長い GC フェーズに入りました。

3. 長い GC により、すべての Redis ノードでロックが期限切れになります。

4. クライアント 2 は A、B、C、D、E のロック申請を行い、取得します。

5. クライアント 1 は GC フェーズから回復し、ステップ 2 の各 Redis ノードからの要求結果を受信します。クライアント 1 は、ロックを正常に取得したと判断します。

6. クライアント 1 とクライアント 2 は両方ともロックを保持していると認識します。

実際、Redlock のロック プロセスについて十分に理解していれば、この状況が Redlock に影響を及ぼさないことがわかります。なぜなら、クライアント 1 が GC フェーズから回復した後のステップ 5 で、Redlock アルゴリズム (前回の Redlock の紹介で説明した 4 番目のステップ) でロックが取得された場合、キーの実際の有効時間は、有効時間からロックの取得にかかった時間を引いた時間に等しいからです。

したがって、クライアント 1 はこのチェックを通じてロックの有効期限が切れたことを認識し、ロックを正常に取得できたとは考えなくなります。

この点は、Curly Brother のその後の返答でも言及されています。

しかし、よく考えてみると、これは長髪兄さんの意図ではないと思います。上記の問題はさておき、彼が強調したいのは、ロックがクライアントによって取得された後、使用される前に期限切れになるのは良くないということです。クライアントの観点から見ると、これは信頼できないものです。ロックをもらったけど、まだ使ってないのに期限切れですか？

上記の点に加えて、チャンファ兄弟は自身の経験に基づいた講演も提案しました。

ロックを取得する目的は何ですか?

彼の意見では、それは効率性と正確さという2 つの側面に帰着します。彼は彼らを次のように説明した。

効率化を図る場合は、さまざまなクライアントを調整して、作業の重複を避ける必要があります。このシナリオでは、ロックがたまに失敗したとしても、2 つのクライアントが同じ作業を行った可能性があり、その結果、コストが若干高くなったり (AWS に通常よりも 5 セント多く支払うことになる)、不便が生じたり (たとえば、ユーザーが同じ電子メール通知を 2 回受け取ることになる) するだけです。

正確さが目標である場合、ロックの失敗はいかなる状況でも発生してはなりません。ロックの失敗が発生すると、データの不整合、データの損失、ファイルの破損、またはその他の重大な問題が発生する可能性があるためです。 （例えば、患者が薬の量を2倍に増やした場合）

結局、長髪の男は結論に達した。魚でも鳥でもない（魚でも鳥でもない）

効率を向上させる必要があるシナリオでは、分散ロックが使用され、時折のロック失敗が許可されます。この場合、シンプルで効率的な単一の Redis ノード ロック ソリューションで十分です。 Redlock の使用は重すぎます。

正確性に対する要件が高いシナリオでは、時間に依存し、十分に強力なアルゴリズムではありません。 Redlock は正確性を保持しません。

では、どのようなテクノロジーを使用すべきでしょうか?

Changfa 兄弟は、Zookeeper に似たソリューション、つまりトランザクションをサポートするデータベースを検討すべきだと考えています。

巻き毛の男が反撃

長髪の男が「分散ロックのやり方」という記事を公開した翌日、巻き毛の男が反撃し、「Redlock は安全か？」というタイトルの記事を公開した。

記事URL: http://antirez.com/news/101

その上司は上司としてふさわしい。巻き毛の兄の返答は明瞭かつ流暢だ。彼は、ロングヘアがレッドロックが安全ではないと考える主な理由は 2 つあると結論付けました。

1. 自動有効期限機能を備えた分散ロックでは、共有リソースの真の相互排他保護を提供するために、有効期限後にクライアントがロックを使用するときに問題を回避する方法 (フェンシング メカニズム) が必要です。ロングヘアー兄弟は、レッドロックにはそのような仕組みはないと言いました。

2. チャンファ兄弟は、問題「1」をどのように解決しても、実際のシステムでは保証できないシステムモデルでのタイミング仮定を行うため、アルゴリズムは本質的に安全ではないと述べました。

最初の点に関して、カーリー氏はこの疑問を反駁するために5つの主要な点を挙げた。重要な点の 1 つは、Redlock はフェンシング メカニズムに似た単調に増加するトークンを提供しないが、ランダムな文字列も備えていると考えていることです。このランダムな文字列をトークンとして使用すると、同じ効果が得られます。共有リソースとやり取りする必要がある場合は、トークンが変更されたかどうかを確認します。そうでない場合は、「get-modify-write back」操作を実行します。

最終的な結論は、自己を省みる質問です。ロックが失敗したときにリソースへの相互排他的アクセスを維持し続けることができるフェンシング メカニズムがすでに存在するのに、なぜ分散ロックを使用し、そのような強力なセキュリティ保証を提供する必要があるのでしょうか。

しかし、2 番目の質問、つまりネットワークの遅延や GC の一時停止については、Redlock のセキュリティには影響しないことを以前に分析しており、これは Curly Brother が実際に設計時に時間要因によって引き起こされる問題を考慮したことを示しています。

しかし、時計を飛ばすことを提案したのが長髪の兄だったとしたら、巻き毛の兄は時計が飛ばればレッドロックの安全が保証されないことを知っており、それが彼のアキレス腱であることは明らかです。

しかし、Long Hair Brother がクロックジャンプについて書いたときに言及した 2 つの例は次のとおりです。

1. 運用保守担当者がシステムクロックを手動で変更しました。

2. NTP サービスから大きなクロック更新イベントを受信しました。

巻き毛の男は反撃した。

まず、運用保守担当者が手動で時計を変更しましたが、これは人的要因によるものです。それについては私に何もできません。彼らはただあなたを困らせたいだけなのです。どうすればいいですか？管理を強化して、このようなことはしないでください。

2 番目のポイントは、NTP サービスから大量のクロック更新を受信することです。この問題は、運用と保守を通じて保証される必要があります。サーバーに大量の更新を行う必要がある場合は、少量ずつ複数回に分けて行う必要があります。更新時間をできるだけ短くしながら、複数回の改訂を行います。

この点についての議論は、信長の弟のタイムジャンプが確実に起こると考えるか、信長の弟のタイムジャンプも我々が対応できると考えるかによって変わってきます。

時計のジャンプに関しては、この神々の戦いの産物でもある記事がありますので、ぜひ読んでみてください。

https://jvns.ca/blog/2016/02/09/til- Clock-skew-exists/

この記事の最終的な結論は、クロックジャンプは存在するということです。

実際、私たちは皆、時計の飛びを経験したことがあります。 2016年の最終日に「うるう秒」という概念があったことを覚えていますか?その結果、2017年1月1日7時59分60秒にこの光景が見られました。

戦いの焦点

このようなやり取りを経て、両者の戦いの焦点は実は非常に明確になりました。それは、分散ロックに対する大きな遅延の影響です。

大きな遅延がRedlockに与える影響については、Changfa兄弟が分析したとおりです。ロックは期限切れですが、業務は完了していません。 Curly Brotherは、この影響はRedlockだけでなく、自動放出ロックを備えた他の分散ロックも同じ問題を抱えていると考えています。

大きな遅延の問題については、ソーシャルプラットフォームで2人の神々の間で次の会話を見つけました。

カーリーヘアの男は尋ねました：返信を投稿した後、大きなメッセージの遅延がレッドロックの操作に害を及ぼさないことに同意できるのではないかと思います。

チャンファ兄弟は答えました：クライアントとロックサーバーの間のメッセージの遅延に関して、私はあなたのポイントに同意します。しかし、クライアントとアクセスされるリソースの間の遅延は依然として問題があります。

したがって、Curly Brotherの応答記事と特定のソーシャルプラットフォームの記録から判断すると、彼は大規模なシステムクロックジャンプがレッドロックを失敗させることに同意します。この点で、彼の意見は、実際のシステムでは、優れた操作とメンテナンス方法を通じて大きな時計ジャンプを回避できると考えているという点で、長い髪の兄弟の意見とは異なります。

したがって、この時点で、2人の神はバランスに達し、議論の違いを確保しながら共通の基盤を達成したように見えました。

ファイトサマリー

インターネット業界の開業医であり、分散システムのユーザーとして、私は彼らの記事と彼らから派生した知識ポイントを読んだ後、多くの利益を得ました。それで、私はこの記事を学習の要約として書き、あなたと共有します。この記事にはまだ多くの欠点があります。私を許してください。

記事の冒頭で述べたように、この議論には最終的な勝者はいません。明らかに、巻き毛の男は長髪の男を納得させませんでした。なぜなら、2017年に長髪の男が発行した「データ集中アプリケーションシステム設計」という本には、信頼できない時計と呼ばれる特別なセクションがあります。

実際、この議論の終わりに、長い髪の兄弟は議論の非常に感情的な要約をしました。彼はこう言った。

次の翻訳は、https：//www.jiansshu.com/p/dd66bdd18a56からのものです

私にとって最も重要な点はこれです。この議論で誰が正しいか間違っているかは気にしません。過去の過ちを繰り返して未来を改善することを避けることができるように、他人の仕事から学ぶことだけを気にします。私たちの前任者は、私たちのために多くの大きな成果を生み出しました。巨人の肩に立って、より良いソフトウェアを構築できます。

他のアイデアと同様に、それらをテストし、議論を通してそれらを置き、他の人からの精査に立ち向かうかどうかを確認することが重要です。それは学習プロセスの一部です。しかし、目標は、あなたが正しいことを他の人に納得させるのではなく、知識を得ることです。時々、それはただ止まって考えていることを意味します。

ネチズンがメロンを食べることから得たもの

ここでショーを見ているネチズンは私に言及しています。

私はこの記事を書いてから多くを得ました。まず第一に、私はChangfa GEによる「Data Intensive Application System Design」という本を購入し、いくつかのセクションを読んで、この本が本当に良いことを発見しました。ドゥーバンスコアは9.6で、強くお勧めします。

第二に、私は今週の毎週の更新タスクを完了しましたが、土曜日の正午から日曜日の午前3時まで書くのは非常に困難でした。 。 。

それから私は別のメロンを食べました。これはメロンの中で最高のメロンでした。

Redisの公式ウェブサイトは今週金曜日に短い停止を経験しませんでしたか？それが起こることは珍しいことではありませんが、ページはRedisに接続できないことを示しました。これはかなり興味深いですね。

私がこの記事を書いていたとき、私はこれを巻き毛の兄弟のソーシャルプラットフォームで見つけました：

私が心配しているのはOOMではありませんが、Curly Hair Brotherが実際にRedisの公式Webサイトが月に5ドルしかかかり、メモリしかない仮想マシンで実行できるという事実です。ハハハ、ショックを受けた、このメロンはおいしい。

最後に、カーリーヘアの男はイタリア人であり、最近の流行のために、四川の専門家チームが支援を提供するためにイタリアに駆けつけたので、中国人にとても感謝したいと思います。実際、このネチズンの答えは非常に良いです。好意を返してください。

流行がすぐに通過し、世界が平和になりますように。

最後に、言葉

私がこれを書いたとき、それはすでに午前3時を過ぎていましたが、私はこれら2人の偉大な作家の間の熱烈な議論を追っていたので、私の心は異常に明確でした。

それを書いた後、私は誰が正しいか間違っているのかわかりません。誰もがシステム設計の異なる出発点を持っていると思います。完璧な建築、普遍的な建築というものは存在しませんが、完璧さと普遍性の間で良いバランスをとった建築は良い建築です。