義務とは何かを理解するのに役立つ、あらゆる年齢層向けの長いカフカの記事

[[376344]]

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

この記事を読めば、単純なメッセージ キューにこれほど多くの知識ポイントがある理由がわかります。 Kafka の主な機能とアプリケーション シナリオを理解する。 Kafka の主な技術用語を理解します。義務とは何かを理解してください！

分散メッセージング システムとして、Kafka には責任感がなければなりません。企業は自らのポジショニングを明確にし、誰のためにどのような価値を創造し、誰に依存して生き残り、自らの責任は何かを理解する必要があります。

このような激しい圧力の下で平静を保てるシステムはほとんどないが、カフカは持ちこたえた。それは真の戦士です。

Kafka のコアはメッセージ キューとして使用されます。では、メッセージ キューとは何でしょうか?この質問が理解できない場合は、カフカの思想的認識があまり高くないことが証明されており、考え続けて研究を続ける必要があります。

この質問についてさらに詳しく知るために、私たちは牛乳配達人にインタビューしました。

1. 牛乳配達人の物語

牛乳は、乳製品工場で搾った新鮮な牛乳であれ、合成乳であれ、美味しくて栄養価が高いので、地域の多くの人が注文します。

毎朝、牛乳配達人は牛乳を積んだカートで牛乳を配達し始めます。最初は、ノートに書かれた家の番号に従ってすべての家のドアをノックし、お客さんの手に牛乳を詰めていました。顧客が家にいない場合もあるので、連絡を取るために顧客の電話番号を見つけるためにアドレス帳を調べなければなりません。しかし、ビジネスが成長するにつれて、牛乳配達人はこの仕事についてただ一言だけ言うようになりました。「これは感謝されない仕事だ。」

眠そうな目でドアを開けて、生活の邪魔をしたと苦情を言う客もいた。パジャマ姿で牛乳を受け取りに来た女性客の中には、店員が下品な目で見ていると苦情を言う人もいた。顧客の中には早く出勤した人もいたが、牛乳配達人の配達ルート計画によると、彼らの牛乳は最後に配達されたため、彼らは牛乳の配達が遅いと苦情を言った。

幸いなことに、牛乳配達人はかつてプログラマーでした。少し考えた後、彼は上司を説得して、顧客一人一人にミルクの箱を配るようにした。彼の仕事は、新鮮な牛乳を定期的に箱に入れることだけです。顧客がいつそれを手に入れるか、顔を洗うために使うか、手を洗うために使うかは彼には関係ない。

それ以来、彼はパジャマの下にぼんやりと見えていた死体を二度と見ることはなかった。

上記のシナリオでは、牛乳配達人と顧客という 2 人の主な参加者がいることがわかります。ミルクボックスが追加される前は、相互作用がブロックされ、情報処理が非効率的で、深刻な結合の問題があったため、牛乳配達人は見るべきではないものを見ていました。

もちろん、ミルク ボックスを追加した後は、インタラクション ロジックが変更され、適応が必要になります。また、ミルクボックスにはコストがかかり、取引量がそれほど大きくない場合は、これを追加するとコストが増加します。

簡単に見てみましょう。上のミルク ボックスはメッセージ システムです。各ミルク ボックスはメッセージ キューです。牛乳配達人は生産者です。顧客は消費者である。そして牛乳はニュースです。顧客がミルクを受け取らない場合は、メッセージが滞留することになります。顧客は牛乳を受け取ったことを確認するメッセージを送信します。これが ACK です...

2. 最も単純な一般化されたメッセージングシステム

メッセージシステム！中間層を提供します。プロデューサーは特定の中間層にメッセージを送信するだけでよく、コンシューマーは中間層から情報を取得するだけでよいのです。

したがって、最も単純な形式はデータベースです。

上の図は、いくつかの小規模システムの典型的なアーキテクチャを示しています。受注のビジネスシナリオを考慮すると、当社のビジネスシステムを指すリクエストが多数あります。複雑なビジネス ロジックを通じてビジネス テーブルに直接入力すると、多数のリクエストがタイムアウトして失敗します。そこで、ユーザー要求を処理するために中間バッファ テーブルを追加しました。次に、バッファー テーブルからデータを継続的に取得して、非常に複雑なビジネス ロジック処理を実行するスケジュールされたタスクがあります。

疑わないでください。これは実際には最も単純なメッセージング システムですが、多くの問題があります。

1. スケジュールされたタスクのポーリング間隔を制御するのは困難です。業務処理が遅れる傾向があります。
2. 処理能力を水平方向に拡張することは不可能であり、分散ロックや順次保証などの問題が生じます。
3. 他のビジネスでもこの注文データが必要な場合は、スケジュールされたタスクにビジネス ロジックを追加する必要があります。

トラフィックが増加し、ビジネス ロジックが複雑になると、より高度なメッセージ モデルが必要になります。

3. メッセージングシステムの基本要件

メッセージング システムに対する基本的な要件は次のとおりです。

• 高いパフォーマンスには、メッセージの配信とメッセージの消費が含まれ、どちらも高速である必要があります。一般的に、並列処理能力はシャードの数を増やすことによって得られます。明らかにデータベースがボトルネックになっています。
• メッセージは特定のシナリオでは信頼性が高く、失われてはなりません。メッセージは、生成、消費、および MQ の終了時に失われることはありません。この問題は通常、レプリカを追加してディスクを強制的に更新することで解決されます。当然のことながら、データベースもマスター/スレーブ経由でバックアップする必要があります。
• スケーラビリティは、プロジェクトを拡張し、永続的に継続するのに十分なものでなければなりません。クラスターにノードを追加しても、パフォーマンスが低下することはありません。データベースのスケーラビリティは明らかに疑問であり、複雑なシャーディング コンポーネントを導入する可能性があります。
• エコシステムの成熟度の監視、運用と保守、多言語サポート、活発なコミュニティ。これにより、使用するメッセージ キューが信頼できるかどうかが決まります。

さらに、xjjdog にはこれを説明する別の記事があります: 分散メッセージング システム、設計ポイント。龍や虎の骨を描くのは難しい

要件は非常に多くありますが、モデルは非常にシンプルです。難しいところは何ですか？カフカを見ると頭痛がする学生もいるのはなぜでしょうか?

4. 義務を果たすように頼むのはどれほど難しいことでしょうか?

メッセージ システムのモデルは単純なプロデューサー/コンシューマー モデルですが、現在のメッセージ システムはなぜそれほど複雑なのでしょうか。実際、その複雑さは主に「分散」という 3 つの単語に反映されており、メッセージ キューとはほとんど関係がありません。すべての分散システムが直面しなければならないいくつかの問題に対処する必要があります。

4.1 コピー

ハード ドライブが故障したり、電源が落ちたり、光ケーブルが切断されたりする可能性があるため、単一のマシン上のデータは信頼できません。したがって、データのセキュリティは通常、複数の冗長コピーを使用することで確保されます。レプリカのもう 1 つの機能は、追加の計算能力を提供することです。たとえば、一部のリクエストはレプリカに送信されます。レプリカの数が多いほど、可用性が高まります。

レプリカを追加した後、データ同期の問題が発生します。最速の LAN でも遅延は発生します。マシンのパフォーマンスの違いによって同期の遅延が発生することは言うまでもありません。これにより問題が発生します。読み取りレプリカ要求によって読み取られたデータは最新ではない可能性があり、データの一貫性が変わったことを意味します。もちろん、データの一貫性を確保する手段はいくつかありますが、コピーの数が増えるほど遅延が大きくなります。

レプリカを追加すると、マスタースレーブ問題も発生します。マスターノードが停止すると、レプリカノードがその代わりを務める必要があります。このプロセスの調整には時間がかかり、この期間中はシステムの一部が利用できなくなる可能性があります。

すべてのメッセージング システムでは、これらの例外を処理するために大量のコードが必要です。

4.2 パーティション分割

データの種類が十分に大きく (テーブルなど)、そのデータに対する操作に非常に時間がかかる場合、そのようなデータを分割して複数のマシンに分散する必要があります。このカット処理はシャーディングと呼ばれ、特定のルールに従ってシャーディングを行うことで、単一のクエリデータのサイズを縮小し、クラスターの容量を増加させます。

シャードのデータを書き込むことができる場所はマスターの 1 か所のみです。他のレプリカはマスターからデータをコピーします。

レプリカは読み取り操作の並列性を高めることができますが、ダーティなデータを読み取る可能性があります。読み取りたいデータが一貫している場合は、KAFKA の ack=-1 などの同期書き込みレプリカ方式を使用できます。すべての同期が成功した場合にのみ、送信は成功したとみなされます。

ただし、コピーが多すぎると、このプロセスは非常に遅くなります。書き込みと読み取りのレプリカ数を割り当てることで、書き込みと読み取りの効率を調整することができます。 Quorum の R+W>N はトレードオフ戦略です。

5. Kafka 用語集

Kafka の定義を逆に見てみると、はるかに簡単になります。

Kafka は分散メッセージング (ストレージ) システムです。分散システムでは、シャーディングによって並列性が向上し、レプリカによって信頼性が向上しますが、Kafka も例外ではありません。その構造は、上で紹介した基本的な分配理論から逃れることはできません。レプリカ、パーティション、トピック チャネル、プロデューサー、コンシューマーなどの用語を組み合わせると、グラフが非常に大きくなる可能性があります。

マシンに Kafka をインストールすると、このマシンはブローカーと呼ばれます。 Kafka クラスターには、このようなインスタンスが 1 つ以上含まれています。これは単なる名前であり、特別な意味はありません。

KAFKA にデータを書き込むコンポーネントはプロデューサーと呼ばれ、メッセージ プロデューサーは通常、ビジネス システムに記述されます。うちの牛乳配達人と同じ大きさです。

KAFKA に送信されるメッセージには複数の種類がある場合があります。カテゴリーを区別するにはどうすればいいでしょうか?これがトピックの概念です。トピックが配布されると、複数のブローカー上に存在する可能性があります。

トピックが複数のセグメントに分割され、並列度が高められた後、各セグメントはパーティションと呼ばれ、パーティションは通常、すべてのマシンに均等に分散されます。

Kafka でデータを消費するアプリケーションはコンシューマーと呼ばれます。トピックの消費者ビジネスに名前を付けるので、名前は Consumer Group と呼ばれます。

Kafka Server の設定ファイルを見てみましょう。最も重要な 2 つのパラメーター、partitions と replication.factor は、実は非常に簡単に理解できます。

最も重要な概念についてお話ししましょう。 Kafka は ISR を使用してレプリカ間の同期を解決します。これは、Kafka 面接で必ず知っておくべきポイントの 1 つです。

ISR は「In-Sync Replicas」の略で、HA と一貫性を確保するための重要なメカニズムです。レプリカの数は Kafka のスループットに一定の影響を及ぼしますが、可用性は大幅に向上します。一般的には2～3個が適切です。

レプリカには 2 つの要素があります。1 つは数が十分である必要があること、もう 1 つはレプリカが同じインスタンスに存在しない必要があることです。 ISR はパーティションを表し、各パーティションには同期リストがあります。 N 個のレプリカのうち、1 つのレプリカがリーダーであり、その他はフォロワーです。リーダーはパーティションのすべての読み取りおよび書き込み要求を処理し、その他はバックアップです。同時に、フォロワーはリーダーのデータを受動的かつ定期的にコピーします。

フラワーがリーダーより大幅に遅れている場合、または一定期間データ複製要求を開始しない場合、リーダーはフラワーを ISR から削除します。

リーダーは、ISR 内のすべてのレプリカがリーダーに ACK を送信した場合にのみコミットします。

6. メッセージングシステムの役割

ここまで説明してきたので、コンピューター用語を使ってメッセージ キューの役割を説明しましょう。

ピークカットは、業務システムの処理能力を超える要求に対応し、円滑な業務運営を実現するために使用されます。これにより、多くのコストを節約できます。たとえば、一部のフラッシュセールはピーク時の容量を考慮して設計されていません。

バッファリングは、サービス レイヤーと低速着陸レイヤーにバッファー レイヤーとして存在します。その機能はピークシェービングに似ていますが、主にサービス内のデータフローに使用されます。たとえば、バッチ SMS メッセージを送信します。

デカップリング プロジェクトの開始時には、具体的な要件を決定することはできません。メッセージ キューは、重要なビジネス プロセスを分離するためのインターフェイス レイヤーとして機能します。拡張機能を得るには、規則に従い、データに対してプログラムするだけです。

冗長メッセージ データは、複数の無関係なビジネスに対して 1 対多の方法で使用できます。

堅牢なメッセージ キューはリクエストを蓄積できるため、コンシューマー側のビジネスが短時間停止しても、メイン ビジネスの正常な動作には影響しません。

しかし、カフカは優秀な人なので、非常に複雑で、より多くのことができるのです。その職務範囲はより広範囲にわたり、以下を含みますが、これらに限定されません。

1. ビジネスメッセージの配信
2. ユーザーアクティビティログ • 監視項目等
3. ログ
4. ストリーム処理（一部の集計など）
5. コミットログは、いくつかの重要なサービスの冗長性として機能します。
6. イベント ソース、実践的なトレース、DDD の概念

以下は、ログ記録の一般的な使用シナリオです。

7. KAFKA が高速なのはなぜですか?

Kafka は一般的にその速度のために使用されるため、以前は一部のログ メッセージしか処理できないと考えられていました。実際、Kafka は最も複雑なトランザクション メッセージもサポートしており、その素晴らしさはそのスピードによって影を潜めています。

それで、なぜそんなに速いのでしょうか?まとめると、いくつかの理由があります。

1. キャッシュ ファイルシステム キャッシュ ページキャッシュ キャッシュ
2. 順次書き込み 最新のオペレーティング システムでは先読みと先書きの技術が提供されているため、ディスクへの順次書き込みはメモリへのランダム書き込みよりも高速になることがよくあります。
3. ゼロコピー、メモリスワップが1つ少ない
4. メッセージのバッチ処理。小さなリクエストをマージし、ストリーミング方式でやり取りしてネットワークの制限に達する
5. プル モードでは、プル モードを使用してメッセージを取得および消費します。これは、コンシューマー側の処理機能と一致します。

これらが主な5つのポイントです。圧縮、JVM パフォーマンスの最適化などについては、すべて子供の遊びであり、言及する価値はありません。

終わり

ご覧のとおり、Kafka はメッセージ処理とデータ保存の両方を実行できる万能プレーヤーです。後悔なく働き、効率も極めて高いが、一瞬たりとも休むことなく働かなければならない。これは労働者の最も悲劇的な運命を体現している。

分散システムの設計も非常に優れています。これは、設計者によってカスタマイズされたシステムです。Kafka ノードがダウンすると、より多くの Kafka ノードがその代わりとなり、10 秒ほどの苦労の末、その犠牲を完全に忘れることができます。

Kafka は分散メッセージング システムですが、やりすぎには注意してください。過酷な環境でもその不屈の精神を磨くために、CPU コア 1 個とメモリ 512M のみが割り当てられています。

データを失って、それでも不安定さのせいにするなら、良心が痛むのではないでしょうか?

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