メッセージキューのインタビューのトピック

支出の重複を回避する方法

RocketMQは、メッセージが繰り返されないことを保証するものではありません、あなたのビジネスは厳密に重複したメッセージである必要はありませんならば、あなたはビジネスの端に重いを移動する必要があります

インターフェイスの冪等の保護、冪等を維持するために、消費者側の処理ビジネスニュース

Redisの

1）setNX（）、重いを行うにはメッセージID、Javaのバージョンは、現在、有効期限の設定をサポートしていません。

// Redisの操作は、操作されたTODOか否かを判断する
ブールのフラグ= jedis.setNX（KEY）;
 IF （のフラグ）{
     // 消費 
} 他{
     // 無視し、繰り返し消費 
}

拡張（アトミックではないが再び期限切れ場合、次のようにロックを分散させることができます）

ロック
の文字列結果 = jedis.set（キー、値、「NX」、「PX」、expireTime）

ロック解除（Luaのスクリプトは、最初のキーを確認し、ロック試合を解除し、LUAは原子性を保証することができます）
文字列スクリプト =「IFのRedis。コール（[1] 'GET'、KEYS）== ARGV [1]は、その後返す（ '・デル'、KEYS [1]）は、他の戻り0 "終了redis.call ; 
オブジェクトの結果 = jedis.eval（スクリプト、Collections.singletonListを（lockKey）、Collections.singletonList（requestId） ）; 

注：lockKeyは商品IDとすることができる、requestIdは、同じクライアントを識別するために使用

2）INCRアトミック操作：キーインクリメント、戻り値は、次に、消費者を介して0より大きい

INT NUM = jedis.incr（KEY）;
 IF（NUM == 1 ）{
     / 消費
} 他{
     // 無視し、繰り返し消費 
}

両方の方法はなく、原子考え分散ロックの問題であることができるが、有効期限を設定する原子の重複の問題、データニーズを大量に考えなくてもよいです。

重複除外データベーステーブル

ユニーク索引キーのDOを使用してフィールド内のメッセージ

どのようにメッセージの信頼性を確保するために、メッセージが処理上の問題で失われます

プロデューサー端

再試行、再試行が、メッセージのキーは一意である必要がありますか、同期または非同期モードを送って、一方向送信を使用しないでください。
配信ログを保存する必要が、キーフィールド、納期、配送状況、再試行回数、身体への要求と応答します

ブローカーの終わり

複数のノードが必要とされているネームサーバをダブルダブルマスタスレーブアーキテクチャ、
同時デュアル書き込み、非同期ブラシディスク（同期ブラシディスクは、より信頼性の高いですが、パフォーマンスはほとんどあり、サービスの選択に応じて）

消費者端

ログメッセージ、そのメッセージのメタデータとメッセージボディを保つようにしてください消費者
消費者側の冪等のトリートメントを確認してください

ブローカー端末に配信した後、

マシンサイクルパワー：非同期ブラシプレートは、メッセージが失われ、同期メッセージは、ブラシディスクを失っていません
ハードウェア障害：が失われる可能性があり、キューのアーキテクチャを参照してください

メッセージは、ブローカーの内部に蓄積がたくさんある場合は、どのように対処します

回線障害、そしてどのように対処します

ニュースメッセージの数千万人を処理する、10時間を積み上げて、今どのように行うには？
修理消費者は、その後、ゆっくりと消費しますか？また、新しいメッセージが行う方法で、完全な消費に数時間を取ることができますか？

正しい姿勢

トピック一時キューの拡張、および消費者の能力を向上させていますが、消費者の数が、メッセージキュー内のトピックの固定数の蓄積を増やす場合は、あまりにも多くの消費者は、メッセージキューに割り当てることはできません
暫定操作ディスパッチャの準備、迅速回キューの数の新しいトピック展開に新しい暫定トピックトピックに古いから読み込まれ、その後、新しいトピックでは、一時的な消費でより多くの消費者を開始

高性能、高可用性アーキテクチャのRocketMQ原因分析

MQアーキテクチャの構成

シーケンシャル書き込み、ランダム読み取り、ゼロコピー
flushDiskTypeによって配置された同期および非同期SYNC_FLUSHブラシディスクブラシプレートASYNC_FLUSH、
同期および非同期レプリケーション、brokerRole設定ASYNC_MASTERによって、SYNC_MASTER、SLAVE
推奨同期レプリケーション（ダブル書き込み）、非同期ディスクブラシ

可用性送信端

デュアルデュアルマスタスレーブアーキテクチャ：トピックに対応する時間を作成し、メッセージキューは、複数のブローカーに作成しました
ブローカすなわち、同じ名前が異なるbrokerid（即ち、マスタ・スレーブモード）マスターは、他のグループマスタがまだ使用可能、使用不能です。
十分なマシン・リソースは、必要が手動でスレーブ・マスターに変身するときには、現在の自動変換、使用可能なシェルの処理をサポートしていません。

消費者の可用性

マスター・スレーブ・アーキテクチャ：ブローカーの役割、マスターは読み取りおよび書き込みを提供し、スレーブは読み取り専用のサポートを
消費者の何も設定しない場合、またはビジー状態のマスターと、スレーブ消費者は自動的にノードに切り替わります読み取ることができます

メッセージの購買力を上げます

パラレル消費
- 複数のノードを追加します。
- 消費者の個々の増加の並列処理、修正およびconsumerThreadMax consumerThreadMin
- N、メッセージより、各時間メッセージがNを受信した場合consumerMessageBatchMaxSizeコンシューマ、デフォルトを設定ボリューム消費者は、1であります
Linuxのext4ファイルシステムを選択し、Ext4のファイルシステムのサイズ1Gが削除されたファイルは、通常より少ない50ミリ秒以上かかり、ext3ファイルシステムは、ディスクIO大きな圧力からあなたの削除ファイルは、IO操作がタイムアウトが発生することができ、時間のかかる1Sを、必要