まず、なぜメッセージキューの使用？
多くの場合、メッセージキューの目的:: 切り離され、非同期、クリッピング。
MQを通して、パブ/サブパブリッシュ・サブスクライブ・メッセージングは完全に切り離され、そのようなモデルであります
同期の動作は非同期動作となるようにMQによって、効率を向上させます。
MQ、制御サービスが受信できる要求の数
第二に、どのような利点と欠点メッセージキュー
特別なシナリオの下で、対応する利点は、利点があり、非同期のデカップリングは、クリッピング、
いくつかの欠点があります。
-
システムの可用性を削減
導入された外部システムの依存関係、ハングアップする方が簡単。高可用性を備えたメッセージングキューを確保する必要性
-
システムの複雑さの増加は、メッセージが消費を繰り返されないことを保証するために、どのようにメッセージの損失が発生した場合に対処するために、どのように確保するために、そのメッセージの配信のために？無残に大きな頭、多くの問題の大部分。
-
一貫性
しかし、問題はBCD、BD 2個の書き込みライブラリシステムが正常に行われた3つのシステム、Cの書き込みライブラリシステムの結果は、zezhengを失敗した場合のことであり、直接のリターンを超える処理システムは、人々はあなたが成功する要請と思い、成功したのですか？あなたのデータが矛盾しています。
第三に、どのようにメッセージを解決するために失われていますか？
-
ACK（消費者の確認）（コンシューマー・マニュアルACK ）
-
持続性（スイッチ、キュー、メッセージ）
-
性能検証を削減するメッセージトランザクションの使用を推奨していません
-
メーカー認証（パブリッシャ確認）：プロデューサーは何の障害情報を受信していないか、受信された場合、ACKのMQを待っているメッセージを送信した後、再試行してください。あなたがメッセージを受け取った場合、ビジネスの成功の結論です。
チャネル。waitForConfirmsOrDie（10000）; -
信頼性の高いメッセージング・サービス（また、ロジック自体を書く）：一部の生産者が確認メッセージキューをサポートしていないため、メッセージがデータベースに永続化される前に、メッセージが送信され、記録ステータスメッセージ、その後のメッセージ送信、消費プロセスに依存していますデータベースを分析し、メッセージのステータスを変更します。
第四に、どのようにメッセージの蓄積を避けるために、
-
同じキューによってより多くの消費者がメッセージのための競争を実現する監視、メッセージは消費の速度を加速します。
第五に、どのように整然としたメッセージを確保するには？
：あなたがプロ高いのタイミング要件に遭遇した場合、ほとんどのサービスは、メッセージの要求が厳しく命じ、2例を扱いました：
-
同時操作要求の少ない中：
-
注文した同期メッセージが送信されたときに保証
-
同じキューメッセージが受信されていることを確認するために、
-
キューつのみ消費者を確保、スレーブ（スタンバイ状態）、高可用性があってもよいです。
-
マスタースレーブ（飼育係クラスタ予備選挙）
-
-
同時に厳しいながらビジネス：
-
前記第一の条件が満たさシーンです
-
あなたは、複数のキューを持つことができます
-
固定された一方向ハッシュに2ハッシュをキューにディスパッチすることにより、要件のメッセージのセットタイミング - > klsdilelksd
-
第六に、どのように支出のメッセージの重複を避けるために？
-
冪等を確保するためのインタフェースは、その後、どのようにそのインターフェイスの冪等、それを保証するには？
-
このようなクエリのような天然の電源のようないくつかのインターフェース、
-
いくつかのインターフェイスは、新しいような本質的冪等、ではない、ならびに特定のインタフェースの機能を変更します
1--受信したメッセージが処理されて、3- 2-メッセージであります
更新設定STAT = 3ここで、ID = 2及びSTAT = 2
-
消費者の取引終了を決定することによって行うか否かは、特定のサービスまたは状態に応じて決定することができます
MSGID転送メッセージID = 123 - 「123456のRedisのMSGID - > 123456、ユーザID
-
-
七、カフカ、ActiveMQの、RabbitMQの、RocketMQ何の利点と欠点？
| プロパティ | ActiveMQの | RabbitMQの | RocketMQ | カフカ |
|---|---|---|---|---|
| スタンドアローンのスループット | 一万、大きさの順RocketMQ、カフカよりも低く | ActiveMQのでは | 100,000高スループットをサポート | 100,000高スループット、リアルタイム計算データ、ログの収集および他のシーンのための一般的なシステムを持つ大規模なデータクラス |
| スループットトピック数への影響 | トピックは、より少ない程度に減少し、スループットの数百/数千人のレベルに到達することができ、これは大きな利点がRocketMQで、同じマシンに、あなたは、トピックの多数をサポートすることができます | 倍の数十〜数百から話題、スループットが大幅に低下でき、同じマシンでは、カフカはあなたが大規模なトピックをサポートしたい場合は、より多くのマシンのリソースを追加する必要があり、そのトピックの数があまりないことを確認してみてください | ||
| 即時性 | ミリ秒レベル | RabbitMQのの大きな特徴であるマイクロ秒、最小の遅延 | ミリ秒レベル | ミリ秒の遅延段内 |
| 可用性 | 高可用性を実現するために、マスタ・スレーブ・アーキテクチャに基づいて、高 | ActiveMQのでは | 非常に高い、分散アーキテクチャ | 分散データの非常に高い、複数のコピー、機械のダウンタイムの数が少ないが、何もデータが失われることはありません、それは利用できませんにはなりません。 |
| メッセージの信頼性 | データ損失の低い確率を持っています | 基本が失われることはありません | パラメータ最適化設定の後、それが0の損失を行うことができます | RocketMQ付き |
| サポート機能 | 完全なのMQ非常に機能領域 | アーランの開発に基づいて、同時性が非常に強い、優れた性能、低遅延であります | MQ関数は、より完璧な、または分散、スケーラビリティ | この関数は、主支持シンプルMQ機能、リアルタイムシステムは比較的単純で、フィールドで収集されたデータを記録する大規模な使用であり、 |
中小企業は、技術力はRabbitMQのは良い選択であるとの技術的な課題は、特に高いものではなく、より一般的です。
大企業RocketMQと、R＆Dインフラ強いが、良い選択です。
もしそうであれば、データの大面積