機能（機能）

1購読して公開する

メッセージ公開とは、プロデューサーがトピックにメッセージを送信することを意味します。メッセージサブスクリプションとは、消費者がトピック内の特定のタグを持つメッセージに注意を払い、そのトピックからのデータを消費することを意味します。

2メッセージシーケンス

メッセージの順序とは、あるタイプのメッセージが消費されるときに、送信された順序でメッセージを消費できることを意味します。例：注文は、注文の作成、注文の支払い、注文の完了の3つのメッセージを生成します。消費するときにこの順序で消費することは意味がありますが、同時に、注文を並行して消費することもできます。RocketMQは、メッセージの順序を厳密に保証できます。

シーケンスメッセージは、グローバルシーケンスメッセージとパーティションシーケンスメッセージに分けられます。グローバルシーケンスとは、特定のトピックに基づくすべてのメッセージをシーケンスする必要があることを意味します。部分シーケンスメッセージは、メッセージの各グループが順番に消費されるようにする必要があるだけです。

グローバル順序指定されたトピックについて、すべてのメッセージは厳密なファーストインファーストアウト（FIFO）の順序で公開および消費されます。該当するシナリオ：パフォーマンス要件は高くなく、すべてのメッセージはFIFOの原則に厳密に従って公開および消費されます。
パーティションの順序指定されたトピックでは、すべてのメッセージがシャーディングキーに従ってパーティション化されます。同じパーティション内のメッセージは、厳密なFIFO順序で公開および消費されます。シャーディングキーは、シーケンシャルメッセージの異なるパーティションを区別するために使用されるキーフィールドであり、通常のメッセージのキーとはまったく異なる概念です。該当するシナリオ：高性能要件、パーティションフィールドとしてシャーディングキーを使用し、メッセージの公開と消費について同じブロック内のFIFOの原則に厳密に従います。

3メッセージフィルタリング

RocketMQコンシューマーは、タグに基づいてメッセージをフィルタリングでき、カスタム属性フィルタリングもサポートします。メッセージフィルタリングは現在ブローカー側で実装されています。利点は、コンシューマーへの不要なメッセージのネットワーク送信を減らすことです。欠点は、ブローカーの負担が増え、実装が比較的複雑になることです。

4メッセージの信頼性

RocketMQは、メッセージの高い信頼性と、メッセージの信頼性に影響を与えるいくつかの状況をサポートします。

ブローカーが異常終了しました
ブローカーの異常なクラッシュ
OSクラッシュ
マシンの電源が切れますが、電源はすぐに復旧できます
マシンの電源をオンにできません（cpu、マザーボード、メモリ、その他の主要機器が損傷している可能性があります）
ディスクデバイスが破損している

1）、2）、3）、4）4つの状況はすべて、すぐに回復できるハードウェアリソースです。RocketMQは、これらの4つの状況でメッセージが失われたり、少量のデータが失われたりしないようにすることができます（フラッシュ方法が同期か非同期かによって異なります）。。

5）、6）単一の障害点であり、回復することはできません。一度発生すると、この単一の点のすべてのメッセージが失われます。これらの2つのケースでは、RocketMQは、非同期レプリケーションによってメッセージの99％が失われないことを保証できますが、失われる可能性のあるメッセージはごくわずかです。同期デュアルライトテクノロジーにより、シングルポイントを完全に回避できます。同期デュアルライトはパフォーマンスに影響を与えるため、金銭関連のアプリケーションなど、非常に高いメッセージの信頼性が必要な場合に適しています。注：RocketMQは、バージョン3.0以降の同期二重書き込みをサポートしています。

5少なくとも1回

少なくとも1回は、各メッセージを1回配信する必要があることを意味します。コンシューマーは最初にメッセージをローカルにプルし、消費が完了した後にackをサーバーに返します。消費がない場合はackメッセージがないため、RocketMQはこの機能を十分にサポートできます。

6遡及消費

遡及消費とは、消費者が正常に消費したメッセージを指します。ビジネスニーズのため、再消費する必要があります。この機能をサポートするには、成功したメッセージが消費者に配信された後も、ブローカーはメッセージを保持する必要があります。また、再消費は通常、時間ディメンションに基づいています。たとえば、コンシューマシステムの障害のため、データはリカバリ後1時間前に再消費する必要があり、ブローカーは時間ディメンションで消費の進行状況をロールバックするメカニズムを提供する必要があります。RocketMQは、時間の遡及に従って消費をサポートし、時間ディメンションはミリ秒単位で正確です。

7トランザクションメッセージ

RocketMQトランザクションメッセージ（トランザクションメッセージ）は、ローカルトランザクションのアプリケーションを指し、メッセージ送信操作は、グローバルトランザクションで定義でき、同時に成功または失敗します。RocketMQのトランザクションメッセージは、X / Open XAと同様の分散トランザクション機能を提供し、分散トランザクションの最終的な一貫性は、トランザクションメッセージを通じて実現できます。

8時限メッセージ

時限メッセージ（遅延キュー）は、メッセージがブローカーに送信された後、すぐには消費されず、特定の時間が実際のトピックに配信されるのを待つことを意味します。ブローカーには構成アイテムmessageDelayLevelがあり、デフォルト値は「1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h」、18レベルです。カスタムmessageDelayLevelを構成できます。messageDelayLevelはブローカーの属性であり、トピックに属していないことに注意してください。メッセージを送信するときは、delayLevelレベルを設定するだけです：msg.setDelayLevel（level）。レベルには次の3つの状況があります。

level == 0、メッセージは遅延しません
1 <= level <= maxLevel、メッセージは特定の時間遅延します。たとえば、level == 1、遅延は1秒です。
level> maxLevel、次にlevel == maxLevel、たとえば、level == 20、delay 2h

時限メッセージは、SCHEDULE_TOPIC_XXXXという名前のトピックに一時的に保存され、delayTimeLevel、queueId = delayTimeLevel – 1に従って特定のキューに保存されます。つまり、キューは同じ遅延のメッセージのみを保存し、同じ送信遅延のメッセージを順番に消費できるようにします。ブローカーはスケジュールに基づいてSCHEDULE_TOPIC_XXXXを消費し、実際のトピックにメッセージを書き込みます。

タイミングメッセージは、最初に書き込まれるときと実際のトピックに書き込まれるようにスケジュールされているときの両方でカウントされるため、送信とtpsの数が増えることに注意してください。

9メッセージの再試行

コンシューマーがメッセージの消費に失敗した後、メッセージを再度消費させるために再試行メカニズムを提供する必要があります。消費者がメッセージを消費できないことは、一般的に次の状況と見なすことができます。

逆シリアル化の失敗など、メッセージ自体が原因で、メッセージデータ自体を処理できません（たとえば、電話料金が再請求され、現在のメッセージの携帯電話番号がキャンセルされ、再充電ができません）。この種のエラーは通常、このメッセージをスキップしてから他のメッセージを消費する必要があります。この失敗したメッセージをすぐに再試行しても、99％は成功しません。したがって、タイミング再試行メカニズム、つまり10秒後を提供するのが最善です。再試行。
たとえば、依存するダウンストリームアプリケーションサービスが利用できないため、db接続が利用できず、外部システムネットワークにアクセスできません。この種のエラーが発生した場合、現在の失敗したメッセージがスキップされたとしても、他のメッセージの消費もエラーを報告します。この場合、次のメッセージを消費する前に30秒間スリープを適用することをお勧めします。これにより、ブローカーがメッセージを再試行する圧力を軽減できます。

RocketMQは、消費者グループごとにトピック名「％RETRY％+ ConsumerGroup」で再試行キューを設定します（このトピックの再試行キューは、トピックごとではなく、消費者グループ用であることに注意してください。）、さまざまな例外のためにコンシューマー側で消費できないメッセージを一時的に保存するために使用されます。例外からの回復には時間がかかることを考慮し、再試行キューには複数の再試行レベルが設定されます。各再試行レベルには対応する再配信遅延があります。再試行回数が多いほど、配信遅延は大きくなります。RocketMQの再試行メッセージの処理は、最初にトピック名「SCHEDULE_TOPIC_XXXX」で遅延キューに保存され、バックグラウンドタイミングタスクは対応する時間に従って遅延されてから、「％RETRY％+ consumerGroup」の再試行キューに保存されます。

10メッセージの再投稿

プロデューサーがメッセージを送信するときに、失敗した場合は同期メッセージが再送信されます。非同期メッセージが再試行されます。Onewayには保証がありません。メッセージの再キャストにより、メッセージが失われることなく可能な限り正常に送信されますが、メッセージの重複が発生する可能性があります。これは、RocketMQでは避けられない問題です。通常の状況では、メッセージの繰り返しは発生しません。大量のメッセージとネットワークジッタがある場合、メッセージの繰り返しは高確率のイベントになります。さらに、プロデューサーによるプロアクティブな再送信とコンシューマーの負荷の変化も、メッセージの重複を引き起こす可能性があります。次の方法で、メッセージの再試行戦略を設定できます。

restartTimesWhenSendFailed：同期送信が失敗したときの再試行回数。デフォルトは2であるため、プロデューサーは最大1回retryTimesWhenSendFailedを送信しようとします。前回失敗したブローカーを選択せず、他のブローカーに送信して、メッセージが最大限に失われないようにします。再投稿の数を超えると、例外がスローされ、クライアントはメッセージが失われないようにします。RemotingException、MQClientException、および一部のMQBrokerExceptionが発生すると、それらは再キャストされます。
restartTimesWhenSendAsyncFailed：非同期送信失敗の再試行回数。非同期再試行は他のブローカーを選択せず、同じブローカーでのみ再試行します。メッセージが失われないという保証はありません。
tryAnotherBrokerWhenNotStoreOK：メッセージの点滅（プライマリまたはスタンバイ）がタイムアウトしたか、スレーブが使用できません（戻りステータスがSEND_OKではありません）。他のブローカーに送信しようとするかどうか、デフォルトはfalseです。非常に重要なニュースを開くことができます。

11フロー制御

ブローカーの処理能力がボトルネックに達するためのプロデューサーフロー制御、消費能力がボトルネックに達するためのコンシューマーフロー制御。

プロデューサーフロー制御：

commitLogファイルがosPageCacheBusyTimeOutMillsより長くロックされている場合、パラメーターのデフォルトは1000msであり、フロー制御が返されます。
transientStorePoolEnable == trueが有効で、ブローカーが非同期フラッシュディスクのホストであり、transientStorePoolのリソースが不十分な場合、現在の送信要求は拒否され、フロー制御が返されます。
ブローカーは、送信要求キューのヘッド要求の待機時間を10ミリ秒ごとにチェックします。waitTimeMillsInSendQueueを超えると、デフォルトは200ミリ秒になり、現在の送信要求は拒否され、フロー制御が返されます。
ブローカーは、送信要求を拒否することによってフロー制御を実装します。

プロデューサーフローコントロールはメッセージの再送信を試みないことに注意してください。

消費者の流れの制御：

コンシューマーによってローカルにキャッシュされるメッセージの数がpullThresholdForQueueを超える場合、デフォルトは1000です。
コンシューマーローカルキャッシュメッセージのサイズがpullThresholdSizeForQueueを超える場合、デフォルトは100MBです。
コンシューマーローカルキャッシュメッセージスパンがconsumeConcurrentlyMaxSpanを超える場合、デフォルトは2000です。

消費者のフロー制御の結果は、プルの頻度を減らすことです。

12デッドレターキュー

デッドレターキューは、通常は消費できないメッセージを処理するために使用されます。メッセージが初めて消費されなかった場合、メッセージキューは自動的にメッセージを再試行します。最大再試行回数に達した後も消費が失敗した場合、通常の状況ではコンシューマーがメッセージを正しく消費できないことを意味します。現時点では、メッセージキューはメッセージを消費しません。メッセージはすぐに破棄しますが、コンシューマーに対応する特別なキューに送信します。

RocketMQは、通常の状況では消費できないメッセージをDead-Letterメッセージと呼び、デッドレターメッセージを格納する特別なキューをDead-Letterキューと呼びます。RocketMQでは、コンソールを使用してデッドレターキュー内のメッセージを再送信し、コンシューマーインスタンスを再び消費させることができます。

13元のリンク

注释：来源于GitHub
https://github.com/apache/rocketmq/blob/master/docs/cn/README.md

RocketMQ（2）の機能