アリババ:RocketMQを10分で始めよう

クズども · 掲載地 2017/07/28 20:26:52

この記事ではまず、メッセージミドルウェアが通常解決すべき問題、これらの問題解決に直面する困難、Apache RocketMQをAlibabaによる高性能・高スループットの分散型メッセージミドルウェアとしてオープンソースとして解決できるかどうか、そして仕様書上でこれらの問題がどのように定義されているかについて触れます。この記事では、読者がRocketMQについて素早く理解できるように、RocketMQのアーキテクチャ設計を紹介します。
1. メッセージミドルウェアはどのような問題を解決する必要があるのか? Publish/Subscribeはメッセージミドルウェアの最も基本的な機能であり、従来のRPC通信に対しても相対的な機能です。ここでは詳しくは触れません。
メッセージ優先度仕様で記述されている優先度はメッセージキューを指し、各メッセージは異なる優先度を持ち、一般的に整数で表されます。優先度の高いメッセージが最初に配信されます。メッセージが完全にメモリキュー内にある場合は、優先順位に従ってソートしてから配信し、高い優先度が先に届けられるようにします。
RocketMQのすべてのメッセージは永続的であるため、優先順位でソートされるとオーバーヘッドが非常に大きくなります。そのため、RocketMQはメッセージ優先度を明確にサポートしていませんが、類似の機能を回避策として実装できます。つまり、高優先度のキューと通常の優先度のキューを設定し、異なる優先度を異なるキューに送信するというものです。
優先事項については、2つのカテゴリーにまとめることができます。

優先度が達成されていれば、厳密な意味での優先度とは言えず、優先度は通常、高、中、低、または複数のレベルに分けられます。各優先度は異なるトピックで表現でき、メッセージ送信時には優先度を表す異なるトピックを指定することで、ほとんどの優先度問題を解決できますが、ビジネスの優先度の正確さを損なうことになります。
厳密な優先度の場合、優先度は0 ~ 65535のように整数で表されますが、この種の優先度問題は一般的に異なるトピックで解くことに適していません。 MQでこの問題を解決したいのであれば、MQのパフォーマンスに大きな影響を与えます。ここで、ビジネスが本当にこの厳格な優先順位付けを必要としているかを確認するポイントがあります。そして、優先事項が少数に圧縮された場合、それがビジネスにどれほどの影響を与えるでしょうか?

メッセージの順序とは、送信された順序で消費できるメッセージの一種を指します。例えば、注文は注文作成、注文支払い、注文完了の3つのメッセージを生成します。消費する際には、この順番で消費することが意味があります。しかし同時に、注文は並行して消費することも可能です。
RocketMQはメッセージの秩序を厳密に保証できます。
メッセージフィルターブローカーメッセージフィルタリング
ブローカーでは、消費者の要件に応じたフィルタリングは、不要なメッセージの送信を減らすという利点があります。
欠点は、ブローカーの負担が増え、実施が比較的複雑になることです。
1. Taobao Notifyは、メッセージタイプによる直接フィルタリングや柔軟な構文表現フィルタリングなど、ほぼ最も要求の高いフィルタリングニーズを満たす多様なフィルタリング方法をサポートしています。
2. Taobao RocketMQは、シンプルなメッセージタグ、メッセージヘッダーおよび本文によるフィルタリングをサポートしています。
3. 柔軟な構文式フィルタリングもCORBA通知仕様でサポートされています。
コンシューマー側のメッセージフィルタリング
このフィルタリングはアプリケーションによって完全にカスタマイズ可能ですが、欠点として多くの無意味なメッセージが消費者に送られてしまうことです。
メッセージ永続化でよく使われるいくつかの永続化手法があります:

Mysqlなどのデータベースに永続化します。
levelDB、Berkeley DBなどのKVストレージに永続化します。
ファイルレコードの形での永続性(Kafka、RocketMQ など)
BeanstalkdやVisiNotifyのようなメモリデータの永続イメージを作成します
(1)、(2)、(3)これら3つの永続化メソッドはすべてメモリキューバッファを拡張できる能力を持ち、(4)は単なるメモリイメージであり、ブローカーがハッシュして再起動した後も前のメモリからデータを復元できます。

JMSおよびCORBA通知仕様は、永続化方法を明示的に指定していませんが、永続化部分のパフォーマンスがメッセージミドルウェア全体の性能を直接決定します。
RocketMQはLinuxのファイルシステムのメモリキャッシュを最大限に活用し、パフォーマンスを向上させています。
メッセージ信頼性がメッセージの信頼性に影響を与える状況はいくつかあります:

ブローカーは通常通りクロージングします
ブローカーの暴落
OSクラッシュ
機械は電源を失いますが、電源はすぐに復旧可能です。
マシンが起動しません(CPU、マザーボード、メモリなどの重要なデバイスが損傷している可能性があります)。
ディスク機器の損傷。

(1)、(2)、(3)、(4)はすべてハードウェアリソースを即座に回復できる状況であり、RocketMQはメッセージの損失や少量のデータ損失を保証できます(フラッシュ方式が同期か非同期かによります)。
(5)(6) これは単一障害点であり、一度発生すると回復できず、この点上のすべてのメッセージは失われます。いずれの場合も、RocketMQは非同期レプリケーションによるメッセージの99%の喪失を保証していますが、失われる可能性のあるメッセージは非常に少ないです。同期デュアルライト技術は、性能に影響を及ぼすシングルポイントを完全に回避できるため、マネー関連アプリケーションなど非常に高いメッセージ信頼性要件を持つ状況に適しています。
RocketMQはバージョン3.0から同期デュアル書き込みをサポートしています。
低遅延メッセージングは、メッセージがブローカーに到達した直後に、メッセージの蓄積なしに消費者に到達できます。
RocketMQは長いポーリングプル方式を採用し、メッセージが非常にリアルタイムであり、リアルタイムメッセージがプッシュより低くないことを保証します。
少なくとも一度は、各メッセージが一度だけ届けられることを意味します。
RocketMQ Consummerはまずメッセージをローカルエリアに引き寄せ、消費が完了するとACKをサーバーに返します。
ちょうど一度だけ

送信メッセージステージでは重複メッセージの送信はできません。
コンシューム・メッセージ段階では、重複したメッセージの消費は許可されません。

上記の2つの条件が満たされた場合にのみ、メッセージは「正確に一度だけ」とみなされ、上記の2点を達成するために分散システム環境では必然的に大きなオーバーヘッドが生じます。したがって、高性能を追求するためにはRocketMQはこの機能を保証せず、ビジネス上の重複除去が必要であり、消費者メッセージは冪等性でなければなりません。 RocketMQは重複防止を厳密に保証することはできませんが、通常であれば繰り返し送信や消費は稀で、ネットワークの異常、コンシューマーの開始・停止、メッセージの重複などの異常な状況のみが発生します。
この問題の根本的な理由は、ネットワーク通話に不確実性、すなわち成功も失敗もない第三の状態が存在するため、メッセージの繰り返しの問題が生じます。
ブローカーズバッファが満杯の場合、どうすればよいですか? ブローカーのバッファは通常、ブローカー内のキューのメモリバッファサイズを指しますが、キューのサイズに制限がある場合、バッファが満杯の場合はどうなりますか?
CORBA通知仕様では以下の扱い方が示されています:

RejectNewEventsは新しいメッセージを拒否し、RejectNewEventsのエラーコードをプロデューサーに返します。
特定のポリシーに従って既存のメッセージを破棄する
- AnyOrder - オーバーフロー時に任意のイベントを破棄できます。このプロパティのデフォルト設定です。
- FifoOrder - 最初に受け取ったイベントは最初に破棄されます。
- LifoOrder - 最後に受け取ったイベントが最初に破棄されます。
- PriorityOrder - イベントは優先順に破棄し、低優先度のイベントが高優先度のイベントより先に破棄されるようにすべきです。
- DeadlineOrder - イベントは最短期限の順に破棄すべきです。

RocketMQにはメモリバッファの概念がなく、キューは永続的なディスクであり、データは定期的にクリアされます。
この問題の解決策として、RocketMQは他のMQと非常に大きな違いがあります。RocketMQのメモリバッファは無限長のキューに抽象化されており、どれだけ多くのデータが入ってきてもインストール可能です。この無限大は、ブローカーが期限切れのデータを定期的に削除することを前提としています。例えば、ブローカーは3日分のメッセージだけを保存しますが、バッファの長さは無限でも3日前のデータがキューの最後から削除されます。
回顧的消費とは、消費者が成功裏に消費したメッセージであり、ビジネス需要のためにそのメッセージを再消費する必要があることを意味します。例えば、消費者システムの故障により、1時間前のデータを回復後に再消費する必要があり、その後ブローカーは時間次元に応じて消費進捗を元に戻す仕組みを用意すべきです。
RocketMQは時間に基づく遡及消費をサポートしており、ミリ秒単位の時間次元を把握し、前後に遡ることができます。
メッセージスタッキングメッセージミドルウェアの主な機能は非同期デカップリングであり、もう一つの重要な機能はフロントエンドのデータフラッドピークをブロックし、バックエンドシステムの安定性を確保することです。これにより、メッセージミドルウェアは一定のメッセージスタッキング能力を持つ必要があります。メッセージヒープは以下の2つの状況を統合します。

メッセージはメモリバッファに蓄積され、メモリバッファを超えると、CORBA通知仕様に記載された特定のドロップポリシーに従ってメッセージを破棄できます。これは、破棄メッセージを許容できるサービスに適しています。この場合、メッセージの蓄積能力は主にメモリバッファのサイズにあり、メッセージをスタックした後のパフォーマンス低下はあまり大きくありません。なぜなら、メモリ内のデータ量が外部へのアクセス能力に限定的な影響を与えるためです。
メッセージはDBやKVストレージ、ファイルレコード形式などの永続的ストレージシステムに蓄積されます。メモリキャッシュ内のメッセージがヒットしない場合、ディスクにアクセスすることは避けられず、これにより大量の読み取りIOが発生し、読み取りIOのスループットがメッセージの蓄積後のアクセス能力を直接決定します。

メッセージ蓄積能力を評価する主なポイントは4つあります。

どれだけのメッセージを積み重ねられるのか、何バイト分? つまり、メッセージのヒープ容量です。
メッセージが積み重なった後、そのメッセージのスループットはスタッキングによって影響を受けますか?
メッセージが積み重なった後、消費者の通常の消費に影響は出ますか?
メッセージが積み重なった後、ディスク上に溜まったメッセージにアクセスするときのスループットはどのくらいになりますか?

分散トランザクション XA、JTAなどの既知の分散トランザクション仕様がいくつかあります。その中でも、XA仕様はOracleやMysqlなどの主要なデータベースベンダーによって広くサポートされています。その中でも、Oracle TuxedoのようなXAのTM実装リーダーは、金融、通信、その他の分野で広く利用されています。
分散トランザクションは2段階のコミット問題を伴い、データ保存の観点からはKVストレージをサポートする必要があります。なぜなら、コミットロールバックの第2段階ではメッセージの状態を修正し、キーに基づいてメッセージを見つける操作が必要だからです。 RocketMQは第2段階でキーに基づいてメッセージを見つける問題を回避し、第1段階で準備済みメッセージを送信し、メッセージのオフセットを取得し、第2段階でオフセット経由でメッセージにアクセスし状態を修正します。オフセットはデータのアドレスです。
RocketMQのトランザクション実装方法はKVストレージではなくオフセット方式で行われており、オフセット方式には大きな欠陥があり、オフセットによるデータ変更はシステム内に多くのダーティページが発生し、特別な注意が必要です。
スケジュールメッセージスケジュールメッセージとは、ブローカーに送信された直後に消費者がメッセージを消費できず、特定の時間点または特定の時間帯を待ってからのみ消費できることを意味します。
任意の時間精度をブローカーレベルでサポートしたいなら、メッセージソートを行う必要があり、永続性が関係している場合、メッセージソーティングは必然的に大きなパフォーマンスオーバーヘッドを伴います。
RocketMQはタイミングメッセージをサポートしていますが、任意の時間精度はサポートせず、5秒、10秒、1メートルなどの特定のタイミングレベルもサポートしています。
メッセージの再試行消費者がメッセージを消費しなかった場合、メッセージを再度消費させるリトライ機構を提供します。消費者消費メッセージの失敗は、通常以下の状況で考慮されます:

メッセージ自体の理由、例えばデシリアライゼーションの失敗により、メッセージデータ自体は処理できません(例えば電話料金の再充電、現在のメッセージの携帯電話番号がログアウト、充電不可など)。このエラーは通常、このメッセージをスキップして他のメッセージを消費し、この失敗メッセージは消費を直ちに再試しても99%の成功率が高いため、10秒後に再試すタイマー付きの再試行メカニズムを提供するのが最善です。
依存する下流アプリケーションサービスが利用できないため、例えばDB接続が利用できない、外部システムネットワークにアクセスできないなどです。このエラーが発生すると、現在の失敗メッセージがスキップされていても、他のメッセージも消費されます。この場合、スリープ30を適用して次のメッセージを消費することが推奨されており、これによりブローカーへのメッセージ再試行のプレッシャーを軽減できます。

RocketMQ概要 RocketMQが上記のメッセージミドルウェアが直面する問題を解決しているかどうかを見てみましょう。

RocketMQとは何ですか?

上記の図はメッセージミドルウェアの典型的な送受信モデルであり、RocketMQも同様に設計されています。簡単に言えば、RocketMQは以下の特徴を持っています。

これは、高パフォーマンス、高信頼性、高いリアルタイムかつ分散特性を持つキューモデルのメッセージミドルウェアです。
プロデューサー、コンシューマー、キューはすべて配布可能です。
プロデューサーは順にいくつかのキューにメッセージを送信し、キューコレクションはトピックと呼ばれます。消費者:ブロードキャスト消費の場合、1つの消費者インスタンスがそのトピックに対応するすべてのキューを消費し、クラスター消費の場合は複数の消費者インスタンスがこのトピックに対応するキューコレクションを均等に消費します。
厳格なメッセージの順序は保証されます
リッチなメッセージプルモードを提供します
効率的な水平加入者スケーリング機能
リアルタイムメッセージサブスクリプションメカニズム
数億件のメッセージ蓄積容量
依存性の減少

RocketMQの物理的展開構造

上の図に示されているように、RocketMQの展開構造は以下の特徴を持っています。

ネームサーバーは、ノード間の情報同期なしでクラスターに展開できる、事実上状態のないノードです。
ブローカーの展開は比較的複雑で、ブローカーはマスターとスレーブに分かれており、マスターは複数のスレーブに対応しられますが、スレーブは一つのマスターにしか対応できません。マスターとスレーブの対応は、同じBrokerName、異なるBrokerIdを指定することで定義されます。BrokerIdはマスターを0、非0はスレーブを示します。マスターは複数配置することも可能です。各ブローカーはネームサーバークラスター内のすべてのノードと長い接続を確立し、定期的にすべてのネームサーバーにトピック情報を登録します。
プロデューサーはネームサーバークラスタ内のノードのいずれかと(ランダムに選択)と長い接続を確立し、定期的にネームサーバーからトピックルーティング情報を取得し、トピックサービスを提供するマスターとの長い接続を確立し、定期的にマスターにハートビートを送信します。 Producerは完全にステートレスで、クラスターでデプロイ可能です。
消費者はネームサーバークラスタ内のノードのいずれか(ランダムに選択)と長い接続を確立し、定期的にネームサーバーからトピックルーティング情報を取得し、トピックサービスを提供するマスターとスレーブと長時間の接続を確立し、定期的にマスターとスレーブにハートビートを送信します。消費者はマスターとスレーブの両方からメッセージを購読でき、サブスクリプションルールはブローカーの設定によって決定されます。

RocketMQ論理展開構造

上の図に示されているように、RocketMQの論理展開構造には生産者と消費者の2つの特徴があります。

プロデューサーグループ

メッセージングアプリケーションを表すために使われるプロデューサーグループは、複数のプロデューサーインスタンスを含みます。これは複数のマシン、複数のマシンのプロセス、またはプロセスの複数のプロデューサーオブジェクトである場合があります。プロデューサーグループは複数のトピックメッセージを送信でき、プロデューサーグループは以下のように機能します。

生産者のタイプを特定する
O&Mツールを使って、このメッセージングアプリケーションに複数のProducerインスタンスが存在するかどうかを照会できます
分散トランザクションメッセージを送信する際、プロデューサーが予期せずダウンした場合、ブローカーはプロデューサーグループの任意のマシンを積極的に呼び戻し、取引状況を確認します。

消費者グループ

消費者メッセージングアプリケーションを表すために用いられる消費者グループは、複数の消費者インスタンスを含みます。これらは複数のマシン、複数のプロセス、またはプロセスの複数の消費者オブジェクトである場合があります。コンシューマーグループ内の複数のコンシューマーは均等に分散してメッセージを消費し、ブロードキャストに設定された場合、このコンシューマーグループの各インスタンスが全量のデータ消費を行います。

RocketMQデータストレージ構造

上の図に示されているように、RocketMQはデータをインデックスから分離する保存方式を採用しています。ファイルリソース、IOリソース、メモリリソースの損失を効果的に削減します。 Alibabaのような膨大なデータであっても、高同時進行シナリオはエンドツーエンドの遅延を効果的に削減し、強力な水平スケーリング能力を持つことができます。

リユノン · 掲載地 2017/07/29 8:09:37

甘謝鳳翔、共有ありがとうございます

アリババ:RocketMQを10分で始めよう

関連記事

閲覧したセクション