分散システムコアログの詳細紹介（画像とテキスト）

この記事では、分散システムのコア ログについて詳しく説明します (写真とテキスト)。必要な方は参考にしてください。

ログとは何ですか?

ログは、時系列に追加された完全に順序付けられた一連のレコードです。実際、このファイルは次のようなものです。ワードセクション配列であり、ここでのログはレコードデータですが、ファイルに比べて、ここでの各レコードは相対的な時間順に配置されており、最も単純な保存モデルと言え、一般的には読み取りが可能です。 from メッセージ キューなど、ログ ファイルは通常、左から右に線形に書き込まれ、コンシューマはオフセットから開始して順番に読み取ります。

ログ自体の固有の特性により、レコードは左から右に順番に挿入されます。これは、左側のレコードが右側のレコードよりも「古い」ことを意味します。システムクロックに依存する必要があるため、この機能は分散システムにとって非常に重要です。

#ログの適用

データベースへのログの適用

ログはいつ現れるか分かりません。コンセプトが単純すぎるのかもしれません。データベース分野では、MySQL の REDO ログなど、システムがクラッシュしたときにデータとインデックスを同期するためにログがよく使用されます。REDO ログは、システムがハングしたときにデータの正確性と完全性を保証するために使用されます。たとえば、物事の実行中に、REDO ログが最初に書き込まれ、その後、システムがクラッシュ後に回復するときに実際の変更が適用されます。 REDO ログに基づいて再作成されます。元に戻してデータを復元します (初期化プロセス中、この時点ではクライアント接続はありません)。ログは、データベースのマスターとスレーブ間の同期にも使用できます。基本的に、データベースのすべての操作記録がログに書き込まれているため、ログをスレーブに同期し、それをスレーブで再生するだけでマスターを実現できます。 -スレーブ同期。REDO ログをサブスクライブすることで、データベース内のすべての変更を取得でき、監査やキャッシュ同期などのパーソナライズされたビジネス ロジックを実装できます。

分散システムにおけるログのアプリケーション

分散システム サービスは基本的に状態に関するものであり、ここでの変更により次のことが可能になります。 2 つの独立したプロセス (システム クロック、外部インターフェイスなどの外部環境に依存しない) に一貫した入力が与えられると、一貫した出力が生成され、最終的には一貫した状態が維持され、その固有の順序性が維持されるためです。システムクロックに依存しないため、変更順序の問題を解決するために使用できます。

私たちはこの機能を使用して、分散システムで発生する多くの問題を解決します。たとえば、RocketMQ のスタンバイ ノードでは、メイン ブローカーがクライアントのリクエストを受信して​​ログを記録し、それをリアルタイムでスレーブに同期します。マスターがハングアップしても、スレーブはそれをローカルで再生し続けます。書き込みリクエストを拒否して読み取りリクエストを処理するなど、リクエストを処理します。ログにはデータを記録するだけでなく、SQL ステートメントなどの操作を直接記録することもできます。

ログは、一貫性の問題を解決するための重要なデータ構造です。たとえば、広く使用されている Paxos では、各レコードが命令を表します。 Raft プロトコルは、ログに基づいて構築された一貫性のあるプロトコルです。

メッセージ キューでのログのアプリケーション

ログはデータの流入と流出の処理に簡単に使用でき、各データ ソースは独自のログを生成できます。ここでのデータ ソースは、特定のイベント ストリーム (ページのクリック、キャッシュの更新リマインダー、データベースのバイナリの変更) など、さまざまな側面から取得できます。ログをクラスターに集中的に保存でき、サブスクライバーはオフセットに基づいてログを読み取ることができます。各レコードに、各レコードのデータと操作に基づいて独自の変更を適用します。

ここでのログはメッセージ キューとして理解でき、メッセージ キューは非同期の切り離しと電流制限の役割を果たすことができます。なぜデカップリングと言うのでしょうか?コンシューマーとプロデューサーにとって、2 つの役割の責任は非常に明確であるため、データベースの変更ログであるか特定のイベントであるかにかかわらず、どちらが下流であるか上流であるかを気にすることなく、メッセージの作成とメッセージの消費に責任を負います。特定のパーティを気にする必要はまったくなく、興味のあるログとそのログ内の各レコードに注意を払うだけで済みます。

データベースの QPS は確実であり、上位層のアプリケーションは一般に水平方向に拡張できることがわかっています。この時点で、ダブル 11 のような突然のリクエスト シナリオが発生してデータベースが圧倒される場合、メッセージを導入できます。キューを作成し、各チームのデータベースを追加します。操作はログに書き込まれ、別のアプリケーションがこれらのログ レコードを使用してデータベースに適用する役割を果たします。データベースがハングした場合でも、回復時に最後のメッセージの位置から処理を続行できます。 (RocketMQ と Kafka はどちらも Exactly Once セマンティクスをサポートしています)、ここでは、プロデューサーの速度がコンシューマーの速度と異なっていても、ログはここにバッファーの役割を果たします。ログの書き込みがマスター ノードによって処理されるため、メッセージのバックログ容量が大幅に向上します。1 つは末尾読み取りであり、消費量が少なくなります。 1 つの種類の読み取りはキャッシュに直接送信でき、もう 1 つの種類の読み取りは書き込みリクエストに遅れてスレーブ ノードから読み取ることができるため、IO 分離とページキャッシュ、キャッシュ事前読み取りなど、オペレーティング システムに付属する一部のファイル ポリシーを使用すると、パフォーマンスが大幅に向上する可能性があります。

# 水平方向のスケーラビリティは、分散システムにおいて非常に重要な機能です。マシンを追加することで解決できる問題は問題ではありません。では、水平拡張を実現できるメッセージ キューを実装するにはどうすればよいでしょうか? スタンドアロンのメッセージ キューがある場合、トピックの数が増加するにつれて、IO、CPU、帯域幅などが徐々にボトルネックになり、パフォーマンスが徐々に低下します。パフォーマンスの最適化についてはどうすればよいでしょうか?

1.topic/log sharding 本質的に、トピックによって書き込まれるメッセージはログ レコードになります。書き込みの数が増えると、徐々にボトルネックになります。現時点では、1 つのトピックを複数のサブトピックに分割し、各トピックを別のマシンに割り当てることができます。このようにして、大量のメッセージを含むトピックはマシンを追加することで解決できますが、メッセージの量が少ないトピックもあります。マシンを追加することで解決できます。同じマシンに割り当てることも、分割しないこともできます。たとえば、Kafka のプロデューサー クライアントは、メッセージを書き込むときに、最初にローカル メモリ キューに書き込みます。次に、各パーティションとノードに従ってメッセージを書き込み、バッチで送信します。サーバー側またはブローカー側では、このメソッドを使用して最初にページキャッシュに書き込み、その後ディスクを定期的にフラッシュすることもできます。たとえば、金融サービスではディスクをブラッシングする方法が使用されます。

3. 無駄なデータのコピーを避ける

4.IO 分離

##結論

分散システムのログこれは非常に重要な役割であり、分散システムのさまざまなコンポーネントを理解するための鍵となります。理解が深まるにつれて、Zookeeper、HDFS、Kafka、RocketMQ、Google Spanner などの多くの分散ミドルウェアがログに基づいて構築されていることがわかります。 Redis、MySQL などのデータベースの場合でも、マスターとスレーブはログ同期に基づいており、共有ログ システムに依存して、ノード間のデータ同期、同時更新データ順序の問題 (一貫した安定性の問題) など、多くのシステムを実装できます。 ）、永続性（システムがクラッシュした場合でも、他のノードを介してサービスを提供し続けることができる）、分散ロックサービスなど、実践と多くの論文を読むことで理解が深まると思います。

以上が分散システムコアログの詳細紹介（画像とテキスト）の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。