このレッスンでは、我々は、メッセージキューのキュー、トピック、パーティションなどの基本的な概念を学ぶ必要があります。これらの概念的基礎、あなただけそれらをすべて知っているよう、私たちは、フォローアップ調査を行うためには、プログラミング言語の基本的な構文を学ぶよう。
あなたは一つのメッセージ・キューイング製品よりももっと勉強した場合には、あなたは、各メッセージキューはキュー（待ち行列）テーマ（トピック）またはパーティション（パーティション）これらの用語や概念のように、メッセージモデルの独自のセットを持っていることに気づいたかもしれません各メッセージキューモデルは同じではありませんまた、いくつかの意味を含むことになります。
なぜこのような状況はありますか？標準的ではありませんので。一時期、国際機関の数は、このような早期のJMSやAMQPなどのメッセージ関連の標準を通じて開発しようもあります。しかし、イライラは進化の標準税率は、メッセージキューに追いつくために進化したことで、これらの基準は、実際に放棄されています。
だから、最後にキューは何ですか？テーマは何ですか？トピックとキュー、それがどのような違いを生むのでしょうか？完全にこのことを理解したい、私たちは、メッセージキューからの進化について話をする必要があります。
トピックとキューの違いは何ですか？
インターネットの途中で建築家の円は、そのようなの広がりが引用のソースを知らない、私は非常に同意し、愛：良いアーキテクチャを設計するのではなく、アウト進化していません。パターンを示すキュー現代のメッセージは徐々に進化の10年後に以前と同じです。
元のメッセージキューは、キューは、厳密な意味です。コンピュータの分野では、「キュー（待ち行列）は、」データ構造、完全かつ厳密な定義です。ウィキペディアは、キューは次のように定義されています。
キューはFIFO（FIFO、先入れ先出し）リニアフォーム（線形リスト）です。典型的にはアレイまたは特定用途にリンクされたリストを使用して。キュー（REARをいう。）のみ後端フロントエンド（フロントと呼ばれる）で操作、削除操作を挿入します。
いくつかの重要なポイントが含まれています。この定義は、最初のものは最初に出で初めてです、要件はチームのプロセスにチームのニュースでは、必要がこれらのメッセージがキューに書き込まれたものを順番に、厳格かつ秩序であることを保証するために、ということを意味していますこれは、同じ順序でキューから読み取らなければなりません。しかし、キューが、この操作を「読み取り」キューからメッセージを「削除」であるチームは、ある「読み」ではありません。
初期のメッセージキューは、「キュー」の設計データ構造に従ったものです。一緒に私たちは、この図を見て、プロデューサー（プロデューサー）、消費者（消費者）がメッセージ受信したメッセージのエンキュー操作は、削除操作、コンテナのストレージ・サーバ・メッセージは、当然と呼ばれるチームがされている「キューを。」
待ち行列モデル：これは、メッセージングモデルの最初のです。
複数の生産者は、内部の同じキューにメッセージを送信がある場合は、このキューがメッセージを消費することができ、メッセージは、これらの生産者が生産の全てのコレクションです。これらの生産者のメッセージシーケンスは、自然順序メッセージで送信されます。同じメッセージキューを受信するための複数のコンシューマがある場合は、これらの消費者の間の関係は、実際に競合している、各消費者はそれらのいずれかが唯一のメッセージとすることができることを、メッセージキューの一部を受け取ることができます消費者が受け取ります。
あなたは、複数の消費者に配布メッセージデータのコピーが必要な場合は、各消費者が注文データ、リスク管理システム、分析システム、決済システムのために、例えば、メッセージの全額を受け取るので、メッセージを受信する必要ができることが必要です。今回は、単一のキューは、可能な解決策は、生産者が複数のコピーを送信するように、各消費者のために別々のキューを作成することで、需要を満たすことはありません。
もちろん、これはデータが複数のキューにコピーされたメッセージの同じコピーは、リソースの無駄になり、比較的愚かなアプローチであり、より重要なのは、生産者はどのように多くの消費者を知っている必要があります。設計された「デカップリング」のメッセージ・キューに実際に反して、個々の消費者のためのメッセージを送信します。
「 - サブスクライブ・モデル（パブリッシュ・サブスクライブの模様）公開」：この問題を解決するために、モデルは、別のメッセージを進化しました。
でパブリッシュ - サブスクライブ・モデルを、メッセージの送信者は、（出版社）の加入者（加入者）と呼ばれるメッセージの受信者を発行者と呼ばれる、サーバー・ストレージ・コンテナは、ニュースの話題（トピック）と呼ばれます。パブリッシャーがトピックにメッセージを送信し、加入者は、メッセージを受信する前に「のトピックをサブスクライブ」する必要があります。ここで「購読」アクションの両方ですが、また消費の時点で話題の論理コピーと考えることができ、各サブスクリプションは、加入者は、すべてのニューストピックを受け取ることができます。
長時間のメッセージフィールドの歴史の中で、キューモードと公開 - などActiveMQのように、両方のメッセージングモデル、いくつかのメッセージキューのサポートをモデル共存をサブスクライブします。我々は慎重にキューが対象となり、消費者が加入者である、出版社はプロデューサーである、二つのモデルを比較して、本質的な違いはありません。それらの間の最大の違いは、実際には、メッセージデータは何回もの消費者問題になることはできません。
実際には、このパブリッシュ - サブスクライブ・モデルを、一つだけの加入者、およびキューモデル、それは基本的に同じである場合。言い換えれば、パブリッシュ - 機能レベルでサブスクライブ・モデルを互換性のあるキューモデルです。
メッセージキュー製品内のメッセージの現代のモデルは主にこのパブリッシュで使用されている - サブスクライブ・モデル、もちろん、例外もあります。
RabbitMQのメッセージングモデル
例外はRabbitMQのですが、それはいくつかは、まだ製品の1の待ち行列モデルを使用して主張しています。つまり、消費者の問題は解決しませんどのようにでしょうか？あなたは、私がレッスンその上のExchangeモジュールの機能でのRabbitMQの話を覚えていますか？RabbitMQのでは、Exchangeは生産者とキューの間に配置され、生産者にメッセージの送信キューいる気にしませんが、Exchangeにメッセージを送信するために、ポリシーは、メッセージがキューに配信される取引所の構成によって決定されます。
メッセージの同じコピーを過ごすにはより多くの消費者にする必要がある場合は、消費者に消費者サービスを提供することができ、それぞれが完全なメッセージデータに格納されている、複数のキューにメッセージを送信するようにExchangeを構成する必要があります。この機能を「メッセージデータが消費する多くの倍以上の加入者することができ、」サブスクリプション・モデル-これはまた変装新しいリリースで達成することができます。あなたは、特定の構成RabbitMQの公式のチュートリアルを参照することができ章では、具体的サブスクリプションを公開する方法についてです。
RocketMQニュースモデル
RabbitMQのメッセージングモデルが終了し、私たちはRocketMQを見てみましょう。標準を使用してRocketMQメッセージモデルが公開 - RocketMQ用語集、生産者、消費者とテーマに、モデルをサブスクライブし、私は上記のリリースで話している - モデルのコンセプトを購読まったく同じです。
しかし、RocketMQにも、この概念キュー（待ち行列）を有しており、キューは、そのキューRocketMQそれがどのような役割であるでRocketMQで非常に重要な概念ですか？これは話してメッセージキュー機構の消費からです。
メッセージが原因転写プロセスにおけるネットワークやサーバの障害のために失われていないことを確実にするためのメカニズムを - ほとんどすべてのメッセージキュー製品のは、非常に単純な「確認要求」を使用します。具体的なアプローチは非常に簡単です。生産の終わりには、プロデューサーの最初のメッセージがサーバに送信され、すなわちブローカーは、サーバーがメッセージトピックまたはキュー書き込みを受けた後にメッセージを送信し、プロデューサーが応答確認を送信します。
メッセージを受信した後、最終消費者に消費者をして（例えば、データベース内のデータを保存するために）彼らの消費者のビジネスロジックを完了し、生産者が受信された確認やサーバ障害応答を受信しない場合、デバイスは、メッセージを送信します、それ以外の場合は、あなたが成功の確認、対応する消費を受け取るまで、消費者がメッセージを再送与えるだけメッセージが正常に消費だと思う、唯一の消費の確認を受けた後、サービスの最終消費者の成功の確認にサーバーが送信されます。
確認応答メカニズムメッセージ配信プロセスの信頼性を確保するための良い方法は、しかし、消費者側では、このメカニズムの導入は大きな問題をもたらしました。何が問題でしょうか？消費者が成功する前にメッセージの秩序性を確保するために、メッセージは、次のメッセージがそうでない場合、メッセージがこの原則の順に反し、何も表示されますが、消費することはできません。
これは、消費者支出を行うせいぜい1つのインスタンス、任意の時点でそれぞれのテーマである、拡張の消費者の数によって、消費者の最終消費者のパフォーマンスの全体的なレベルを向上させることは不可能であろう。この問題を解決するには、以下のトピックでRocketMQは、キューの概念を追加しました。
各テーマは、並列キュー複数の生産と消費の複数のインスタンスを実装するために、複数のキューを含みます。RocketMQがテーマだけレベルでのメッセージの整然としたキューが厳しいためのメッセージという保証するものではないことを確認、ということに注意してください。
RocketMQは、加入者の概念が具現化されるコンシューマ・グループ（コンシューマ・グループ）を介してです。各コンシューマ・グループの消費者のトピックは、メッセージは、消費者グループ2の消費を与えるだろう、あまりにも消費者グループ1の消費量がある、すなわち、完全なメッセージでは、異なる消費者団体間の消費の進行がお互いに影響を与えています。
消費者グループは、消費者の同じグループ内の複数の消費者が含まれている競争の消費量との関係で、各消費者は、消費者グループ内のメッセージの一部を担当しています。メッセージは、消費者Consumer1、他の消費者は、もはやこのメッセージを受信しません同じグループが消費された場合。
消費プロセスのトピック、メッセージは、消費者がメッセージを完了し、すぐに除去することが、各コンシューマ・グループのRocketMQ消費を必要とする（各キュー上の位置を維持しないので、複数の消費者の異なるセットする必要があるためこの位置のニュースはニュースが消費されなかった後に成功した各メッセージの消費のために、前に消費される前に、消費者オフセット）は、消費の場所がプラスです。私たちは、メッセージキューを使用する場合、メッセージが原因消費者の場所の不適切な取り扱いにほとんどが失われているため、消費者の位置は、非常に重要な概念です。
より重要なRocketMQメッセージモデルは、これらの概念ということです。あなたの理解を容易にするために、私は以下の絵を描きました。
あなたはこの絵を制御することができ、その後、私はこれらの概念を消化し、理解を深めていき言います。
カフカのメッセージモデル
私たちは、他の一般的なメッセージキューカフカを見てみましょう、とRocketMQカフカのメッセージモデルがまったく同じで、私はちょうど対応する肯定応答機構と、生産と消費の過程で言うすべてRocketMQの概念は、完全にはカフカにも適用可能です。唯一の違いはカフカに、この概念のキューの名前が同じではないことである、対応する名前カフカは意味や機能が異なっていない、「パーティション（パーティション）」です。
概要
私たちは、学ぶためにこのレッスンの内容を要約したものです。 - サブスクライブ・モデル待ち行列モデルと公開：まず、私たちは、実際には2つの異なるメッセージングモデルに対応する2つの概念の後ろに、キューとトピックの違いについて話しました。次に、2つのニュースのモデルは、実際には根本的に異なるものではないことを理解する必要があり、お互いを拡張したり交換する変更の数を介して利用できます。
共通メッセージキューは、RabbitMQのキューモデルが使用されているが、それはまだ公開達成することができます - 機能をサブスクライブします。サブスクライブ・モデル、および両方のモデルは基本的に同じメッセージです - RocketMQとカフカは、パブリッシュを使用しています。
最後に、あなたを思い出させるために、私はこのレッスンのメッセージモデルおよび関連する概念について語るビジネスレベルのモデルであり、ビジネスモデルの深い理解は、メッセージキューを使用するのに最適な姿勢をお届けします。
但业务模型不等于就是实现层面的模型。比如说 MySQL 和 Hbase 同样是支持 SQL 的数据库，它们的业务模型中，存放数据的单元都是“表”，但是在实现层面，没有哪个数据库是以二维表的方式去存储数据的，MySQL 使用 B+ 树来存储数据，而 HBase 使用的是 KV 的结构来存储。同样，像 Kafka 和 RocketMQ 的业务模型基本是一样的，并不是说他们的实现就是一样的，实际上这两个消息队列的实现是完全不同的。
思考题
最后给大家留一个思考题。刚刚我在介绍 RocketMQ 的消息模型时讲过，在消费的时候，为了保证消息的不丢失和严格顺序，每个队列只能串行消费，无法做到并发，否则会出现消费空洞的问题。那如果放宽一下限制，不要求严格顺序，能否做到单个队列的并行消费呢？如果可以，该如何实现？欢迎在留言区与我分享讨论。