ベストプラクティス
1人のプロデューサー
メッセージノート1.1を送信
1タグの使用
可能なアプリケーションとAトピック、メッセージのサブタイプは、タグを用いて同定することができます。message.setTags（「多賀」）：タグは、メッセージフィルタを行う消費者がタグを使用してメッセージ・ブローカを購読することができた場合にのみ、アプリケーション、タグを設定するメッセージを送信するための唯一のプロデューサーによって自由に設定することができます。
使用する2つのキー
固有の識別コードがキー・フィールドの動作レベルに設定される各メッセージは、将来位置情報損失の問題を容易にします。サーバは、誰によって各メッセージのインデックス（ハッシュインデックス）、トピックごとのアプリケーション、このニュースの内容を照会するキー、およびニュースの消費量を作成します。それはハッシュインデックスであるため、可能な限り唯一のキーがハッシュの潜在的な競合を避けるためにことを確認してください。
// 订单Id
String orderId = "20034568923546";
message.setKeys(orderId);
3ログを印刷
メッセージが正常に送信またはSendResultとキーフィールドを印刷してください、メッセージログを印刷することができませんでした。長いメソッドが例外をスローしないようとしてメッセージを送信し、代わって正常に送信。sendResult年に定義された複数の状態を、持って成功を送信します。以下、各状態について記載されています。
- SEND_OK
メッセージが正常に送信しました。メッセージが正常に送信されることに注意してください、それが信頼性があることを意味するものではありません。何もメッセージが失われないことを保証するために、あなたはまた、同期マスタサーバまたは同期ブラシプレート、すなわちSYNC_MASTERまたはSYNC_FLUSHを有効にする必要があります。
- FLUSH_DISK_TIMEOUT
しかし、成功メッセージサーバタイムアウトブラシディスク。メッセージは、サーバーのキュー（メモリ）を入力しただけでサーバーがダウンしている、メッセージが失われます。構成パラメータを格納するメッセージは、設定ブラシディスクモードと時間の範囲の同期ブラシ長、同期ブラシ板用ブローカサーバのセットブラシディスク、すなわちFlushDiskType = SYNC_FLUSH（デフォルト非同期ブラシプレートモード）、ブローカサーバが同期していない場合は、ブラシであることができます時間はディスク（デフォルト5秒）ブラシプレートが完了すると、ステータスが返されます - ブラシプレートのタイムアウトを。
- FLUSH_SLAVE_TIMEOUT
メッセージが正常に送信されますが、サーバのタイムアウトは、スレーブに同期させます。メッセージは、サーバーのキューに入っている唯一のサーバーがダウンしていると、メッセージが失われます。サーバーの役割をマスターブローカ、すなわちSYNC_MASTER（すなわちデフォルトの非同期マスターASYNC_MASTER）、ブローカー同期され、サーバからではなく、時間のプライマリサーバと完全に同期する同期ブラシディスク（デフォルト5秒）、それはステータスが返されている場合 - - サーバへのスレーブデータの同期がタイムアウトしました。
- SLAVE_NOT_AVAILABLE
メッセージが正常に送信されますが、この時、スレーブは使用できません。役割は、マスターブローカサーバ、すなわちSYNC_MASTER（デフォルトはASYNC_MASTERある非同期マスターサーバーです）同期されますが、スレーブブローカーサーバーに設定されていない場合、この状態が返されます - いいえ、スレーブサーバが利用可能です。
メッセージ送信失敗処理モード1.2
次のようにsendメソッドの再試行内部のプロデューサーのサポート自体は、再試行ロジックは次のとおりです。
- 図2は、複数回テストする（2回同期送信のために、非同期伝送が0回です）。
- 送信が失敗した場合、次の回転ブローカー。この方法は、時間の合計がsendMsgTimeoutセットのデフォルトの10秒の値を超えていないがかかります。
- ブローカーは自分自身にメッセージを送信した場合、タイムアウト例外は、再試行しません。
上記の戦略は、メッセージが正常に送信できることを保証するために、ある程度もあります。メッセージトラフィックが比較的高い場合、信頼性、提案されたアプリケーションの再試行ロジックにおける対応する増加：送信同期メソッド呼び出しが失敗した場合、メッセージがDBの試み、再試行タイマバックグラウンドスレッドに格納されているような、メッセージブローカに到達することを保証しなければなりません。
行うために内部MQクライアントに統合されますが、完全に独自のアプリケーションを必要とし、以下の考慮事項に基づいていないのはなぜDbが、上記のように再試行：まず、ステートレスモードに設計されたMQクライアント、便利な任意の水平展開、およびにマシンのリソースは、CPU、メモリ、ネットワークを消費していました。第二に、唯一のより信頼性の高い同期の内部MQクライアント統合のKVストレージモジュール、ディスクからのデータならば、しかし、ディスク自体オフ同期性能は、オーバーヘッド大、通常は非同期の発注であり、アプリケーション・プロセスは、MQトランスポートを閉じていないので、制御および保守担当者は、多くの場合、このようキルを発生する可能性があり-9暴力は発注には時間を失っていないデータが得られ、シャットダウン。第三に、プロデューサー、通常、仮想マシンは、重要なデータを格納するのに適していないマシンの信頼性が低いです。要約すると、提案されたアプリケーションは、再試行プロセス制御と呼ばれます。
1.3一方向選択された送信形式
メッセージは、典型的には、プロセスに送信されます。
- クライアントがサーバに要求を送信します
- サーバーは要求を処理し
- サーバーは、クライアントに応答を返します
したがって、メッセージ送信時間がかかり、非常に短いかかる請求項に3以上の工程、及びいくつかのシーンの和であるが、信頼性が高くないが、例えば、コレクション型アプリケーションログ、そのようなアプリケーションは、コールの形をとることができる一方向、応答を待たずにのみ送信要求を形成し、クライアントオペレーティングシステムのレベルを達成するための要求を送信する一方向のシステムコールのコストだけで、書き込みデータへのクライアントソケットバッファにについて、このプロセスはマイクロ秒で、通常かかります。
2消費者
2.1消費プロセスの冪等
RocketMQリピートビジネスは、消費者に非常に敏感であるのであれば、メッセージを（正確にワンス）繰り返しを避けることができない、運用レベルでの重複排除処理を実行することを確認してください。重複除外は、リレーショナルデータベースを用いて行うことができます。ユニークキーメッセージを決定するための最初の必要性は、MSGIDはまた、のような注文IDとして、メッセージの内容にのみ識別フィールドとすることができるかもしれません。唯一の鍵は、消費前の判断にリレーショナルデータベース内に存在しています。何の挿入、および消費がない場合は、そうでない場合はスキップします。（実際のプロセスは、主キー違反メッセージ場合、挿入は失敗し、スキップ、そこに挿入されているかどうかを判断しようとする場合があり、問題の原子を検討します）
MSGIDは、（重複を引き起こすメカニズムが再結合クライアントためなど、消費者主導の再送信）の二つの異なるMSGIDを持っている。このような状況のニーズグローバル一意識別子であってもよいが、実際の使用、同じメッセージの場合もあり得る必要があります事業分野は、消費を繰り返しました。
2.2消費遅いアプローチ
1増加消費の並列処理
メッセージのほとんどは、データベース操作とすることができるすべてのIO集中消費行動、またはRPC呼び出し、特定の消費者の行動または並列の消費を増加させることにより、外側バックエンド・データベース・システムが、全体を増加させることができるような消費率であります消費者は、スループットが、ある程度の並列度が、分類されます。したがって、アプリケーションは、並列処理の合理的な程度を設定する必要があります。次のように消費並列性を修正するには、いくつかの方法があります。
- （サブスクリプションが無効なキューのコンシューマインスタンスの数を超えていること注）1 ConsumerGroupの下では、並列度を上げることにより、インスタンスの消費者の数を増やすことができます。機械、または既存のマシンで複数のプロセスを開始するための方法を追加することにより。
- 個人消費の増加、個々の並列スレッドは、パラメータconsumeThreadMinを変更することで、consumeThreadMaxを達成します。
2バッチモード消費
消費の特定のビジネスプロセスをサポートバッチモードは、そのような順序電荷型アプリケーションとして大きく消費のスループットを向上させることができる場合は、時間のかかるプロセス順序1S、処理10件の受注回ことができる唯一の2秒を要し、そのような消費が大幅に消費者consumeMessageBatchMaxSizeリターンパラメータを提供することにより、スループットを向上させることができ、デフォルト、すなわちのみメッセージコンシューマ一旦、1であり、Nに例えばセットについて、消費あたりのメッセージの数はNに等しい未満であります
3非クリティカルなメッセージはスキップされます
消費者はより少ないビジネスデータを要求した場合、あなたは重要でないメッセージを破棄するかを選択することができ、伝送速度の速さに追いつくために持っている場合は、メッセージの蓄積が、発生します。メッセージ・キューの数が100,000上に堆積されたときに、すぐにメッセージを送信するのスピードに追いつくことができますので、例えば、その試みは、メッセージの一部またはすべてを廃棄します。次のようにサンプルコードは次のとおりです。
public ConsumeConcurrentlyStatus consumeMessage(
List<MessageExt> msgs,
ConsumeConcurrentlyContext context) {
long offset = msgs.get(0).getQueueOffset();
String maxOffset =
msgs.get(0).getProperty(Message.PROPERTY_MAX_OFFSET);
long diff = Long.parseLong(maxOffset) - offset;
if (diff > 100000) {
// TODO 消息堆积情况的特殊处理
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
// TODO 正常消费过程
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
4つの最適化プロセスの各メッセージコンシューマ
一例として、以下のように、メッセージの消費のプロセスを次のように
- DB [1]からのメッセージデータ
- DB [2]からのメッセージデータ
- 複雑なビジネス・コンピューティング
- データを挿入するDB [3]
- [4]データDBを挿入します
各5msのに従って計算した場合、このメッセージは、DB 4倍と対話するために持っている消費プロセスは、その後、計算はビジネス5msのを想定して消費し、20msの合計を取り、その後、合計時間がかかりすぎる、我々はDBと対話することができそうだとすれば、25msの4倍です2回最適化、次いで合計時間は、40％改善され、全体的なパフォーマンスである、15msのに最適化することができます。遅延に敏感なアプリケーションならば、それはSCSIディスクに比べて、DB SSDハードディスクに展開することができるので、旧RTははるかに小さくなります。
2.3消費者の印刷ログ
量が少ないのニュースであれば、フォローアップのトラブルシューティングを容易にするため、消費者の入力方法、消費者やその他の時間のかかる中でメッセージを印刷することをお勧めします。
public ConsumeConcurrentlyStatus consumeMessage(
List<MessageExt> msgs,
ConsumeConcurrentlyContext context) {
log.info("RECEIVE_MSG_BEGIN: " + msgs.toString());
// TODO 正常消费过程
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
あなたは、各メッセージコンシューマ時間がかかるので、オンライン時の問題のトラブルシューティングと遅い消費を印刷できる場合は、それがより便利になります。
2.4その他の消費勧告
消費者およびサブスクリプションの1
ノートへの最初のものは、異なる消費者団体は、独立して、いくつかのトピックの消費量、および各グループの支出独自の消費者が同じグループのサブスクリプション内の各消費者は情報が残っていることを確認し、オフセットしていることができています一貫性のあります。
注文したメッセージについて2
消費者は、これはパフォーマンスの低下になりますが、彼らは個別に消費していることを確認するために、各メッセージキューをロックしますが、メッセージ・シーケンスを気にする際に有用であろう。私たちは、あなたの代わりにConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENTを返すことができ、例外をスローすることはお勧めしません。
3同時消費について
名前が示すように、消費者はこれらのメッセージの同時消費になります、あなたが良好なパフォーマンスを得るためにそれを使用することを、我々は例外をスローすることはお勧めしません、あなたが代わりにConsumeConcurrentlyStatus.RECONSUME_LATERを返すことができるお勧めします。
消費状態の4には、ステータスを消費します
同時消費リスナーのために、あなたはこのニュースと希望を消費することができない今、消費者に知らせるためにRECONSUME_LATERを返すことができ、後でそれを再摂取。その後、あなたは他のメッセージを消費し続けることができます。あなたはその順番を気にするので、あなたがメッセージをスキップすることはできませんが、SUSPEND_CURRENT_QUEUE_A_MOMENTのtell消費者が瞬間を待って返すことができるようにするために、メッセージ・リスナーを命じました。
ブロッキングについて5
それは、スレッドプールをブロックしますので、私は、リスナーをブロックすることはおすすめしません、そして最終的に消費者は、プロセスを終了させることができます
スレッドの6数について
メッセージの内部にThreadPoolExecutor消費者の消費量は、あなたがsetConsumeThreadMinやsetConsumeThreadMaxを設定することで、それを変更することができます。
消費者のサイト上で7
新しいコンシューマ・グループを作成するときは、メッセージが既にメッセージ履歴を無視するCONSUME_FROM_LAST_OFFSETブローカーの歴史の中で存在して消費し、後に生成されたすべてのメッセージを消費するかどうかを決定する必要があります。CONSUME_FROM_FIRST_OFFSET消費者情報は、ブローカの各々に存在するであろう。また、生成された指定されたタイムスタンプの後にメッセージを消費するためにCONSUME_FROM_TIMESTAMPを使用することができます。
3ブローカー
3.1ブローカーの役割
ASYNC_MASTER（非同期ホスト）、SYNC_MASTER（同期マスタ）とスレーブ（スレーブ）にブローカーの役割。メッセージの信頼性要件がより厳しい場合は、展開の使用SYNC_MASTERプラスSLAVEすることができます。以下のメッセージの信頼性を要求した場合、展開のASYNC_MASTER追加SLAVEを使用することができます。便利なだけテストした場合、あなただけのASYNC_MASTERのみSYNC_MASTERの展開を選択することができます。
3.2 FlushDiskType
SYNC_FLUSH（同期リフレッシュ）ASYNC_FLUSH（非同期処理）と比較して、パフォーマンスの多くを失うだけでなく、より信頼性の高いだろうが、実際のビジネスシナリオに基づいたトレードオフを行う必要があります。
3.3ブローカーの設定
| パラメータ名 | デフォルト値 | 説明 |
|---|---|---|
| listenPortの | 10911 | クライアント接続を受け入れるためにポートを聞きます |
| Nmesrwaddra | ヌル | ネームサーバのアドレス |
| brokerIP1 | InetAddressのカード | 現在のブローカー・リスニングIP |
| brokerIP2 | 同様brokerIP1 | マスタからブローカが存在する場合に、プライマリノード上の構成ブローカbrokerIP2プロパティ場合、マスターノードから接続ブローカーノードがbrokerIP2を同期させるように構成します |
| brokerNameに | ヌル | ブローカーの名前 |
| brokerClusterName | DefaultCluster | ブローカーのCluser名が所属します |
| brokerId | 0 | ブローカーID、0はマスターを表し、他の正の整数スレーブ |
| storePathCommitLog | $ HOME /店舗/ commitlog / | ログ保存パスをコミット |
| storePathConsumerQueue | $ HOME /店舗/ consumequeue / | ストレージは、キューのパスを消費します |
| mappedFileSizeCommitLog | * 1024 1024×1024（1G） | ログマッピングファイルのサイズをコミット |
| deleteWhen | 04 | 削除したファイルは、その日の何時にコミットログの保持時間を超えました |
| fileReservedTime | 72 | 文書保持時間の時間で |
| brokerRole | ASYNC_MASTER | SYNC_MASTER / ASYNC_MASTER / SLAVE |
| flushDiskType | ASYNC_FLUSH | メッセージプロデューサブラシディスクを確実にするために、応答モードを受信する前にSYNC_FLUSH / ASYNC_FLUSH SYNC_FLUSH下ブローカー。ブラシディスク・メッセージ・パターンを使用して、モードセット内ASYNC_FLUSHブローカは、より良い性能を達成することができます。 |
4ネームサーバ
RocketMQ、中にネームサーバは、単純なルーティング管理のために設計されています。その責任は、次のとおりです。
- 各ネームサーバ登録ルートにブローカー通常のデータ。
- 最新のルーティング情報を提供するために、生産者、消費者、コマンドラインクライアントを含むクライアントのためのネームサーバ、。
5クライアントの設定
ブローカクラスタに対するRocketMQ、生産者と消費者がクライアントです。このセクションでは、公開設定の生産者と消費者の行動を説明します。
アドレッシング5.1クライアント
RocketMQは、クライアントがネームサーバーを見つけ行い、その後、ネームサーバーによってブローカーを見つけることができます。低優先度の高いから、以下に示すように様々な構成があり、高優先度のオーバーライドは優先度を下げます。
- ネームサーバのアドレスは複数のアドレス間で分割セミコロンによってコードで指定namesrv
producer.setNamesrvAddr("192.168.0.1:9876;192.168.0.2:9876");
consumer.setNamesrvAddr("192.168.0.1:9876;192.168.0.2:9876");
- ネームサーバアドレスで指定されたJavaの起動パラメータ
-Drocketmq.namesrv.addr=192.168.0.1:9876;192.168.0.2:9876
- アドレスを指定するネームサーバの環境変数
export NAMESRV_ADDR=192.168.0.1:9876;192.168.0.2:9876
- 静的アドレス指定のHTTPサーバ（デフォルト）
クライアントが開始した後、あなたが定期的に以下のアドレスに静的なHTTPサーバを訪問する：http://jmenv.tbsite.net:8080/rocketmq/nsaddr次のように、このURLを返します。
192.168.0.1:9876;192.168.0.2:9876
2分ごとに一度クライアントのデフォルトのHTTPサーバにアクセスし、ローカルのネームサーバのアドレスを更新します。URLは、サーバにアクセスするために、コード内にハードコーディングされている/ etc / hostsに、例えば、変更されてもよい/ etc / hostsファイルを変更することによって増加次の
10.232.22.67 jmenv.taobao.net
HTTPサーバがアドレス指定を使用し、静的に推奨され、利点は、単純なクライアントの展開であり、ネームサーバのクラスタのアップグレードが高温になることがあります。
5.2クライアントの構成
DefaultMQProducer、TransactionMQProducer、DefaultMQPushConsumer、DefaultMQPullConsumerはClientConfig一般的な構成は、クライアントクラスのために、ClientConfigクラスから継承されます。設定クライアントは、他のパラメータ、producer.setNamesrvAddr（「192.168.0.1:9876」）、このパラメータを設定することができ、例えばnamesrvAddr、GET、各パラメータはスプリングで構成することができる集合形態は、コードに配置することができるされています共感。
1つのクライアントの一般的な構成
| パラメータ名 | デフォルト値 | 説明 |
|---|---|---|
| Nmesrwaddra | ネームサーバのアドレスリストは、複数のアドレスはセミコロンで区切られたネームサーバ | |
| クライアントIP | ローカルIP | いくつかのマシンが発生する可能性があり、クライアントのIPアドレスは、コードを強制するために、アプリケーションのニーズをクライアントのIPアドレスを認識しません |
| instanceNameの | デフォルト | クライアント名の例として、クライアントは、消費者が実際に共通の内部インスタンス（この例では、ネットワーク接続、スレッドリソース、等を含む）、複数のプロデューサを作成 |
| clientCallbackExecutorThreads | 4 | スレッドの通信層の非同期コールバックナンバー |
| pollNameServerInteval | 30000 | ネームサーバーのポーリング間隔（ミリ秒） |
| heartbeatBrokerInterval | 30000 | ミリ秒単位で、Brokerにハートビートを送信 |
| persistConsumerOffsetInterval | 5000 | ミリ秒単位で永続消費者消費スケジュール間隔時間、 |
2プロデューサー設定
| パラメータ名 | デフォルト値 | 説明 |
|---|---|---|
| producerGroup | DEFAULT_PRODUCER | プロデューサーのグループ名を、より多くのプロデューサーアプリケーションの一部であれば、同じメッセージを送信し、その後、彼らは同じグループに分類されなければなりません |
| createTopicKey | TBW102 | メッセージを送信すると、サーバーが自動的にトピックを作成し、ここで、メッセージの話題デフォルトルートを送信するために使用することができるキー、キーを指定する必要が存在しません。 |
| defaultTopicQueueNums | 4 | メッセージを送信すると、サーバーは自動的に、トピックが存在しません作成されたキューのデフォルト数を作成し、 |
| sendMsgTimeout | 10000 | ミリ秒単位でのメッセージのタイムアウトを送信 |
| compressMsgBodyOverHowmuch | 4096 | メッセージ本文はバイト単位で、（消費者がメッセージを受信、自動的に解凍されます）はるかに超える圧縮を開始します |
| retryAnotherBrokerWhenNotStoreOK | FALSE | リターン・メッセージが送信を再試行するかどうか、sendResultを送ったが、sendStatus！= SEND_OKされた場合 |
| retryTimesWhenSendFailed | 2 | メッセージが失敗した場合は、再試行の最大数は、パラメータは、同期転送モードで作用します |
| maxMessageSize | 4NB | エラーを超えるクライアントのメッセージサイズの制限、およびサーバは、サービスの最終用途に協力する必要がある、制限されます。 |
| transactionCheckListener | トランザクションメッセージを送信した場合、トランザクションメッセージリスナをバックチェックし、あなたが設定する必要があります | |
| checkThreadPoolMinSize | 1 | プロデューサーブローカーチェックバック時に事務の状態、スレッドプールのスレッドの最小数 |
| checkThreadPoolMaxSize | 1 | プロデューサーブローカーチェックバック時に事務の状態、スレッドのスレッドプールの最大数 |
| checkRequestHoldMax | 2000 | Broker回查Producer事务状态时，Producer本地缓冲请求队列大小 |
| RPCHook | null | 该参数是在Producer创建时传入的，包含消息发送前的预处理和消息响应后的处理两个接口，用户可以在第一个接口中做一些安全控制或者其他操作。 |
3 PushConsumer配置
| 参数名 | 默认值 | 说明 |
|---|---|---|
| consumerGroup | DEFAULT_CONSUMER | Consumer组名，多个Consumer如果属于一个应用，订阅同样的消息，且消费逻辑一致，则应该将它们归为同一组 |
| messageModel | CLUSTERING | 消费模型支持集群消费和广播消费两种 |
| consumeFromWhere | CONSUME_FROM_LAST_OFFSET | Consumer启动后，默认从上次消费的位置开始消费，这包含两种情况：一种是上次消费的位置未过期，则消费从上次中止的位置进行；一种是上次消费位置已经过期，则从当前队列第一条消息开始消费 |
| consumeTimestamp | 半个小时前 | 只有当consumeFromWhere值为CONSUME_FROM_TIMESTAMP时才起作用。 |
| allocateMessageQueueStrategy | AllocateMessageQueueAveragely | Rebalance算法实现策略 |
| subscription | 订阅关系 | |
| messageListener | 消息监听器 | |
| offsetStore | 消费进度存储 | |
| consumeThreadMin | 10 | 消费线程池最小线程数 |
| consumeThreadMax | 20 | 消费线程池最大线程数 |
| consumeConcurrentlyMaxSpan | 2000 | 单队列并行消费允许的最大跨度 |
| pullThresholdForQueue | 1000 | 拉消息本地队列缓存消息最大数 |
| pullInterval | 0 | 拉消息间隔，由于是长轮询，所以为0，但是如果应用为了流控，也可以设置大于0的值，单位毫秒 |
| consumeMessageBatchMaxSize | 1 | 批量消费，一次消费多少条消息 |
| pullBatchSize | 32 | 批量拉消息，一次最多拉多少条 |
4 PullConsumer配置
| 参数名 | 默认值 | 说明 |
|---|---|---|
| consumerGroup | DEFAULT_CONSUMER | Consumer组名，多个Consumer如果属于一个应用，订阅同样的消息，且消费逻辑一致，则应该将它们归为同一组 |
| brokerSuspendMaxTimeMillis | 20000 | 长轮询，Consumer拉消息请求在Broker挂起最长时间，单位毫秒 |
| consumerTimeoutMillisWhenSuspend | 30000 | 长轮询，Consumer拉消息请求在Broker挂起超过指定时间，客户端认为超时，单位毫秒 |
| consumerPullTimeoutMillis | 10000 | 非长轮询，拉消息超时时间，单位毫秒 |
| messageModel | BROADCASTING | 消息支持两种模式：集群消费和广播消费 |
| messageQueueListener | 监听队列变化 | |
| offsetStore | 消费进度存储 | |
| registerTopics | 注册的topic集合 | |
| allocateMessageQueueStrategy | AllocateMessageQueueAveragely | Rebalance算法实现策略 |
5 Message数据结构
| 字段名 | 默认值 | 说明 |
|---|---|---|
| Topic | null | 必填，消息所属topic的名称 |
| Body | null | 必填，消息体 |
| Tags | null | 选填，消息标签，方便服务器过滤使用。目前只支持每个消息设置一个tag |
| Keys | null | 选填，代表这条消息的业务关键词，服务器会根据keys创建哈希索引，设置后，可以在Console系统根据Topic、Keys来查询消息，由于是哈希索引，请尽可能保证key唯一，例如订单号，商品Id等。 |
| Flag | 0 | 选填，完全由应用来设置，RocketMQ不做干预 |
| DelayTimeLevel | 0 | 选填，消息延时级别，0表示不延时，大于0会延时特定的时间才会被消费 |
| WaitStoreMsgOK | TRUE | 选填，表示消息是否在服务器落盘后才返回应答。 |
6 系统配置
本小节主要介绍系统（JVM/OS）相关的配置。
6.1 JVM选项
推荐使用最新发布的JDK 1.8版本。通过设置相同的Xms和Xmx值来防止JVM调整堆大小以获得更好的性能。简单的JVM配置如下所示：
-server -Xms8g -Xmx8g -Xmn4g
如果您不关心RocketMQ Broker的启动时间，还有一种更好的选择，就是通过“预触摸”Java堆以确保在JVM初始化期间每个页面都将被分配。那些不关心启动时间的人可以启用它： -XX:+AlwaysPreTouch
禁用偏置锁定可能会减少JVM暂停， -XX:-UseBiasedLocking
至于垃圾回收，建议使用带JDK 1.8的G1收集器。
-XX:+UseG1GC -XX:G1HeapRegionSize=16m
-XX:G1ReservePercent=25
-XX:InitiatingHeapOccupancyPercent=30
这些GC选项看起来有点激进，但事实证明它在我们的生产环境中具有良好的性能。另外不要把-XX:MaxGCPauseMillis的值设置太小，否则JVM将使用一个小的年轻代来实现这个目标，这将导致非常频繁的minor GC，所以建议使用rolling GC日志文件：
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=30m
如果写入GC文件会增加代理的延迟，可以考虑将GC日志文件重定向到内存文件系统：
-Xloggc:/dev/shm/mq_gc_%p.log123
6.2 Linux内核参数
os.sh脚本在bin文件夹中列出了许多内核参数，可以进行微小的更改然后用于生产用途。下面的参数需要注意，更多细节请参考/proc/sys/vm/*的文档
- vm.extra_free_kbytes，告诉VM在后台回收（kswapd）启动的阈值与直接回收（通过分配进程）的阈值之间保留额外的可用内存。RocketMQ使用此参数来避免内存分配中的长延迟。（与具体内核版本相关）
- vm.min_free_kbytes，如果将其设置为低于1024KB，将会巧妙的将系统破坏，并且系统在高负载下容易出现死锁。
- vm.max_map_count，限制一个进程可能具有的最大内存映射区域数。RocketMQ将使用mmap加载CommitLog和ConsumeQueue，因此建议将为此参数设置较大的值。（agressiveness --> aggressiveness）
- vm.swappiness，定义内核交换内存页面的积极程度。较高的值会增加攻击性，较低的值会减少交换量。建议将值设置为10来避免交换延迟。
- File descriptor limits，RocketMQ需要为文件（CommitLog和ConsumeQueue）和网络连接打开文件描述符。我们建议设置文件描述符的值为655350。
- Disk scheduler，RocketMQ建议使用I/O截止时间调度器，它试图为请求提供有保证的延迟。