メッセージブローカーを理解する。 ActiveMQ と Kafka を使用したメッセージングの仕組みを学習します。 第1章

みなさん、こんにちは！

私は小さな本の翻訳を始めました。
«メッセージブローカーを理解する"、
著者：Jakub Korab、出版社：O'Reilly Media, Inc.、発行日：2017 年 9781492049296 月、ISBN：XNUMX。

この本の紹介文より：
"... この本では、Apache ActiveMQ と Apache Kafka という XNUMX つの人気のあるブローカー テクノロジを比較対照しながら、ブローカー メッセージング システムについて考える方法を説明します。 ここでは、開発者が同じ分野、つまり中間ブローカーを使用したシステム間のメッセージングに対して非常に異なるアプローチを取るようになったユースケースと開発インセンティブについて概説します。 これらのテクノロジーを根本から検討し、その過程でのさまざまな設計選択の影響を強調します。 両方の製品を深く理解し、その使用方法と使用すべきでないことを理解し、将来他のメッセージング テクノロジを検討する際に何に注意すべきかを理解することができます。 ... "

これまでに翻訳された部分:
第1章;序章
第3章 カフカ

完成した章は翻訳され次第掲載します。

CHAPTER 1

導入

システム間のメッセージングは​​、IT の分野で最も理解されていない領域の XNUMX つです。 開発者またはアーキテクトとして、さまざまなフレームワークやデータベースに精通しているかもしれません。 ただし、ブローカーベースのメッセージング テクノロジがどのように機能するかについては、おそらくほんの少ししか理解していないでしょう。 このように感じても、心配しないでください。あなたは良い仲間です。

通常、人々がメッセージング インフラストラクチャと接触することは非常に限られています。 彼らは多くの場合、ずっと前に作成されたシステムに接続するか、インターネットからディストリビューションをダウンロードして PROM にインストールし、そのコードの作成を開始します。 PROM でインフラストラクチャを実行した後、結果はさまざまです。障害によりメッセージが失われたり、送信が期待どおりに機能しなかったり、ブローカーがプロデューサを「ハング」させたり、コンシューマにメッセージを送信しなかったりします。

おなじみのように聞こえますか？

一般的なシナリオは、当面はメッセージング コードがうまく機能する場合です。 機能しなくなるまで。 この期間は、人の警戒心を誤った安心感に陥らせ、テクノロジーの基本的な動作についての誤った信念に基づいたコードが増加することにつながります。 物事がうまくいかなくなり始めると、不都合な真実に直面することになります。それは、製品の根本的な動作や、パフォーマンスと信頼性、トランザクション性と水平スケーラビリティなど、作成者が選択したトレードオフを実際には理解していないということです。 。

ブローカーがどのように機能するかを深く理解していない人々は、メッセージング システムについて次のような一見合理的な発言をします。

• システムはメッセージを決して失うことはありません
• メッセージは順番に処理されます
• コンシューマーを追加するとシステムが高速化します
• メッセージは一度だけ配信されます

残念ながら、これらの記述の中には、特定の状況下でのみ適用される仮定に基づいているものもあれば、単に間違っているものもあります。

この本では、Apache ActiveMQ と Apache Kafka という XNUMX つの人気のあるブローカー テクノロジを比較対照しながら、ブローカー ベースのメッセージング システムについて考える方法を説明します。 ここでは、開発者が同じ分野、つまり中間ブローカーを使用したシステム間のメッセージングに対して非常に異なるアプローチを取るようになったユースケースと開発インセンティブについて概説します。 これらのテクノロジーを根本から検討し、その過程でのさまざまな設計選択の影響を強調します。 両方の製品を深く理解し、その使用方法と使用すべきでないことを理解し、将来他のメッセージング テクノロジを検討する際に何に注意すべきかを理解することができます。

始める前に、基本を確認しましょう。

メッセージング システムとは何ですか?なぜ必要ですか?

XNUMX つのアプリケーションが相互に通信するには、まずインターフェイスを定義する必要があります。 このインターフェイスの定義には、HTTP、MQTT、SMTP などのトランスポートまたはプロトコルの選択と、システム間で交換されるメッセージ形式のネゴシエーションが含まれます。 これは、メッセージ ペイロードのコスト要件を備えた XML スキーマの定義などの厳密なプロセスである場合もあれば、HTTP リクエストの一部にクライアント ID が含まれるという XNUMX 人の開発者間の合意など、それほど形式的ではない場合もあります。

メッセージの形式とメッセージの送信順序がシステム間で一貫している限り、他のシステムの実装を気にすることなく相互に通信できます。 使用されるプログラミング言語やフレームワークなど、これらのシステムの内部は時間の経過とともに変化する可能性があります。 契約自体が維持されている限り、相手側からの変更はなくやり取りを続けることができます。 XNUMX つのシステムは、このインターフェイスによって効果的に分離 (分離) されます。

通常、メッセージング システムには、送信者を受信者からさらに切り離す (分離する) ために対話する XNUMX つのシステム間の仲介者が関与します。 この場合、メッセージング システムを使用すると、送信者は受信者がどこにいるか、受信者がアクティブであるかどうか、インスタンスがいくつあるかを知らなくてもメッセージを送信できます。

メッセージング システムが解決する問題の種類についていくつかの類似点を見て、基本的な用語をいくつか紹介しましょう。

ポイントツーポイント

アレクサンドラはアダムに荷物を送るために郵便局に行きます。 彼女は窓口に行き、従業員に荷物を手渡します。 従業員は荷物を受け取り、アレクサンドラに領収書を渡します。 アダムは荷物の発送時に家にいる必要はありません。 アレクサンドラは、荷物は将来のある時点でアダムに届けられると確信しており、仕事を続けることができます。 その後、ある時点でアダムは荷物を受け取ります。

これはメッセージング モデルの例です ポイントからポイントへ。 ここの郵便局は荷物の配送メカニズムとして機能し、各荷物が XNUMX 回ずつ配達されることを保証します。 郵便局を利用すると、荷物を送る行為と荷物の配達が分離されます。
従来のメッセージング システムでは、ポイントツーポイント モデルは次のように実装されます。 очереди。 キューは、XNUMX つ以上のコンシューマがサブスクライブできる FIFO (先入れ先出し) バッファとして機能します。 各メッセージは配信されるだけです 購読している消費者の一人に。 通常、キューはコンシューマ間でメッセージを公平に分散しようとします。 このメッセージを受信するのは XNUMX 人の消費者だけです。

「永続的」という用語はキューに適用されます。 信頼性 は、コンシューマがメッセージ配信用のキューにサブスクライブするまで、アクティブなサブスクライバが存在しない場合でも、メッセージング システムがメッセージを保持することを保証するサービス プロパティです。

信頼性はよく混同されますが、 持続性 この XNUMX つの用語は同じ意味で使用されますが、異なる機能を果たします。 永続性は、メッセージング システムがメッセージを受信して​​からコンシューマーに送信するまでの間にメッセージを何らかのストレージに書き込むかどうかを決定します。 キューに送信されるメッセージは永続的な場合とそうでない場合があります。
ポイントツーポイント メッセージングは​​、ユースケースでメッセージに対する XNUMX 回限りのアクションが必要な場合に使用されます。 例には、口座への資金の入金や配送注文の完了などが含まれます。 メッセージング システム自体が XNUMX 回限りの配信を提供できない理由と、キューがせいぜい配信保証を提供できる理由については後で説明します。 少なくとも一度は.

パブリッシャー-サブスクライバー

ガブリエラは会議番号にダイヤルします。 彼女は会議に接続している間、残りの通話参加者とともに、発言者の発言をすべて聞くことができます。 彼女は音を外してしまうと、言われたことを聞き逃してしまいます。 再接続すると、話されている内容を聞き続けます。

これはメッセージング モデルの例です パブリッシュ-サブスクライブ。 電話会議はブロードキャスト メカニズムとして機能します。 話している人は、現在通話中の人数を気にしません。システムは、現在接続している人なら誰でも話している内容を聞くことができます。
従来のメッセージング システムでは、パブリッシュ/サブスクライブ メッセージング モデルは次の方法で実装されます。 トピック。 トピックは、会議メカニズムと同じブロードキャスト方法を提供します。 メッセージがトピックに送信されると、メッセージが配信されます 購読しているすべてのユーザー向け.

話題は通常、 信頼できない（耐久性がない）。 リスナーが切断すると電話会議での発言が聞こえなくなるのと同じように、トピック登録者はオフライン中に送信されたメッセージを聞き逃します。 このため、トピックは配信保証を提供すると言えます。 XNUMX回だけ 消費者ごとに。

パブリッシュ/サブスクライブ メッセージングは​​通常、メッセージが本質的に情報提供であり、XNUMX つのメッセージの損失が特に重大ではない場合に使用されます。 たとえば、トピックはセンサーのグループからの温度測定値を XNUMX 秒に XNUMX 回送信できます。 現在の温度に関心があり、トピックを購読しているシステムは、メッセージを見逃しても心配する必要はありません。近い将来、別のメッセージが到着します。

ハイブリッドモデル

ストアの Web サイトでは、注文メッセージが「メッセージ キュー」に配置されます。 これらのメッセージの主な利用者は実行システムです。 さらに、監査システムは、後続の追跡のためにこれらの注文メッセージのコピーを保持する必要があります。 どちらのシステムも、システム自体がしばらく利用できない場合でも、メッセージの通過を許可できません。 Web サイトは他のシステムを認識すべきではありません。

ユースケースでは、複数のシステムでメッセージのコピーが必要で、メッセージ損失を防ぐために信頼性と永続性の両方が必要な場合など、パブリッシュ/サブスクライブ モデルとポイントツーポイント メッセージング モデルの組み合わせが必要になることがよくあります。

これらのケースでは、メッセージを基本的にトピックとして配布する宛先 (キューとトピックの一般用語) が必要です。そのため、各メッセージは、それらのメッセージに関心のある別個のシステムに送信されますが、各システムでは、受信する受信者を複数のコンシューマーを定義することもできます。メッセージ。キューに似ています。 この場合の読み取りタイプは次のとおりです。 関係者ごとに XNUMX 回。 これらのハイブリッド宛先では、多くの場合、コンシューマがオフラインになった場合に、その時点で送信されたメッセージがコンシューマの再接続後に受信されるように、耐久性が必要です。

ハイブリッド モデルは新しいものではなく、ActiveMQ (トピックとキューを組み合わせた仮想または複合宛先経由) と Kafka (宛先設計の基本プロパティとして暗黙的に) の両方を含む、ほとんどのメッセージング システムで使用できます。

基本的な用語をいくつか理解し、メッセージング システムを何に使用できるかを理解したところで、詳細に移りましょう。

翻訳完了: tele.gg/middle_java

以下の翻訳部分： 第3章 カフカ

継続するには...

出所： habr.com