Linux での効率的なログ ライブラリの適用

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

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

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

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

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

ログは、一貫性の問題を解決するための重要なデータ構造です。ログは、操作シーケンスのようなものです。たとえば、広く使用されている Paxos プロトコルと Raft プロトコルはすべて、ログに基づいて構築されています。

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

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

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

水平方向のスケーラビリティは、分散システムでは非常に重要な機能です。マシンを追加することで解決できる問題は問題ではありません。では、水平方向の拡張を実現できるメッセージ キューを実装するにはどうすればよいでしょうか?それでは、パフォーマンスの最適化についてはどうすればよいでしょうか?

1. トピック/ログのシャーディング。本質的に、トピックによって書き込まれるメッセージはログ レコードです。書き込み数が増加すると、単一のトピックが複数のサブトピックに分割される可能性があります。このようにして、大量のメッセージを含むトピックはマシンを追加することで解決できますが、少量のメッセージを含む一部のトピックは同じパーティションに割り当てるか、処理しないことができます。
Kafka のプロデューサー クライアントなどのグループ コミットは、メッセージを書き込むときに、まずローカル メモリ キューに書き込み、次に各パーティションおよびノー​​ドに従ってメッセージを要約し、サーバー側またはブローカー側にバッチで送信できます。この方法を使用すると、最初にページ キャッシュが書き込まれ、その後ディスクが定期的にフラッシュされます。たとえば、金融サービスでは同期フラッシュ方法が採用されます。
無駄なデータコピーを避ける
IO分離
4. 
   

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

以上がLinux での効率的なログ ライブラリの適用の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。