分散システムの中核 - ログ-Linux-php.cn

ログとは何ですか?

ログは、完全に順序付けされたレコードシーケンスであり、時系列で追加されます。実際には特別なファイル形式です。ファイルはバイト配列であり、ここでのログはレコードデータですが、ここではファイルに対して相対的です。各レコードは次のとおりです。時間の相対的な順序で配置されます。ログは最も単純なストレージモデルであると言えます。読み取りは通常、左から右に行われます。たとえば、メッセージキューは通常、消費者の順序でログファイルに線形に書き込みます。オフセットから読み取りを開始します。
ログ自体の固有の特性により、レコードは左から右に順番に挿入されます。これは、左側のレコードが右側のレコードよりも「古い」ことを意味します。システムクロック: この機能は分散システムにとって非常に役立ち、システムにとって非常に重要です。
分散システムの中核 - ログ

ログアプリケーション

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

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

分散システムにおけるログの適用

分散システムの中核 - ログ
分散システムサービスは基本的に状態の変更に関するものであり、これはステートマシンとして理解できます。2 つの独立したプロセス (システムクロック、外部インターフェイスなどの外部環境に依存しない) は、一貫した入力が与えられると一貫した出力を生成します。そして最終的には維持されます。一貫した状態であり、ログはその固有のシーケンスによりシステムクロックに依存せず、変更順序の問題を解決するために使用できます。
私たちはこの機能を使用して、分散システムで発生する多くの問題を解決します。たとえば、RocketMQ のスタンバイノードでは、メインブローカーがクライアントのリクエストを受信してログを記録し、それをリアルタイムでスレーブに同期します。スレーブはそれをローカルで再生します。マスターがハングアップしても、スレーブは引き続き処理を続行できます。書き込みリクエストを拒否して続行するなど、リクエストを処理します。読み取りリクエストを処理します。ログにはデータを記録するだけでなく、SQL ステートメントなどの操作を直接記録することもできます。
分散システムの中核 - ログ
ログは一貫性の問題を解決するための重要なデータ構造です。ログは一連の操作のようなものです。各レコードは命令を表します。たとえば、広く使用されている Paxos プロトコルと Raft プロトコルはすべて、ログに基づいて構築された一貫性プロトコルです。
分散システムの中核 - ログ

メッセージキューへのログの適用

ログは、データの流入と流出の処理に簡単に使用できます。各データソースは独自のログを生成できます。ここでのデータソースは、特定のイベントストリーム (ページクリック、キャッシュ更新リマインダー、データベースのバイナリログの変更など）を使用すると、ログをクラスターに集中的に保存でき、サブスクライバーはオフセットに基づいてログの各レコードを読み取り、各レコードのデータと操作に基づいて独自の変更を適用できます。
ここでのログはメッセージキューとして理解でき、メッセージキューは非同期デカップリングと電流制限の役割を果たすことができます。なぜデカップリングと言うのでしょうか?コンシューマーとプロデューサーにとって、2 つの役割の責任は非常に明確であるため、どちらが下流であるか上流であるか、データベースの変更ログであるか特定のイベントであるかなどを気にすることなく、メッセージの作成とメッセージの消費に責任を負います。特定のパーティのことを気にする必要はまったくなく、興味のあるログとそのログ内の各レコードに注意を払うだけで済みます。
分散システムの中核 - ログ

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

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

トピック/ログシャーディング。本質的に、トピックによって書き込まれるメッセージはログレコードです。書き込み数が増加するにつれて、単一のマシンが徐々にボトルネックになります。このとき、単一のトピックを複数のサブトピックに分割できます。を作成し、各トピックを異なるマシンに割り当てます。このようにして、大量のメッセージを含むトピックはマシンを追加することで解決できますが、少量のメッセージを含む一部のトピックは同じマシンに割り当てるか、パーティション分割なしで解決できます。

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

以上が分散システムの中核 - ログの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。