分散システムを同期するにはどうすればいいですか?それはとても残酷です！

[[415442]]

この記事はWeChat公式アカウント「妹の味」から転載したもので、著者は妹が飼っている犬です。記事を転載する場合は、ミスシスターテイスト公式アカウントまでご連絡ください。

分散システムは、データの冗長性を通じてデータのセキュリティを確保します。分散システムを作成する場合、避けられないハードルの 1 つはデータの同期です。

「同期」という二つの言葉は、多くの人を死ぬまで苦しめてきました。

同期ですか、それとも非同期ですか?押すのか引くのか？誰が主人で誰が奴隷なのか？オフラインになると何が起こりますか? また、オンラインになると何が起こりますか?集中型ノードかピアツーピアノードか?

これらすべての問題は、分散システムの設計者を悩ませています。

次に、いくつかの主流のストレージ サービスと、それらがどのようにデータ同期の問題を解決するかを見ていきます。

MySQL マスターとスレーブを同期するにはどうすればいいですか?

MySQL のメインサーバーはマスターと呼ばれ、スレーブサーバーはスレーブと呼ばれます。

マスター サーバーは変更を binlog に記録し、スレーブはこれらのレコードを別のスレッドを通じてコピーして再生します。

binlog 形式は、ステートメント、行、混合に分かれています。

• ステートメントは変更されたSQLステートメントをbinlogに書き込み、精度に一定の影響を与えます。
• 行は各レコードの変更をbinlogに書き込みます
• 混合 上記 2 つを組み合わせたもの。 MySQLはステートメントと行をいつ使用するかを決定します

コピーは非同期スレッドによって実行されるため、スレーブは遅延が発生しやすくなります。マスターに障害が発生すると、遅延データ損失が発生します。

非同期レプリケーションの問題を解決するために、MySQL はバージョン 5.5 以降で半同期レプリケーションの概念を導入しました。半同期は、非同期と完全同期の中間です。マスターはトランザクションを完了した後、直接戻るのではなく、少なくとも 1 つのスレーブが正常に書き込みを行うまで待機してから戻ります。少なくとも 1 つのスレーブと対話する必要があるため、非同期レプリケーションと比較するとパフォーマンスは確実に低下します。

もちろん、完全レプリケーション モードでは、すべてのスレーブ ノードがレプリケーションを完了するまで待機する必要があります。これは最も安全ですが、最も効率が悪いです。概念的には、スレーブが 1 つだけの半分のレプリケーションは完全なレプリケーションです。

5.7 以降、MySQL はグループ レプリケーション プロトコルを実装しました。シングルプライマリモードとマルチプライマリモードをサポートしていますが、同じグループ内に同時に存在することはできません。魔法のように聞こえますが、実際には Paxos プロトコルを通じて実装されています。

Kafka はどのようにレプリカを同期しますか?

Kafka はメッセージキューなので、ランダム削除やランダム更新の問題を考慮する必要はありません。記述問題のみに焦点を当てています。構造的には、Kafka の同期ユニットは非常に分散化されています。Kafka には複数のトピックがあり、各トピックは複数のパーティションに分割され、レプリケーションはパーティションに基づいて行われます。

プライマリ パーティションはリーダーと呼ばれ、1 ～ n のレプリカはフォロワーと呼ばれます。プロデューサーがメッセージを送信する場合、まずパーティションのリーダーを見つけて、そのリーダーにデータを送信する必要があります。フォロワーは、プライマリ パーティションに問題が発生した場合に引き継ぐことができるように、バックアップとしてのみ存在します。

Kafka のマスターとスレーブの同期は、ISR (In Sync Replica) メカニズムと呼ばれます。

では、メッセージが正常に送信されたとみなされるのはいつでしょうか?これは ack の送信レベルによって異なります。

• 0 は非同期送信を意味し、メッセージは送信されると成功したとみなされます。
• 1 リーダープライマリレプリカは、送信に成功した場合でも書き込まれる
• -1 リーダーは送信を完了し、ISR内のすべてのレプリカはackで応答する必要がある

0 および 1 の場合、Kafka はメッセージを失う可能性があります。 -1 の場合、メッセージのセキュリティを確保するために、少なくとも 1 人のフォロワーが正常にコミットすることも必要です。フォロワーがリーダーに追いつけない場合は、ISR リストから削除されます。そうです、直接削除されます。 ISR が空の場合、Kafka パーティションと単一マシンの間に違いはないため、Kafka は最小 ISR を指定するための min.insync.replicas パラメータを提供します。

• ISR が満たされない場合はどうすればいいですか?プロデューサーの送信が失敗し、メッセージがシステムにまったく入らないため、Kafka はメッセージを失うことはありません。
• すべてのレプリカが利用できない場合はどうなりますか?この場合、パーティションは使用できなくなります。

レプリカ間のデータ複製は、フォロワー プル、つまりプル方式によって実現されます。

Redis マスタースレーブレプリケーション

Redis はメモリ内 KV データベースであり、他のデータベースよりもはるかに高速で、理論的にはマスターとスレーブの同期が容易です。ただし、トラフィック量が多く QPS が高い場合、マスター スレーブ レプリケーションでは依然として問題が発生します。

Redis スレーブが接続されると、最初に完全な同期が実行されます。 psync コマンドをマスターに送信し、マスターは bgsave を実行して rdb ファイルを生成します。完全同期とは、この rdb スナップショット ファイルをスレーブにコピーすることです。

では、フルコピーの途中に表示されるデータはどうすればよいのでしょうか?キャッシュする必要があります。マスターはバッファを開き、完全なレプリケーション プロセス中に生成された新しいデータを記録し、完全な同期が完了した後に増分データを入力します。

スレーブが切断されるたびに完全な同期を実行する必要はありません。増分に対応するために、レプリケーション オフセット (offset)、レプリケーション バックログ バッファー (replication backlog buffer)、実行 ID (run_id) という 3 つの概念が導入されています。スレーブの識別、およびそのレプリケーション位置とバッファの識別に使用されていることがわかります。

以降の同期では、いつでも psync を使用してコピーできます。それはまだ非同期レプリケーションです。

Redis のマスター スレーブ レプリケーションの一貫性はメモリに大きく依存しており、そのレベルは非常に弱いことがわかります。しかし、速いです。スピードは多くの問題を解決できるため、適用シナリオは異なります。

ElasticSearch マスタースレーブレプリケーション

es は lucene をベースにした検索エンジンであり、データ ノードには複数のインデックスが含まれます。各インデックスには複数のシャードが含まれ、各シャードには複数のレプリカが含まれます。

上記の説明から、これらの概念は Kafka と非常に類似しており、es のレプリケーション単位はシャーディングです。

es のデータは引き続き最初にマスターに書き込まれます。また、同期中のスレーブのリスト (InSyncAllocationIds) も維持します。黄色と赤の州のレプリカは、もちろんこのリストには含まれていません。

マスターは、クライアントに戻る前にこれらの通常のレプリカがすべて書き込まれるのを待つ必要があるため、一貫性レベルは比較的高くなります。スレーブ ノードが読み取り操作に参加する必要があるため、ほぼリアルタイムのシステムです。

データベースなので、削除や更新の操作は引き続き行われます。 Translog は WAL ログと同等であり、停電時のデータ セキュリティを確保し、他の RDBMS のルーチンと一致しています。

Cassandra クラスター モード

Cassandra は非常に有名な CAP 理論実践データベースであり、AP データベースに似ており、現在でも db-engines.com で高い評価を得ています。

データの保存はテーブルの概念に基づいており、テーブルは複数のマシンに保存できます。パーティションはパーティション キーによって設計され、データの分散はハッシュ関数に大きく依存します。ノードで問題が発生した場合はどうなりますか?次に、一貫性のあるハッシュのサポートが必要になります。

カサンドラはとても興味深いです。そのレプリカは他のマスタースレーブデータとは異なります。これは、マスター データの複数のコピーのようなもので、それらはすべて同時に外部の世界にサービスを提供します。チェックポイントが失敗した場合、プライマリノードとバックアップノードを切り替える必要はありません。

なぜこれが達成できるのでしょうか? Cassandra は最終的な一貫性を追求しているからです。レプリカの存在により、分散システムでは必然的に非同期または同期のレプリケーションが必要になります。では、複製の適切な程度はどの程度でしょうか? Quorum の R+W はトレードオフ戦略です。

クォーラム = (レプリケーション係数の合計 / 2) + 1

それはどういう意味ですか？引き出しが 5 つあり、W 個のボールをランダムにそれらに入れる場合、ボールを取り出すのに R を何回実行する必要がありますか?ボールを 1 個入れた場合、毎回正しい判定を得るには 5 回開ける必要があります。このとき、R=5、W=1です。ボールを 2 個入れた場合は、4 回開けるだけで済みます。ボールを 5 個入れた場合は、一度だけ読み取る必要があります。

R+W>N の場合、強い一貫性です。 R+W<=N の場合、結果整合性となります。

興味深いことに、Cassandra のクラスター情報、つまりメタ情報は、ゴシップ (プッシュ プル ゴシップ) を使用して送信されます。

MongoDB マスタースレーブレプリケーション

Mongodb には 3 つのデータ冗長モードがあります。 1 つはマスター/スレーブ (非推奨)、1 つはレプリカ セット、1 つはシャーディング モードです。

Mongodb のレプリカ セット マスター/スレーブは、手動による介入を必要とせずに自動フェイルオーバーを実装する標準的な方法です。マスターノードに障害が発生すると、選出によってレプリカセットから新しいマスターノードが見つかり、他のノードはこのマスターに接続するように誘導されます。

Mongodb の選択アルゴリズムは bully を使用します。

マスター ノードへの変更は、特定のシステム テーブルに保存されます。スレーブは定期的にこれらの変更をプルして適用します。この説明から、同期の遅延が発生したり、単一のノードに問題が発生した場合、MongoDB はデータを失う可能性があることもわかります。

要約する

分散コンピューティングは、単一マシンの容量問題を解決するように設計されていますが、データの同期という新たな問題も生じます。

データ同期では、一貫性、障害回復、および適時性に重点を置く必要があります。

同期する必要があるデータは主に 2 種類あります。

• メタデータ情報
• 実データ

メタデータ情報の場合、現在主流のアプローチは、データ配信に raft プロトコルを使用することです。実際のデータ同期に関しては、ラフト プロトコルの効率はまだやや低いため、非同期レプリケーションが一般的に使用されます。

この場合、非同期レプリケーション リストは、クラスターがこれらのノードのステータスを維持するために必要な重要なメタデータ情報になります。最悪の場合、すべての非同期レプリケーション ノードが利用できなくなり、マスターは非常に信頼できない環境で実行されます。

データ分散の柔軟性を高めるために、これらのレプリケーション ユニットは主にシャーディング スライス上で動作し、メタ情報が爆発的に増加します。

分散システムは非常に多く存在しますが、統一されたモデルは存在しません。興味深いことに、最も効率の悪い分散システムでさえ、多数のフォロワーがいます。信じられませんか？ BTCの動向を見てみましょう。

著者について: Sister Taste (xjjdog)、プログラマーが寄り道をすることを許可しない公開アカウント。インフラストラクチャと Linux に重点を置きます。 10 年間のアーキテクチャと 1 日あたり数千億のトラフィックを基に、私たちはお客様とともに高並行性の世界を探求し、新たな体験をお届けします。